API Calls – Best Practices for Calling Multiple APIs and Data Manipulation

As is often the case, it depends

With a pure JS framework

• you push a lot of processing to the clients. That means your webserver for the client application will only be serving static files that can be cached.
• your clients have to be able to handle that processing and need some amount of computing power
• your clients need to fully support all JS-features that your front-end framework uses and you are somewhat tied to the support that framework offers for older browsers. If your framework's newest version decides to drop support for some older IE version that your clients still rely on, you will be stuck with that.
• your REST API's endpoints needs to be accessible by all the clients which might be an issue

Having an intermediate layer means

• you put the processing power in your single server, which is something you can control and, if need be, add more resources to. For clients this is more difficult and sometimes impossible
• you have the ability to control the calls to the REST API and, for example, cache data so you don't need to hit the API every time
• you have more control over security as the endpoints for the REST API do not need to be public
• you have more fine-grained control over the rendered HTML and are not tied to the components provided by your framework. You could create a component that initially uses JS to build part of a view and when performance becomes an issue replace that by HTML generated from the server
• you need to run and maintain a server with some server-side programming language capability

The question is: which of these issues matter to you and which don't. If you have a requirement to support lower-end hardware I'd stay away from JS front-end frameworks. It's very hard to control performance that way and you are very limited in the optimisations you can perform.

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.