DEV Community


Posted on • Updated on

Micro Frontends Patterns#6: Isomorphic JavaScript

Isomorphic JavaScript (Universal JavaScript) refers to JavaScript or JavaScript applications that work on both the client and server.

This chapter show you some use cases and technologies.

Server Side Rendering

A typical example is Server Side Rendering (SSR) in React applications, which uses ReactDOMServer to generate markups on the server side and return dynamic views from the server side.

This solves the performance bottleneck of Client Side Rendering, SEO optimization and OGP issues. It also allows the use of Virtual DOM libraries such as React as "templates", avoiding the traditional inefficient client side programming with template engines.

SSR in this context includes a technique called Rehydration. The ability to do rehydration means that, for example, Client Side Rendering is also possible. The SSR application is displayed for initial rendering only, followed by rehydration on the client side, and Client Side Rendering thereafter.


BFF, or Node.js as an API Gateway layer, can be considered as an extension of Isomorphic JavaScript as SSR. Basically, let Backend Microservices do the CPU-heavy processing, and BFF communicates with them via API. I think it fits well as a BFF layer 1, partly because Node.js doesn't have very nice ORM I personally don't like Node.js ORM as much as those in other languages 2.

As I mentioned in the Microservice Architecture chapter, the Gateway layer needs some work to keep it simple. Node.js's ease of implementing asynchronous & non-blocking I/O and TypeScript's strong type support are not bad for a language that runs on this layer.


SSR had some technical complications. For example, there are processes for fetching data that you want to run only on the server side, and processes for rehydrating data in a state management layer such as Redux.

Frameworks such as Next.js and Nuxt.js have emerged as technologies to cover these troublesome issues. They were not just for SSR, but they had an impact at the time simply because they wrapped up the difficulties of SSR.

In addition, API route in Next.js allows for backend implementation, so we can expect to see uses such as BFFs and endpoints for SSG, which I mentioned in the JAMstack chapter. The fact that you can use universal bundling with almost zero configuration is also attractive.

It is also unique in that it can be used to build a hybrid of SSR, SSG, and Incremental Static Regeneration. For more information, please visit

Pros and Cons


The fact that the Gateway layer can be developed in one language and the "frontend" of the application can be taken care of using only JavaScript will reduce switching costs and will be effective in team development of distributed systems. It is also good at handling large numbers of requests due to the aforementioned asynchronous and non-blocking I/O nature.

Although it not about the Web, it also has high portability as a program, in that it can run on relatively any device, anywhere. The client is implemented in JavaScript, and can often be used as a set.


Rather than the disadvantages of Isomorphic JavaScript itself, you need to understand the weak points of Node.js and JavaScript. For example, one of the biggest ones is the aforementioned CPU-heavy characteristics.

As for JavaScript as a language, I feel that it has a complex build process and ecosystem. In today's JS world, considering TypeScript, testing, etc., building is a prerequisite, and considering understanding and using the surrounding ecosystem and compiler specifications, it is a relatively complex world compared to other languages. TypeScript is certainly wonderful, but I think the complexity of it is difficult to understand for different language people.

And it is too free as a language, that can be both an advantage and a disadvantage. JavaScript is a multi-paradigm language that can be written in many different ways, and some engineers may find it difficult to implement asynchronous processing or package structures.


Isomorphic JavaScript offers the choice to provide the entire Frontend of an application with JavaScript. When used in the right way for the right use case, it has proven to have advantages that are second to none to other languages.

  1. I don't like NoSQL as an escape either. 

  2. I have only used Sequelize and TypeORM. 

Top comments (2)

clamstew profile image
Clay Stewart

“Node.js doesn't have very nice ORM”.

Strongly disagree. Sequelize.js is a solid ORM with schemas, seeders, migrations, etc.

kasvith profile image
Kasun Vithanage

“Node.js doesn't have very nice ORM”

Try Objection.js with Knex. Dont fall for sequelize and suffer later