Best Practices - Including endpoint URL calls in JavaScript vs backend calls

Question

I am building a web application that will retrieve results from a remote server and use them to render some charts and maps. The remote server has already been implemented and contains a large amount of APIs, written in Java Spring Framework. The developer that implemented them, has given me access to a set of non-public endpoint URLs, which I will query and get the results in JSON format. Please note that some time in the near future, some of these APIs will be sensitive and should be limited to authenticated users only.

From my side, I am developing only the frontend with ReactJS. The entire logic of the calculations, the user maintenance, the authorization/authentication as also as the user input, happens on the remote server via these API calls.

Now, my question is this: where is a good place to put the web service calls? As far as I am concerned, there are two options:

• Create asynchronous AJAX calls in the existing ReactJS code, that will retrieve the required data and render the charts
• Create a second backend, written in Django framework, which will do all these API calls, effectively isolating them (they are subject to change) from the ReactJS application and providing a way to securely "hide" the information regarding the actual URLs from a potential intruder. The backend will "talk" with my frontend via a set of calls, different than those of the external server.

The quickest and easiest way is to go with the first approach. But is it a good practice to have sensitive API calls, that due to the nature of the application are subject to change anytime, in the JS code which is only for rendering the client-side?

By having a second set of calls in my local backend, I am allowed to decouple the remote APIs from my application, maintain them more easily, change and secure them and remove the ability from an end-user to inspect the webpage's code and see the actual URLs in plain format.

I know of course that the end-user will be able to see some API calls, but I am more comfortable with him seeing mine APIs (going into my backend), than giving him the ability to see (and maybe use) the remote APIs.

Here's is a simple sketch of the two alternatives:

Is there any obvious gains by following the second approach or am I over analyzing this?

Answer 1

A framework/language or any other technology will not save you. By that I mean that Django is not your only option. What you should focus on is the design and do the implementation on the technology you are most familiar with (if this is not just a personal project). Having that in mind, I would try to make both ends as much independent as they can be. That means that ReactJS (or the frontend) should not hold any data, that are not to be presented to the user.

An approach I think would work:

• Create JSON entities with which the front and back ends can talk to each other. E.g. {"query" : "give me something from the DB <NOT SQL>", "id":"random uuid"} with a reply from the middle layer (read below) {"result" : "contains what you need", "id" : "uuid used before"}.
• Create the "second" backend, which in reality is a middle layer, that converts your data to the data the existing data model holds and is responsible for the communication of the front and the existing backend. This layer will do the retrieval of the data, the authentication of the users, push events, etc.
• Avoid mixing the responsibilities of the presentation of the data to user and the actual retrieval of the information. I've already stated that, but keep in mind JS can be debugged in your browser so you don't want sensitive data to exist there.

As for the communication an alternative to AJAX would be websockets.

Answer 2

1. Aren't you doing extra work for the API developer who should have put robust security and authentication on a public facing API in first place ?

2. API complexity and changes can also be encapsulated by a separate class/service in ReactJS code itself. Moving it to another server serves no purpose.

These two concerns, security and encapsulation need to be addressed at different places in the tech stack.