I need to build a few (2-3) different systems (frontends), they will have different uses and users, however the data for all those systems is in 1 DB.

example: 1st system is a customer facing site 2nd system is a customer facing mobile app (android and ios) (similar to the site but can have different views/data) 3rd system is a backoffice app where admins can manage the customers

since the data is in 1 DB, i was planning to create 1 backend API to support all the frontends.

however the more i try to plan the authentication and authorization part (how the frontends will talk to the backend) it's getting too complicated.

I'm pushing for 1 backend api to prevent code/functionality duplication or differences issues, for example "edit customer" contains many steps and is possible via each frontend. i don't want to have 3 inconsistent versions of the same function.

did anyone have a similar need and found a good solution?

my main issue at the moment is how i protect certain functionality in each app, protect the api routes per user+frontend app.

I'm open to suggestions about which frontend technology to use, the backend is nodejs

thank you

4 Answers 4


You have three options.

  1. Make all the front end use the same auth server. The backend can verify the token and check the claims.

  2. Make the backend able to authenticate the requests for each front end. You can have it check a set of possible signing keys for example.

  3. Have a separate authentication method for the backend, say an API key which each of the front end knows.

    In order to hide this key from end users this may require that each front end has a simple backend which understands its front end auth, adds the secret API key, calls the backend and then returns the results.


I would create a single backend API as you planned and store the info about the frontend in the url, something like:



and then this info I would put in the request object (how you can do that depends on the language, framework you will use). I would use this as you use user roles. urls can be protected by using this info. You can put if else in the api too where depending on the frontend the api has to do different things or things in different way.



I do not see any difference between using one back end for multiple front ends and writing each front end its own back end. I will not make a suggestion on the front end- though,angularjs is very easy to use with classes etc-, but if you can, use inheritance for your back end.

Write a parent class with common functionalities and inherit from that for each back end,(like, you will still have 3 classes, but hassle will be less) in my opinion. This way you don't have to duplicate the same function but when needed, you can specialize.


So based on the time of responding to when the question was initially asked, I am pretty sure you have come across something called headless cms or backend or headless whatever.

The idea with this headless concept is that all frontend architecture will access data through an API. This also gives developers a chance to be flexible and pick a UI development tool that they prefer, rather than sticking to one dev tool because of compatibility with the backend or something related.

So on your question of having multiple frontends, that is quite clear now I guess that since the API can allow the manipulation of data in the database, almost any (reasonable) number of frontends can access the same data in real-time.

I hope your question is answered and I want to leave my answer for those in the future. I know they will come, lol.

Happy hacking !!!

Not the answer you're looking for? Browse other questions tagged or ask your own question.