Breaking 3-tier architecture into multi-tier architecture

Question

Recently I have been working on a rather large system with Vue.js for a single page app (SPA) and an API for the backend. The customer is concerned with the security, performance and maintainability.

So, I'm thinking along having API broken into 3 separate pieces:

1. the security api which authenticates/authorizes, issues/revokes token with user roles/permissions and accounts. It would have a separate db
2. the business API that has the business functionality, accessible only thru the token issued by the security api. It would have a separate db
3. notification api that sends real time notifications and email or text alerts. Again a separate db.

On the front there would be separate apps: one for security api for managing roles user accounts, monitor logs etc and another one, the business app, for the complex business functionality.

I would like to know:

1. what are the advantages and inconveniences of this architecture (2 frontend apps and 3 webapi) compared to a single frontend and a single web api ?

2. which one would be the recommended one, in view of the triple constraint of security, performance and maintainability ?

Answer 1

On the front-end side

Your requirements seem to cover two very different needs and functionalities:

• one, is the management of the application and its security (authorisations, accounts, logging)
• the other is the core business functionality.

Combining both in a single application makes the application more complex to maintain, and this might also result in a more complex user-interface. Go for this approach if most users use both functions (e.g. if business user manage themselves permissions for other users, and if business users need to view logs for verification or audit purposes). In all other cases, having two front-ends for two different user population would have many more advantages than inconveniences.

On the API and the back end side

API, back-end and databases are different but interrelated topics. While your question is very broad, here some comments to help you finding the optimal solution.

If the functionality of your 3 identified API sub-parts is very independent/encapsulated (which seems to be the case) you could be inspired to go for a microservice based architecture, in which each microservice has its own API and its own database.

However microservices require a paradigm shift and significant reengineering that might not always be desirable or even feasible. You can very well achieve a high maintainability by having still a monolithic second tiers back-end but using a clean architecture and a solid design. Scalablity could be achieved by running several second tiers (load balancing). But in this case, a single db seems to me the more pragmatic approach. I assume that the db would then be on a third tiers that is only accessible from the second tiers which themselves uses a sanitized API.