I'm currently working on a project/product which consists of ~60 REST APIs and one client (Web app)
I find many downsides on this design, and not so many benefits, and I'd like to know if this is clearly a bad practice from an architectural standpoint or just bad execution. (And if it can be improved without changing the design)
- Deploying is very easy.
- If something fails, it might not be critical.
- Relation with data
- Each API is closely related with its "data model"
- Each API serves its own http server, averaging at ~75mb idle.
- Most APIs also have at least 2 "workers" (RabbitMQ emitters/handlers) to interact with other systems.
- Expensive development
- Most APIs interact with each other, and even load client side code.
- Errors are hard to find, and easy to introduce.
- Some modules are used in every API, changing these might mean changing ~60 repos too.
- Lots of "boilerplate" repeated in most projects.