Search code examples
restapiweb-servicesarchitectureflask-restful

Should an API be a module in my python project or a new project?

We have a python web app that clients interact with and that web app directly interacts with a database. We now have the need to develop an API that merchants will use to get and post data from/in our database in JSON. Should we build the API as part of the web app, meaning that each request will pass through our python web app and then interact with the database or should it be separated? Further considerations include scalability and the fact that in the future we’ll probably want to develop a mobile app or other services that will also need to communicate with the database. As such, we considered the possibility to build an API as the only point of interaction with the database. However, we are deeply in the development of the flask web app and change it would mean an huge delay in our schedule and we just wanted to weight in the advantages and disadvantages of both solutions. These two schemes summarize the options we are considering:

Option 1:

Option 1

Option2:

Option 2

Solution

  • As you said both options have advantages and disadvantages.

    Option 1 gives you Separation of Concerns. The logic for interacting with your database is abstracted behind a single service. Changes to the type of database you use or the schema you use only requires code changes to a single service. For example, say your platform has expanded and you now wish to cache calls to your database. If you have an API, Web App, and Mobile App all communicating directly with the database they must all be updated to take advantage of the cache. These changes would likely also have to be orchestrated to be deployed at the same time. In reality this is going to involve downtime: most often you see this referred to as 'scheduled maintenance'. However, Option 1 breaks the Single Responsibility Principle. A service should do a single thing and do it well. In Option 1 the service is responsible for both being an interface to the database and rendering HTML for the web app. Changes to the Web App require you to redeploy the service for the API even though the two are not connected.

    The advantages and disadvantages for Option 2 are mostly just the opposites of the advantages and disadvantages for Option 1. Multiple services sharing a database can lead to inconsistency in the data, tight coupling (especially in deployment), and debugging being more difficult.

    A common design pattern (which I'd recommend) is a slight modification of Option 1. An API sits in front of the database. This is the only service that interacts with the database. This setup should improve your scalability. It's easy to deploy duplicate APIs and then load-balance requests between them. Furthermore, caching database lookups or changing database technology entirely is a (relatively) simple task. Your Web App, or any other services you develop in the future, interact with the API instead of the database. Here you can reap the benefits of Single Responsibility. It is worth noting that with this design every request for your Web App will have to go through two services. However, the benefits of the design arguably outweigh a few extra milliseconds of latency.

    One last thing: kudos for thinking about scalability this early on. You may take a hit now if your schedule is delayed but I think you'll be better off in the long term.