Regardless of which communication protocol the backend development prefers, we can use any convenient way to communicate with the web client. REST, RPC, GraphQL — we choose for ourselves.
But isn’t GraphQL itself a solution to the problem of getting data with a single query? Maybe you don’t need to build any intermediate services?
Unfortunately, effective work with GraphQL is impossible without close cooperation with backenders who undertake the development of effective database queries. By choosing such a solution, we will lose control over the data again and go back to where we started.
You can, of course, but it’s not interesting (for a frontender)
Well, let’s implement BFF. Of course, on Node.js . Why? We need a single language on the client and server to reuse the experience of frontend developers and JavaScript to work with templates. What about other execution environments?
GraalVM and other exotic solutions lose V8 in performance and are too specific. Deno is still an experiment and is not used in production.
And one more thing. Node.js is a surprisingly good solution for implementing the Gateway API. The Node architecture allows the use of a single-threaded JavaScript interpreter combined with libuv, an asynchronous I/O library, which, in turn, uses a thread pool.
Long calculations on the JavaScript side hit the performance of the system. You can work around this: run them in separate workers or take them to the level of native binary modules.
But in the basic case of Node.js is not suitable for CPU-intensive operations, and at the same time works perfectly with asynchronous I/O, providing high performance. That is, we get a system that can always respond quickly to the user, regardless of how loaded the backend is with calculations. You can handle this situation by instantly notifying the user about the need to wait for the end of the operation.
Where to store business logic
There are now three big parts in our system: backend, frontend and BFF between them. There is a reasonable (for an architect) question: where to keep the business logic?
Of course, the architect does not want to smear business rules across all layers of the system, there must be one source of truth. And this source is the backend. Where else to store high-level policies, if not in the part of the system closest to the data?
But in reality it doesn’t always work. For example, a business task comes that can be implemented efficiently and quickly at the BFF level. Perfect system design is cool, but time is money. Sometimes you have to sacrifice the purity of the architecture, and the layers begin to leak.
Can we get the perfect architecture by abandoning BFF in favor of a “full-fledged” backend on Node.js? It seems that in this case there will be no leaks.
Not a fact. There will be business rules, the transfer of which to the server will affect the responsiveness of the interface. You can resist this to the last, but you probably won’t be able to avoid it completely. The application-level logic will also penetrate the client: in modern SPAS, it is smeared between the client and the server, even when there is a BFF.
No matter how hard we try, the business logic will penetrate the API Gateway on Node.js Let’s fix this conclusion and move on to the most delicious — implementation!