The goals of this week
I know it's been a while since the last Dev Log entry, but things have been full-steam ahead for us at OMNIUX! I intended to release this blog post a few weeks ago, before one of our client's websites went live. However, the focus on getting the site completed and working out the kinks took priority over the blog post. With that being said, let's get back on track and discuss how we build modular frontends with Nexus!
Website builders and their issues
We plan on hosting a huge variety of websites on Nexus. We already have quite a few diverse client site designs in the pipeline, and we need a way to control how the site looks without over-burdening our frontend. There is a delicate balancing act at play. We want to have as much granular control over our UI as possible, but we also want to make sure that network payload stays at a reasonable level. We can't afford to send 10 Megabyte packages to a client device, it would just be too heavy.
An issue I've noticed with website builder tools such as Wix or Squarespace is that they have an almost complete over-reliance on pre-built themes. The same can be said for Wordpress websites. They rely on large ready-made assets with variables to make minor changes to images and text. The reason most of these website builders do this is due to the way they are built. Almost all of these websites send enormous payloads to the client-frontend, usually in the form of raw JavaScript, resulting in long load times and sometimes degraded experiences on Mobile. They utilize huge caching networks in order to serve content closer to it's users, usually at enormous cost in network egress.
Nexus is uniquely designed in that it does not need to worry about the same issues these website builders currently face. The website development part of Nexus is built using NextJS, meaning that all webpages are built ahead of time using static site generation Static Site Generation (SSG), and React Server Components (RSC).
Static Site Generation, On-Demand Revalidation, and Edge Caching.
Static Site Generation is not unique to Next JS. it has been a staple of web frameworks such as Jekyll and Hugo for just over 10 years. However despite not being a first mover, Next JS allows for more flexibility when compared to these frameworks. Most notably On-Demand Revalidation.
When sites are generated using SSG; at build time the compiler makes a network request to our Nexus API and pulls all relevant page data for that website. It uses this data to generate a static HTML copy of the webpage, and this is what gets served to our visitors. On top of this, the content is cached inside of Vercel's Edge Network, allowing for near instant page load for anyone across the globe. By reducing the overall amount of JavaScript required in the bundle of a webpage the browser is able to load websites in as little as half a second.
SSG generates pages at build time, but when a website content is updated in Nexus, we would need to regenerate the HTML for that webpage and re-distribute that across Vercel's Edge Network. Thankfully, On-Demand Revalidation handles this all for us. With On-Demand Revalidation, everytime we save changes to a webpage in Nexus, we send a request to the NextJS website, telling it that the webpage needs to be regenerated. This happens behind the scenes and takes a few seconds to complete. Once complete, visitors to that web page will be served the newly revalidated copy of the web page. This is what helps us stand out against Wix, Squarespace, and Wordpress.
Because we only use web resources to build static HTML when needed, rather than per visitor request, we save an enormous amount in server costs. our spending is so low, we could process over 20 million of these revalidation and re-cache requests and it would still cost less than $5.
Building Blocks
I'm starting to bore myself with all this server talk, so let's talk about something more exciting. Frontend!
In Payload we have something called a Block. A block can be thought of as a re-usable section of a website such as a Testimonials Section, Product Grid, Logo Cloud, etc... Nexus incorporates these blocks which allow users to place them anywhere in the page, as well as edit the content inside of each block. As an extension of this concept, we wanted to give users as much control over their blocks as possible - allowing them to not only adjust styling and animations of premade blocks, but also create entirely new blocks from scratch.
The way we do this is quite simple. Payload blocks can contain arrays of other blocks. We are able to create a recursive "Content" block which accepts rich text, media, buttons, and other blocks (including Content blocks) to generate truly unique content. Think of each Content block as a div, and that's exactly how we handle the rendering on the frontend. Additionally, we allow for dynamic styling either with inline CSS, or using our pre-made theme templates which replace a collection of CSS variables. These variables are passed into a Tailwind CSS config file which ensures all styling on the site matches the theme.
The result
All of this work has culminated in the development and deployment of our first ever website using Nexus - Cactus Country Waste. This entire frontend has been designed from the ground-up to be as dynamic and fluid as possible. As we look to add more websites to NEXUS, we're sure to run into some style conflicts. Luckily, the Staging environment we set up in the previous Dev log will allow us to anticipate these issues before they become apparent.
Wrapping up
Things are full speed ahead for us here at OMNIUX. Payload version 3 recently went into Alpha and comes jam packed with a ton of features we hope to bake into Nexus. As we look to grow the features of Nexus, we'll look at smoothing out some of the slightly rougher edges of the UI builder, as well as migrate the current OMNIUX fully over to Nexus. Join me next week as I discuss the implementation of our Email template engine