⭐ Porting for React applications

Intro

Let's see how you can save time by using the porting technique when migrating from one technology to another.

Prelude

The world of the frontend is saturated with buzzwords. To avoid problems with migration into other technologies, it's worth using the porting technique in your code. Let's check it together in this article.

Understanding problem

Let's assume that you wrote the platform and it took two years. You used Gatsby and Netlify in particular. One day you see a YouTube video that says your technology stack is dead. A thumbnail of this video looks more or less like this one:

The video is controversial, does not give real examples and ignores many aspects.

One day you have a flooded wall on LinkedIn and it turns out that over time the technology will no longer be supported (or there is such a risk).

It's not your fault, but you have to migrate to Next and Vercel. The first problem arises. Your code is so strongly tied to the Gatsby ecosystem that moving it will not be trivial and will take a lot of time. How we can deal with such risks?

It is very important to not trust every influencer. Many of them create panic and decrease or multiply certain problems and all just for the sake of views.

Code coupled with the framework

In Gatsby for the files based on which the framework generates static pages, we usually have some kind of GraphQL query and JSX code.

It is a request like any other. What if the technology we migrate to does not have GraphQL but something else? The data will have the same shape, but the form of the query will be completely different... It may be a HTTP request for example.

This shows how our code for generating the page has been tied to a particular technology. If you would like to display the page in Next, copying this file is not enough - major changes are needed.

Detaching from Gatsby

We have to use a pattern called a facade. The pattern involves wrapping an implementation of another module (most often a library), in order to avoid using it directly in code.

Thanks to this, the replacement of the library will get around without any problem. Take a look at the following example:

Note the absence of any reference to Gatsby. There are no queries. This component can be used also in Next, pure SPA React and others.

Now we need to apply changes to our page file.

By implementing such an approach we reduce the coupling of the business sphere of the application with a particular technology.

It's like writing SQL queries manually in the controller, and later when migrating to MongoDB - you lament that you have 300 files to change, instead of just one.

You can read more about this pattern in this article.

Usage in Next and Gatsby

As I promised so I will show. See that now we have the opportunity to use the same code in two differently working frameworks.

Firstly, we'll use it in Next.js:

Secondly, we'll use it in Gatsby:

Keep a healthy mind

You may feel the need to write facades for any library - if you've encountered this for the first time, I'll tell you right away that it's natural and you don't need to go to a psychologist🍷.

It is worth applying this pattern in the following cases:

It is also worth mentioning that the implementation of this pattern is an extra minute of work. With a snippet in the code a few seconds, and then it saves tons of money and time.

Summary

Would you rather migrate from Gatsby to Next in an hour? Or would you prefer a few days?

The choice is yours, and the truth is that the porting technique makes a difference. Of course, everything is a calculation of profits and losses.

If you enjoyed it, be sure to visit us on Linkedin where we regularly upload content from programming.

Someone wise once said - "design patterns are there to know when not to use them".