AngularJS: Server Side Architecture

Question

Within our corporate intranet, we have a few end-point service platforms like BPM, document management system, etc. These end-point services expose REST API. We develop web applications using AngularJS as front end.

There are two options on how we can make calls from AngualJS to these end-point services.

Option 1: Given these end-point services expose REST, call these REST API directly from AngualrJS.

Option 2: Introduce a middle layer (on an application server like WebLogic or Tomcat). Build a Java application layer that calls into the end-point REST API; and host it on this millde layer. The AngularJS calls into REST provided by this middle layer; this middle layer inturn calls into the end-point REST.

I personally prefer the Option 1; however I invite your openion on this matter. I have listed the pros and cons of Option 1 as I see them.

Pros of Option 1:

• Better performance (throughput) given one less hop for HTTP requests.
• Lesser development/deployment efforts due to one less component.
• Lesser number of points of failure. If there is an issue, we know its either in AngualrJs or the end service.

Cons of Option 1:

• Security issues? Not sure of this - would like expert comments on this.
• CORS: the end services will need to enable Access-Control-Allow-Origin to appropriate domains.
• Poor logging? If something goes wrong, the logs will be available only on user machines (IE/Chrome development tool) or on the end service.
• Too much processing in AngualJS layer? This processing is mainly parsing the result from end service. This also depends on the kind of end service that is being used.

Answer 1

Thanks for such a nice article.

If you are concern with security and your project requirement is focused on Security. One must go with Option 2.

If Security is not a big concern. Options 2 is better.

Answer 2

option 2 in my opinion is a better option in long run. There are few reasons for that.

Security is first and foremost, If you have a middleware in between, you can have inherent security, which means you can expose only those REST APIs which your angular webapp needs. You can also include a security mechanism like oAuth since you control the middleware.

Logging is another one. for sure any application nowadays do need some sort of auditing. both security and logging are layers before your actual REST calls.

You would be able to add some aspects on any key REST API, such that in case if that API is called trigger a mail, it's always handy to have those flexibility even we don't need at the moment.

You can include response transformation and error handling efficiently. Once you get the response from service, in your middleware you can transform the response, remove unnecessary or critical fields, conjure some values etc. This all can be done with angular also but then the real response or error is exposed to the client.

On the downside you rightly mentioned performance is one but imo keeping your REST middlware in sync with services REST is more bane. any new API added by services, needs to be included in middleware, recompiled and redeployed. But it also depends what are the likelihood and frequency of those changes? for any those changes you anyhow might need to change in angular webapp to include it.

Answer 3

You mention "Within our corporate intranet". Depending on how the end-points are secured, option 1 could be challenging.

Angular will run in a web-browser so if those services are only accessible via VPN / intranet, the web-app will only work if your computer is connected to that intranet (i.e. it won't work if you run it from home).

Another security challenge with option 1 is that if the end-points require special authentication "secrets" (API tokens, passwords, certificates, etc.), those secrets will be exposed and visible to anyone who uses the web-app since anyone can see the traffic between their browser and the server. With option 2, those secrets can stay hidden behind your middle layer.

Lastly, even if Angular talks to those end-points directly, you will still need to have the HTML / JS / CSS hosted on some web-server. You may not need a full blown application server but you'll need something to point your web browser at.

If those concerns don't apply to your case, then it's really up to you to pick whichever option you and your team are the most comfortable with.