0

I have an existing SPA application where api calls from user browser are forwarded to application server hosted separately. My application server have all business logic and repository to connect to DB. Something like below :

enter image description here

we are thinking of merging application layer with rest api so that new design would look like :

enter image description here

Technically both design serves the purpose but I would like to know what are architecture decision points to choose one versus another and what are pros and cons if I have to consider one vs another.

  • In the first picture, what does the box titled "service" actually do? – nvoigt Sep 26 '18 at 9:15
  • @nvoigt : it is a service (say wcf endpoint) exposed from application server so that machine hosting rest api can connect – Rahul Agarwal Sep 26 '18 at 9:27
1

In the first approach you have an underlying business service and a separate backend-for-frontend that accesses it. In the second approach the business service directly services the UI, without an intermediate gateway service.

The trade-off that the second approach makes is operational simplicity for architectural flexibility and separation of concerns.

  • By getting rid of the adapter service the underlying business service now has to mix all concerns needed by the UI. If your intent is to isolate different concerns in microservices, you may find it hard to do this without a gateway service in front.
  • If you add more than one front-end with different needs, that single business service will need to cater to all of them. In my experience this leads to messy API's in practice.
  • I think I understood your both points but still trying to prove my understanding wrong :) sounds crazy ? Ok, for your first point. If I will have my api layer which is accessed from outside as is and it will access my business logic hosted under same application rather than via proxy (which you see in first diagram). Having said that, how your statement underlying business service now has to mix all concerns needed by the UI still applicable ? – Rahul Agarwal Sep 26 '18 at 12:32
  • Also for second point - If you add more than one front-end with different needs, that single business service will need to cater to all of them, can you please help with some example. Like mobile & web browser you mean ? – Rahul Agarwal Sep 26 '18 at 12:33
  • Regarding your first comment, in my understanding that is still a single codebase. That approach can work fine, but if you want to have multiple teams working on that product it is preferable to have separate microservices. For the second comment, different front-ends could be mobile, web, desktop, front-office, back-office, ops, etc... – Joeri Sebrechts Sep 27 '18 at 7:06

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.