Best approach to connect two nodejs REST API servers

Question

Scenario is I have two Node applications which are providing some REST APIs, Server_A has some set of REST endpoints, and Server_B has some other set of endpoints.

We have a requirement where Server_A need some data from Server_B. We can create some REST endpoints for this but there will be some performance issues. Server_A will create http connection each time to Server_B.

We can use Websockets but I am not much sure if it would be good approach or not. In all cases Server_A will be calling Server_B and Server_B will return data instantly.

Server_B will be doing most of the database operations, Server_A has calculations only. Server_A will call Server_B for some data requirements.

In Addition, there will be only one socket connection that is between Server_A and Server_B, all other clients will connect via REST only.

Could anyone suggest if it would be correct approach? Or you have some better idea.

It would be helpful if I get some code references, modules suggestions. Thanks

Answer 1

What you are asking about is premature optimization. You are attempting to optimize before you even know you have a problem.

HTTP connections are pretty darn fast. There are databases that work using an HTTP API and those databases are consulted on every HTTP request of the server. So, an HTTP API that is used frequently can work just fine.

What you need to do is to implement your server A using the regular HTTP requests to server B that are already supported. Then, test your system at load and see how it performs. Chances are pretty good that the real bottleneck won't have anything to do with the fact that you're using HTTP requests between server A and server B and if you want to improve the performance of your system, you will probably be working on different problems. This is why you don't want to do premature optimization.

The more moving parts in a system, the less likely you have any idea where the actual bottlenecks are when you put the system under load. That's why you have to test the system under load, instrument it like crazy so you can see where the performance is being impacted the most and then measure like crazy. Then, and only then, will you know where it makes sense to invest your development resources to improve your scalablity or performance.

FYI, a webSocket connection has some advantages over repeated HTTP connections (less connection overhead per request), but also some disadvantages (it's not request/response so you have invent your own way to match a response with a given request).