I'd like to hear some background from the author on his situation(s). Personally my current company is over 100,000 employees. We have a few 100 developers and many stacks, web apps, mobile apps etc. Our API is essential and is currently a giant monolith written by devs who no longer work here.
Splitting API code into repos based on endpoints allows us to have small easy chunks to deal with. It also allows us to drop those into containers and monitor and scale much easier. It also means instead of one API team, other devs can easily pickup a small code base and make changes for their stuff and, submit a PR for the API team. ]]
This article seems a bit elementary to have been voted up high on HN to be honest. It failed to acknowledge the true merits of doing microservices properly and the huge gains. Not all code bases are meant for microservices. However, huge monolith API's in general are a very good example where it's a perfect fit.
Splitting API code into repos based on endpoints allows us to have small easy chunks to deal with. It also allows us to drop those into containers and monitor and scale much easier. It also means instead of one API team, other devs can easily pickup a small code base and make changes for their stuff and, submit a PR for the API team. ]]
This article seems a bit elementary to have been voted up high on HN to be honest. It failed to acknowledge the true merits of doing microservices properly and the huge gains. Not all code bases are meant for microservices. However, huge monolith API's in general are a very good example where it's a perfect fit.