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)

Pros:

  • Deploy
    • Deploying is very easy.
    • If something fails, it might not be critical.
  • Relation with data
    • Each API is closely related with its "data model"

Cons:

  • Memory.
    • 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.
  • Is each REST api associated with a single database table? If it is, then why aren't you consolidating some of these services by department or function? – Robert Harvey Aug 10 at 20:12
  • I don't have the authority to make such decision, I'm trying to figure out if the "high cost of development" comes from the architecture itself or from the lack of good practices, if it's the latter I might be able to do something about it – user254856 Aug 10 at 21:00
  • "Best practices" are very difficult to pin down. Things that are best practices today may not be best practices five years from now. At the end of the day, the best practices are the ones that most effectively meet your specific requirements. – Robert Harvey Aug 10 at 22:11

It sounds like bad execution. The memory/hardware con is not really a big deal, so I'm going to concentrate on the "Expensive Development" part.

Most APIs interact with each other, and even load client side code. This seems like a red flag. Why are the APIs interacting with each other? Ideally they should be logically discrete. If there's a lot of cross-dependency, then it sounds like things have not been logically grouped correctly. Loading client side code is another red flag.

Errors are hard to find, and easy to introduce. Do your services not have their own logging?

Some modules are used in every API, changing these might mean changing ~60 repos too. You can introduce module versioning to solve this.

Lots of "boilerplate" repeated in most projects. See if you can break them out into libraries

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.