↓Skip to main content

Full-stack

·4 mins·Tomáš Novák

Our initial thought was to build the entire web solution — both frontend and backend — using a single full-stack framework. It’s an enticing idea, especially considering the size of the team behind the project.

Our research into current technologies revealed that the most widely used solutions today are:

  • Next.js
  • Astro
  • Nuxt

Their common denominator is that they are all programmed using JavaScript (or TypeScript). Beyond that, however, they differ quite significantly.

Next.js is the most widely adopted framework, but since it uses React on the frontend, it has the steepest learning curve. It is also the oldest solution here, dating back to around 2016. As a result, it powers many widely known websites, including ChatGPT.

Astro is another framework that enjoys widespread popularity. It is relatively new, having debuted around 2022. Of all the options listed, it has the easiest learning curve. However, its core focus is entirely different from its competitors. Astro is tailored for content-driven websites that need to deliver lightweight, straightforward pages incredibly fast. As a result, it isn’t the right fit for applications with highly dynamic, rapidly changing content.

The last one on the list is Nuxt. It’s also a relatively established solution, dating back to 2018, but it uses the significantly simpler Vue for its frontend layer. This makes it a great middle ground when it comes to the learning curve. For developers, a major advantage is that you don’t have to fiddle with complex configurations; you simply follow a predefined project structure. It handles complex, highly responsive applications just as well as Next.js, and it is trusted by organizations like NASA.

For data visualization, we need a stack capable of handling more complex functionality. Astro simply isn’t cut out for this, so I had to drop it from our shortlist.

Upon a closer comparison of the remaining two, Next.js and Nuxt, I came to the conclusion that while Next.js is likely the superior framework, it is also significantly more complicated. This complexity isn’t just in its features, but also in the steep learning curve required to master the entire ecosystem — especially React.

Therefore, for the initial rollout of our server solution, I chose Nuxt.

The Nuxt architecture relies heavily on TypeScript’s type safety and strict adherence to project structure conventions. It really is not difficult to get a project off the ground. Connecting to databases is smooth and well-optimized, and the same goes for integrating an MQTT Broker.

However, like any technology, it comes with its own set of drawbacks. The biggest pain point was deploying the application via Docker, where I hit numerous roadblocks, particularly on the backend side. A major issue was that a method thoroughly tested natively on Windows simply wouldn’t work at all once containerized in Docker. This was exactly the case with file handling, for example. Ultimately, I discovered that a solution did exist: it required moving the files into “assets,” after which everything worked flawlessly both natively and in Docker.

All in all, developing an application with Nuxt is fast and, once you master the correct project structure, remarkably reliable. It is certainly a highly efficient route for building even more complex applications, especially for developers who are big fans of JavaScript-based solutions.

However, for a programmer used to a traditional workflow that includes compilation and linking, writing an application in JavaScript or TypeScript can feel somewhat “uncomfortable.” You miss that exact pre-run verification phase capable of catching a multitude of bugs. While you can certainly rely on live syntax checking when working with JavaScript or TypeScript, it still felt to me that a standard compiler would have caught many of these errors much earlier.

This realization applies to all three full-stack frameworks mentioned, as they all share a similar programming approach. Consequently, I concluded that the full-stack route was simply not the way to go for me.

On the flip side, I found that the frontend part of Nuxt, which is powered by Vue technology, suited me perfectly. It’s simple, clean, and well-organized, yet packs a massive punch with a wide array of features.

My takeaway from the successful visualization rollout using Nuxt is as follows:

  • the backend just isn’t the right fit for me
  • the frontend, on the other hand, absolutely is.

Since the Nuxt frontend is essentially just a slightly extended version of Vue, I came to the conclusion that instead of a full-stack solution, I would split the system into a separate backend and frontend.

I will be building the frontend using “pure” Vue.

It will be much better to implement the backend using a compiled language. I’m far more accustomed to this workflow, and I also expect the execution speed and lower memory footprint of such a solution to be highly advantageous.

Building a web application using a full-stack framework like Nuxt is by no means a bad option, but splitting it into a dedicated frontend and backend simply feels like the better approach.