NEXT.js and why you might not need it!
Here I was in my corner of the Frontend world at Bugcrowd, working on the design system and trying to leave my mark, when I get pulled into this project with a tight deadline and which uses NEXT.js as the frontend framework so we can deliver the project quickly.
NEXT.js
Here is a great article if you wanted to read about NEXT.js — https://medium.com/eincode/what-are-the-benefits-of-the-next-js-framework-7c5b083c8d23
This is not the point of this article.
There are lots of articles out there which will describe the advantages and disadvantages of NEXT.js and I do believe that NEXT.js has its purpose and use and that if used correctly, it can be a great tool / framework for a frontend engineer.
What I experienced
Let’s give my story some context first.
- The frontend end application, built with NEXT.js, is to be used by internal staff member to manage the different programs that our users could subscribe to.
- There are multiple micro-services which would need to be accessed to get data for the frontend app. So none of the backend architecture was running close to the frontend application.
- Some of these services are dependent on an old monolith
When I first hopped on this project, I had no experience of NEXT.js nor server-side rendering (SSR) nor static site generation (SSG). NADA.
So I was really keen to sink my teeth into this to get my first taste of SSR / SSG and boy was I amazed and impressed that the pages were being rendered on the “server” and then delivered to the client. During development, compilation of the page would happen when you visited that page! WHAT! WOW! That meant faster boot up of the development server.
Is NEXT.js opiniated about a lot of things? Yes. So what? Do you know how much time engineers lose amongst themselves trying to come up with compromises and then turn these compromises into a working solution? A LONG TIME! So I really liked that it was opiniated.
✅ How do you write pages? SOLVED!
✅ How do you structure your folders? SOLVED!
✅ How do you do routing? Here are some components for you to use — next/router, next/link … SOLVED!
✅ Image Optimization? SOOOOLVEEEEEEEED!
And then came data fetching…
In previous documentation on NEXT.js, the recommended data fetching was to use getServerSideProps . The first time I saw this pattern in the application, it got me questionning the point of SSR…
After following up with previous engineers who worked on the app, the answer was well it is the recommended way by NEXT.js. So I ran some test and surprise surprise… if you have a high latency endpoint you now have a high latency UI. Some pages would make several fetch requests to different services. Imagine wait on all of them and I will admit it. I had to continue that pattern on these pages.
Local development made use of local services and mocked data loaded from json files so it was fast. Run the same application in staging and production…
Pages doing data fetching server side were taking between 1.5s–2.5s to render anything.
Click on a button aaaand nothing happens.. so click again… what is happening… click again…. AAARGGGHHHH. Close tab.
Newer pages built with client side fetching loaded instantly. Yes the different components on the page would go and fetch their individual piece of information and you would have to engineer a loader / spinner. The user would still have to wait for these endpoints to return data but at least they can do other things with your application.
I believe that the reason for us using NEXT.js was so make development fast and easy which it did. However, it also brought this Frankestein of an app with bipolar disorder.
CONCLUSION
- In programming, take everything with a grain of salt
- Understand the fundamental mechanisms of serving website
- Remember the old adage, walk before you run, read about the framework , test and understand what it is doing before blindly following them
PS: Here’s another hard pill
Should I refactor those pages or leave them be… leave your opinions below.
