Consumer-Driven Contracts is an interesting approach to the design and verification of API endpoints. The basic idea behind this is that the consumer decides how the API should work, not the server. Scary, isn’t it?
A miracle has occurred! I implemented few things for Commutee and that is great! 🙂
Last time I wrote about the general design of the Ports and Adapters architecture. I have also described how I plan to use this approach in the Commutee app with the focus on the primary ports, that is the entry points to the application. This time I’ll focus on the secondary ports, the ports that domain requires.
Another week has come to a pass and unfortunately, I did not manage to work on a project at all – again. But I have some ideas that may push the progress a bit forward. As I have been on conference week ago I heard some new buzzwords, saw few interesting technologies and architecture patterns so it would be good to test them out. I’m thinking about using Consumer-Driven Contracts for designing REST API for Commutee, but it is still far from that stage of the project. For now, let’s try Hexagonal architecture! The ports and adapters approach. I will probably overengineer it, but hell, better here than in production 🙂
The 2017 4Developers Festival has come to a pass and it was awesome! For me, this is the obligatory conference that I plan to attend every year from now on. I have been on total o 7 hours of lectures and 2 hours of discussion. All of this time was worth it. Only one lecture of these was a bit weaker, but it still was really informative!
Oh, and you can get cool cups there too 😉
Here’s a quick summary of the most interesting things for me.
It is the fourth week of work on Commutee project. Well, technically it is the fifth week, but I didn’t have much time for work on this project, so let’s pretend that it is week number four 😉
I have started thinking about the neo4j data model for all this public transport data that I have been parsing lately, and I have a big problem here…