1

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 ?

  • I've slightly reformulated your question, in order to avoid an opinion based question (opinions are out of scope here, e.g. "your views", "what ou prefer", ... ). Don't hesitate to re-edit if I misunderstood something. – Christophe Jan 26 at 11:12
3

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.

  • actually we are talking about a very complex biz app with very fine grained security. since business users are not really concerned with app maintenance and it is the role of system admin team to maintain and keep the system running hence i decided to have separate apps. and yes you correctly presumed that business users don't handle the permissions or security themselves. – Simple Fellow Jan 27 at 11:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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