Is it a good idea to develop website that only has little access to DB? CRUD will be done by calling API provided by separate internal backend system

Question

I'm going to start developing an application in near future. This application consists of :

1. Back-end system. This system provides API to be used by client. This system connects to data store and 3rd party API.

2. Data Store : Can be relational or nosql data store.

3. Client : Client will be a website and mobile applications.

My reasons are below :

1. I want to prevent duplicated SQL query and 3rd party API call in website application side. The application and website will be developed by different developers. Only back end system developers that can make query or call 3rd party API. All website developers should only use API provided by back-end system

2. In my opinion, the website is also a client just like the mobile application. If the mobile apps get their data from back-end system API, why the website shouldn't be the same.

3. I heard twitter is using similar idea (I can be wrong though). Its website is using twitter API just like their mobile application.

My primary concern to this architecture is that the website performance will be lower compared than If the website can make query or 3rd party API call directly.

Is there any other pros and cons that I should think about ?

Answer 1

As they say in Computer Science, "A level of indirection solves every problem".

You can view what you are developing as a Service Oriented Architecture. The front end application consumes the data retrieved from the back end application. Together, they form a service. (The front end application might run on your user's machine, if it is a thin client, e.g. made in JavaScript, or it might run on your machines, if it is a fat client that needs to perform complex computations or needs access to other resources that are not on your user's machine).

The main upside of this specific "building a level of indirection" is that you are abstracting away your core data model. Many different clients may retrieve it using the same API: a mobile app client, an administration site that is not accessible from the Internet, or an embedded client in a satellite circling the Moon. Also, you are free to exchange the way those core data are stored: to you, they are retrieved from a DB, but those clients do not care if next week the backend retrieves the data from a flat file or a NoSQL key-value store.

The main downside is that this may be overkill if you are building a simple web site that is used within an intranet.

As @RobertHarvey notes, your concern about performance is unfounded. Indeed, being able to exchange backends might allow you to scale to much more performant hardware or software without the clients noticing.

Other pros and cons: remember to have a very clear protocol between frontend and backend -- what was before an interface between packages has now become a remote API. Having an API call that returns the version, or the API capabilities, is useful. If the client calls go over the internet, remember to take into account they could be forged -- try to encrypt and sign them, as if they were mails coming to your central office from local branches.

Answer 2

You're basically describing a service layer.

Your performance concerns seem unfounded. In practice, your service layer will merely translate your API into the necessary 3rd party API or SQL calls; the overhead should be minimal.