When Raspberry Pi Said No to Node: How We Rewired Our Next.js App

Hey, everyone. Welcome to the session where I'm going to talk about a story, actually, it's a storytelling session more than a tech session. I'm going to talk about how we had to rewire our Nexus application when we had hit a constraint from a customer. So, that's all about it, this one. But along with the story, I'm going to bring certain technology aspects because without that, the story would be incomplete.

So, to get started, let's get started with an unexpected rejection story. So, unlike most of the time, let us start this presentation with an unexpected rejection story. And the story goes like this. Just picture this in your brain, like 2 AM, and we have just finished deploying our brand new Nexus application for an EV client. And then the application looks really awesome. It's a beautiful dashboard, tracks real-time battery data, runs perfectly fine on production, like the environment that we had tested. Everything was so good.

But what happened next day morning? Got a call from the customer that this application has to run on Raspberry Pi and there is no Node.js. It's not like that Raspberry Pi doesn't support Node.js, but this particular customer was not keen on using Node.js because they already had a proprietary server, a web server, application server, where a web application can be hosted and it can run easily. So, they thought Node.js will be an extra baggage. Let's not go for this one. But when we heard about this one, it was like, no Node.js, no party, because everything was built with an assumption of Node.js will be there.

So, hey, this is Tapas. I'm a full stack developer. I call it a demand stack because after spending a couple of decades with software engineering, software development, kind of feel free to go across different technology. I have a startup called Creobase Technologies and an open source community called React Play, which was also awarded as, I know, one of the best React open source community in previous React Summit. I'm an educator at TapaScript. That's my YouTube channel as well. The handle is there. You can check it out. I write blogs, technical blogs on Free Code Camp and also an open source enthusiast. So, that's about me. All right. So, we spoke about the unexpected rejection, right? This talk is mostly about what happened next after the rejection. How we rewared our next day's application to run on a restricted hardware without Node.

At the same time, what kind of performance lesson that we had learned, how we made sure that the performance is not degrading, and what actually made us rethink that how a React application should be built, right? So, I'm going to talk about the initial architecture that we started with, then the problem we faced because Node.JS was removed, then our investigation phase, and then how we rewired the entire application. I'll conclude this presentation with the lessons that I have learned. One thing, though, important to mention, in the entire course of doing this, this code is something we felt like very true. You know, every project is an opportunity to learn, to figure out the problems, challenges, and to invent and reinvent. It's so true. Okay. So, let's get started with the architecture, the initial architecture.

The initial architecture goes like this. So, this is a battery management application for electric vehicles. It fetched the data matrix, the battery matrix, basically from IoT sensors, you know, and then processed the data through APIs. And from the API layer, we could visualize it with interactive charts, dashboards, etc. Very simple. And the app was built with NixJS AppRouter. That time it was 14, and then we migrated to 15 later point in time. D3JS for all kinds of visualizations, and of course, edge caching for performance reason. And as you know, like, if you're a NixJS developer and NixJS lover, you know that there are things like server components, SSR, ISR, all these techniques that you bring in.

There's the power of using NixJS as a framework. And you make your application like super performant. You take care of SEO. You take care of many other things that an ideal application would like to see in itself. But we assumed one thing, you know, we assume that there will be NixJS. But what it turns out that when you deploy to an embedded hardware like Raspberry Pi, this particular assumption can be broken very, very easily. That's exactly happened with us, okay? Now, next section, I'm going to talk about what was the problem with NodeJS.

So, when you heard that NodeJS is not there, and we have built the entire application, keeping in mind that the NodeJS will be there, and a lot of power of NixJS framework that we have built in inside this application, so what kind of problem we've started facing or started chalking out where NodeJS was not there? As a developer, when we start between things like SSR, like server-side rendering, the dream of server-side rendering, and the hardware realities, what we figured it out, like, NixJS expects a server for things to run. And the kind of server that the customer given to us, it wanted basically static files. So, from the dream of using SSR, ISR, and all these things, to the fact that we have to use things like static files, some people will say, like, 90s, you know, you have just HTML, CSS, JavaScript, you don't have all these fancy things from framework anymore, that was, like, a little bit dream shattering for a tech team like us, like, which always want to work on some modern techs and all. So we figured out the constraints are basically this, no Node runtime, limited memory, this is second point. We were thinking that it will go to cloud, run on, like, you know, age, things will be super good, but now it is a tiny hardware, so you have the memory limitation, and also client came back with another thing, like, you have to do, you know, offline, so it should be served offline. It might not get the latest data when it is serving on offline, but of course, it should not break, it should not be a blank screen when somebody accessing this app on their iPad or somewhere. So our NixJS app suddenly couldn't render pages, because no Node.js, it could not run the API routes, no Node.js, and then the D3 charts that we have developed, it started choking, because there is no concept of GPU acceleration, you are using this hardware, no streaming APIs, we were dreaming to use that, and that started creating a lot of constraints for us. So as we understood, okay, this is what the life of this application, life of the developers without Node.js, let us start the investigation.

So we started the investigation, and there are two things, two paths that we realized that are there in front of us. One, rewrite everything that we have written in pure React spa mode, single page application mode, no more framework, because the power of NixJS itself, we are not able to use, right, so what is the use of using the framework? So let's get rid of that. Second thing, somehow make NixJS behave statically. Okay, we have spent our hard-earned time, you know, months on building server components, layouts, APIs based on various Node features, what to do, should we throw away and rewrite? We decided, okay, let's not throw away the implementation that we have done, let's try to dissect NixJS. Let's find out what parts of NixJS actually need Node.js, and if we can figure that out, maybe that portion of it needs some rewrite, but other portion we can keep it as it is, because we also have to deliver the customer, and to some extent, I admit that this was our mistake, probably we didn't understand the communication that where exactly this application is going to run, and that's one of the learning I want to call out towards the end, so I cannot really ask for too much of extra time to the customer that I have to rewrite this application, right?

So here are the findings. I'm going to go through them one by one very slowly. What we figured out, the SSR, server-side rendering, and we had written few API routes, those are Node-bound, because you need Node.js for making them work, hosting them, etc. The UI part, where it comes to the component, basically, can we export this component like HTML exports? If we can do that, that means at the end of the day, it is just a mere HTML, logic in JavaScript, and all the beautification is in style, and that is exported, that you can take it portable anywhere in the world, on any server, any application server. So that is good. So it means that if you can statically export the UI, I think that part is not dependent on Node or the Node-based server, great. Then the client components, we had a dream of using server components because since NixJS, 14, AppRouter, and then 15, the server components are everywhere, right? It is sold to all the developers. But as a developer, I think we always have the tendency of looking into that shiny, glowing piece, then too much putting our thoughts on whether that shiny thing is for me, do we really need that? So if you look into this application, the person of that application is someone who is going to go to check a lot of electric vehicles, they want to plug a device, a hardware to the battery, they want to collect the data, and on the iPad, they want to view certain things and take some calls. That's the person. Now, this person is never ever going to use this app publicly. It's not something that on a Google search, you should get this app, right? It's a very private app. So SEO is not at all a matter here, right? Why were we thinking about server components, server side rendering and all these things if SEO is not at all in picture? We can actually bring this app completely from the server side to the client component. And that works everywhere. You don't have the dependency. And if it is that way, we can easily export it and make it working on the browser, any browser. Then the last thing was about the ISR part, incremental static regeneration, where we didn't want the data that was shown on the UI to be still. After a certain period, the data should be refreshed, and users should be able to see the latest data on the app.

After a certain period, the data should be refreshed, and users should be able to see the latest data on the app. This is how we were using ISR in built-in XJS. Now, if Node.js is not there, ISR is tricky. But can we replace it? Yes, it is replaceable. It is replaceable with the age-old technology. We're going to talk about that. So with all these findings, we felt, let's go static, but in a smart way. Okay, so that brings us for rewriting this entire app where we can use the mix of Next.js static export without getting rid of Next.js and the lightweight browser runtime. Okay, now I'm going to talk about various steps that we had taken and ensure that this application was delivered with the constraints that were given to us. It was like, you know, we were tricking Next.js to think that it is running an SSR, but it was just baked and refreshed locally. That's what we did.

First thing, we should have pre-rendered views with Next.js export capability. So when we use Next.js export, what it does basically, it is not going to make the build artifacts or the output in the traditional Node.js environment way. It is going to make the static export of your HTML, CSS, JavaScript in such a way that in an older version of a server, non-Node server, for example, Tomcat, or the kind of server that our customer had, you can easily host your application, because merely it is HTML, JavaScript, and CSS. There is nothing like, which is very much tied with Next.js or Node.js over there on the build artifact. So that was the first configuration that we enabled. First step.

Second step that we did, we had a lot of APIs written using the API routes of Next.js, and as Node.js is not there, we had problems in hosting those. So we thought, okay, let us make a lot of calls on the client side. So from server side, let us start pushing the things on the client side using the mirror fetch call. So if you are able to view this slide, you can see there are certain sections where we are doing that fetch, and there is a data URL, I'm coming to that, what is that data URL, and we're going to fetch the data and going to show that. So there is no server side rendering, there is no server component, pure client component, do a fetch call to something which is not hosted on remote. Rather, the data is quite local. So get periodic JSON data dump from your hardware devices, so that we can actually render that on D3. The data dump looks like this. It is a timestamp, what is the charge, what is the temperature, different kinds of statistics over there, and cache that data locally with IndexedDB. So IndexedDB is something which is lying on your browser, right? And if we are able to cache things on IndexedDB, we can actually give a lot of uplifting in the performance. So every time we get a data, we can put it in the IndexedDB, time period manner, and then serve the data to the UI from that. So we made sure that things are quite faster, because everything is kind of loading on the browser seamlessly.

So we made sure that things are quite faster, because everything is kind of loading on the browser seamlessly. And then the last part, the ISR part, we kind of tricked it using a cron script. So what was happening from the sensor, which was plugged to the EV device, it used to get the data, and on a frequency, it was a Python script, on a cron frequency, it used to dump the JSON in a location. We used to pick the JSON, identify what is the latest JSON data came for the D3 to show, and that is the fetch call used to get to the JSON data, and then we'll show it to the user. So the entire thing, which was like very much Next.js based, very much Node.js based, we had to rewire it to ensure that it runs in that limited constraint or limited hardware that was given to us. There are times where you cannot really go fancy. You have to kind of fall back to something which might be very minimal, which might sound not a best practice, but something in that particular environment, probably the best thing to do. So when we ran it first time, what happened? It was very fast. Initially, with the Next.js, Node.js, that environment, we're putting it in the cloud, you know, age, it was taking like a second, a few seconds, not a couple of seconds, less than that. But now everything is local. So it takes around like 500 milliseconds from the time that we could get the data from the hardware. The moment we get the data, everything is very local, right? As it was local, no server hops, no hydration lag. All this thing is completely gone. So actually, what happened, the irony over here is like Raspberry Pi say no to Node.js, basically our customer said. But we ended up having something which is much more performant, much more faster, and customers were happy. So it was an accidental discovery, I would say, that going static can be smarter than dynamic when you have certain creativity into picture that you can bring in. And in this case, I think that is what worked. So this is what we had done at a very high level.

If you want to kind of get more deeper about it, I will leave you with some of my social links. You can always reach out to me. We can discuss more about in depth how everything happened in the layer. So the lesson that was learned for us at a high level, I want to call them out. Server-side rendering, excellent thing, a fancy thing with React, makes this as a framework. But that may not be always the answer. As I told, as a developer, we tend to do this so much. We tend to use this so much because framework gives us. But don't go blind with what works for the most. Sometimes what happens, the age or static also wins, the way that we have seen over here. Even though those are least used cases. That's the first thing.

Second is think hardware level. Before this project, frankly, my mindset, my team's mindset was not this. We were never designing our application for constraints. But after this incident, we started thinking we should design for constraints, not for the clouds. So think of odds while thinking about all the happy parts that you thought about for your product or the application that you are developing.

Third is understand your tools and frameworks very well, very deeply, so that in a situation like this, you won't abruptly leave or give up from your framework and go to something else because you're hitting a limitation. Being in the framework itself, you can tweak a lot of stuff if you know how working off it is kind of underlying. This was not a story just about the Raspberry Pi, to be very frank. This was the story of our adaptability. And as a developer, as a team, we adapted very well.

If you are using an XS app and if you hit things like this, just keep in mind that you can make things much, much portable. It is very much possible. So, thank you. And if you are ever debugging some of these things or having a caching issue, like we had at 2M, remember that there is always something worse than that, that we faced at the last moment, where there was no Node.js server on Raspberry Pi, but still we could pull it. So you can do that as well. With that, I will end this presentation. Please stay connected and you can connect with me on LinkedIn and various other places. As I mentioned, I have given this as a very, very high-level overview. But in case you want to get deeper with me understanding each of these layers, I'm always open. I can definitely talk more and maybe there are more further better ideas that will be coming up when we're discussing together. So with that, thank you very much.