1

First of all sorry for the title, I didn't know how to explain it. So here comes the story;

We are bunch of coders, front-end and back-end, and we are going to create this new system, based on micro-service architecture for our company. So we already have couple of micro-services in place and our current central application (symfony 1.4 based) is communicating with them, however we want to get rid of this old central application and build a new one. We basically decided to create it with one of the famous JS frameworks without doing much HTML coding. Here are the details about upcoming/planned system

  • Each micro-service is secured with OAuth2
  • Central application is of course responsible for logging in and managing token and requests to this micro-services.

So you may ask, OK this looks good but what is the problem? The problem is this,

(BE represents Backend Developers, FE represents Frontend Developers)

BE says, 'OK guys, we don't need to put your frontend code in a container (Lets say Spring MVC) and we don't need to manage sessions etc. because you FE guys will log this user in via our awesome OAuth2 service, you'll keep the token with you and whenever you want to hit those micro-service endpoints just append that token to your request and micro-service will provide you the response you want'

FE says, 'OK BE guys, why don't we do like this, we put our JS code in your Spring MVC environments which will do the session management and logging in and act as a ROUTER, router means this, our JS code just knows one endpoint in Sprint MVC and send all the requests to that endpoint and then that endpoint acts as a router and he redirects the requests to certain micro-service endpoints by appending token, so JS doesn't have to care about all this stuff'

So BE guys say, our approach will give us some certain benefits like,

  • We don't need to manage session for different machines, because there is load balancer in front of the servers and multiple machines behind we always have to keep sessions synced between them
  • Since we don't have to put your JS code in a container we don't need a running physical server on the cloud, we can just out your code on S3 in a bucket and no auto-scaling and no server costs
  • Since you want use to create a router endpoint for your JS calls that would cause to a 'Single point of failure', that means if this router end point doesn't work the complete system will not work at all, but if we use pure static JS even if one micro-service fails other will still work.'

FE guys take their chance and responds,

  • First of all your approach will make all our source code public
  • Your approach will make our micro-services visible for all, we know those endpoints are secured via oauth2 but that wouldn't stop DDOS attacks
  • This would probably end up in a more complex authentication flow

Here is also the way both teams suggests as a diagram. Which way would you guys go and the most important question is WHY? Thank for your suggestions. enter image description here

  • 4
    This question is a bit verbose and seems to convey some team drama: could you distill this down to what the two options are and what you understand the tradeoffs to be? I don't feel comfortable making such a large change to the question because I might lose important details. I also think you are likely to get a better answer with some editing. – user22815 May 15 '15 at 11:21
1

It's hard to answer.

Both approaches seem valid. most of the arguments seem weak. And you can make both of the architectures mimic the other's intended interface.

I'm mostly a ""server side"" developer, and i pretty much prefer the first (FE) approach, just because it'll give me more control, and i could offer the client a simple clear interface with less effort. I would of course want the "router" to run as several physical instances for scalability and redundancy.

Also I think it makes more sense to do session management on the server side.

On the other hand it really depends on the specifics of what you are building... If you have a "fat" client with a lot of Business Logic in it, the second architecture makes more sense...

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.