Separating API server from HTTP server is really worth to have?

Question

First of all, I would like to tell you guys to understand my English skill even if it's miserable to read it. I'm really trying to learn English nowadays.

-

I'm currently developing a web community that might have 2k ~ 3.5k visiting users per day. and the web server is running on top of NodeJS + Express.

and I'm using a boilerplate called react-starter-kit. and this boilerplate has HTTP, API server at once on a single NodeJS server application. (it provides server-side rendering as well)

while I was working for that project, a thought about performance suddenly came up in my head:

If this server serves both API and HTTP, Isn't it too heavy load on a single nodejs application? and when I rewrite the API part of server, It eventually affects whole web server..

so I just separated API server from HTTP server, and It works great as far as I see. then I finally reached what I want to ask about.

If API server and HTTP server is separated, Isn't it taking extra time to load web page since it does SSR (server-side rendering) which means fetching data from server to server?

below scenario is what I worry about:

1. a user requests a route /me.
2. /me route need to display current signed user information.
3. so HTTP server try to get/fetch current signed user information with authentication token (JWT) which is sent to HTTP server from client.
4. now HTTP server complete to render /me route and send it to client.

in this scenario, HTTP server should process extra fetching logic like what I explained on 3 of above scenario flow. and since HTTP server requests to API server, I think there's some problems:

1. It takes longer time to start downloading whole web page.
2. API server would conflict about client information.
3. It produces heavier load on the API server since both HTTP server and HTTP client requests on a API server.

I think I misunderstood benefits of separating API and HTTP server. can someone correct my thoughts? or tell me If I'm doing well?

Answer 1

In most cases, these kind of separations is likely a premature optimisation. Your load of 2k ~ 3.5k daily users sounds like it can be easily handled by a single server, so adding replica here is likely driven more by redundancy rather than scalability reasons.

For every server you separate out, you will increase operational/deployment complexity. Even when you use microservice architecture, you want to split services based on known needs and problems (examples). Each service that's split out should be done to solve a specific problem you have, rather than as a matter of course.

Answer 2

I'm currently developing a web community that might have 2k ~ 3.5k visiting users per day

The overall number of visits is not as important as the peak of concurrency in a given moment (or lapse of time). You are right being worried about the possibility to overload NodeJS app since NodeJS doesn't shine in scenarios with high concurrency and synchronous calls (web requests).

If API server and HTTP server is separated, Isn't it taking extra time to load web page since it does SSR (server-side rendering) which means fetching data from server to server?

Not necessarily. HTTP servers are implemented with one purpose in mind: to dispatch HTTP requests as quickly as possible. That makes them suitable for load balancing and that's why they are present in many network topologies, usually in front of application servers. Right as you guess in your question.

There're some very well-known for their efficiency and speed. Nginx is one of them, but there're others still faster like HAProxy. The latest is not a Web server in the same way Ngnix or Apache HTTPD is. It's High Availability proxy and its implemented in many of the largest software companies. The key of these components is that they were built to do one job and do it as efficiently and as faster as possible. Even the chosen programming language for their implementation have characteristics that make them especially good for the job.

Speaking about the programming language, I have said that NodeJS is not good at handling web concurrency, but it's excellent at dispatching requests up or down-stream. In other words, it's good at doing fire-and-forget. Pettry much what a proxy or gateway does.

in this scenario, HTTP server should process extra fetching logic like what I explained on 3 of the above scenario flow. and since HTTP server requests to API server, I think there are some problems:

Take some metrics first, With and without HTTP server. The differences in latencies should be around a few milliseconds. The precise latency will depend on several things. The most important ones are whether the connection between servers is encrypted or not (implements TLS) and whether they are deployed close to each other.

Usually, they are deployed within the same network (as @amon commented) or at least in the same data center. In very limited environments, they are deployed in the very same machine. Since the intercommunication process happens within a "secure" DMZ, there's no need for encrypting the communication server-to-server. And as you might guess, the communication between 2 processes running in the very same machine is very very fast. The latencies are negligible.

I think I misunderstood the benefits of separating API and HTTP server

Performance is one of the reasons why we usually put dedicated HTTP servers as balancers. There could be others, like serving static content. But also for security. With these balancers, we hide the network topology and we only expose a single point of attack which it's fairly simple to protect. For example, redirecting the load to a shrink hole or just setting thresholds (limits) of requests per address. Ideally, you will never expose the app server because it's a window that allows access to more important an critical systems. For example the database.

Anyways, don't rush into false premises or conclusions. Take some metrics first. Deal with the tradeoffs (deployment complexity) and then decide whether the benefits out weight the costs and perils.

At the time of getting the metrics, put special attention to the latencies that come from the app server. The potential time consumers are database connections and connections to external services. Overall when these connections lay uppon synchronous protocols and, as commented, they implement TLS.