You don't want to Server-side Render your Next.js App

Rate this content
Bookmark

Next.js is a fantastic framework; it provides many unique features, helping you build any web application effortlessly. But when it comes to choosing the right rendering strategy for your pages, you may face a problem; how should I render them? Should I statically generate them at build time? Should I server-side render them at run-time? Well, the answer is surprising. server-side rendering is rarely the best option, and let's explore why (and how to solve this problem!)

28 min
21 Jun, 2022

AI Generated Video Summary

Next.js is a framework that allows for client-side rendering and easy page transitions. Server-side rendering offers a more secure application and better search engine optimization but requires a server. Static site generation provides outstanding performance and scalability but has limitations. Incremental static regeneration solves the problem of rebuilding the entire website. Choosing the right rendering strategy depends on the specific scenario, and for e-commerce websites, static site generation with incremental static regeneration is recommended.

1. Introduction to Next.js and its Benefits

Short description:

Hello, everyone! I'm Michele, a senior software architect at NearForm, and the author of Real-World Next JS. NearForm is a professional services company specializing in Node.js, React, Next.js, TypeScript, and maintaining open-source packages. Now, let's dive into Next.js. It's a beautiful framework that allows for client-side rendering, providing a native app-like experience with easy page transitions and lazy loading of components. Plus, it doesn't require a server if you don't need one.

Hello, everyone, and welcome to my talk, You Don't Want to Serve a Set Renderer, Your Next JS App. Before we start, let me please introduce myself really briefly. I am Michele. I work as a senior software architect at NearForm. I'm a Google developer expert and a Microsoft MVP. I am also the author of Real-World Next JS, which is a book that, as you may guess, talks about Next.js. So if after the talk you'd like to hang out and talk about Next.js, please feel free to reach out. I'd be glad to talk with you.

A couple of words about NearForm. We are a professional services company, and we're specialized in Node.js, React, Next.js, TypeScript, and whatever. We are maintaining a lot of open-source packages that get downloaded 1.2 billion times per month cumulatively. So if you're looking for a remote-first job and you're really committed to open source, please feel free to reach out. I'd be glad to introduce you to the company.

But that's not why we are here, so let's talk about Next.js. First of all, what is Next.js? Why do we want to use it? And why is it so beautiful? When React started to be a thing, we only had client-side rendering basically. So that was the norm. We basically generate a big bundle and serve it over the net. This bundle will contain the whole application and as soon as it gets transferred to the browser, the browser will read the file, the JavaScript file, execute it, and we'll have the DOM ready to be browsed.

So basically, the problem with this approach, but we will see many problems later on, is that this is what we see when we first download the bundle. So while it's downloading, while it's executing, we see a spinner. After several seconds, we will see the complete page ready to get browsed. So this approach has some cons and has some pros. So let's see why it might be a good or a bad choice. So first of all, it makes you feel your app, like it's a native application, and that's because page transitions are really easy to handle, and you don't have to refresh the page every single time. Every time you click on a button, for example, and you go to another page, you don't need a page refresh. You already have all the components you need that gets lazy loaded directly into the browser. So for example, you're in the home page, you click to read an article, the whole DOM refreshes, but the page doesn't. So the DOM React will swap the content with the new one, and will execute lazy components that haven't been executed yet during the first load. One other great thing about client-side rendering is that you don't need a server. And if you need because you already have one and you want to serve your client-side application from a server, it doesn't require much power.

2. Pros and Cons of Server-side Rendering in React

Short description:

And there's no server workload, which is pretty good because it's really easy to scale. But if you don't have a server that's still good, you can just put your files, static assets, on a CDN on S3 on AWS, for example, or using Cloudflare pages, or whatever. And you just can host an entire application directly from something that doesn't need a server at all. While this is good for many things, it also has some problems, for example, with search engine optimization. React is not particularly good for search engine optimization, especially in markets outside of Europe and America. Additionally, React has a slow initial page load time. Server-side rendering offers a different approach, providing a more secure application, compatibility for non-JavaScript users, and enhanced search engine optimization. However, it requires a server and comes with higher maintenance costs.

And there's no server workload, which is pretty good because it's really easy to scale. But if you don't have a server that's still good, you can just put your files, static assets, on a CDN on S3 on AWS, for example, or using Cloudflare pages, or whatever. And you just can host an entire application directly from something that doesn't need a server at all.

While this is good for many things, it also has some problems, for example, with search engine optimization. We all know that React, it's not particularly good for search engine optimization, which is true. But it really depends on the market you care about. For example, if you care for the European and American market, we know that Google is the number one search engine and Google today is capable of indexing React content. But there might be other search engines that are more popular in other continents, such as Asia, for example, or Africa, that does not read React generated pages. So if you truly care about those continents and markets, you should definitely look into something different for building your application.

Another con is that React is really bad for the initial page load time, as we saw. So the first time you download a bundle, you just have to wait several seconds in order to be able to browse it. So this is why we begin to see server-side rendering as a different way for approaching React rendering specifically. With server-side rendering, this is what you get as soon as you request a page. It might take a couple of seconds, because the server still needs to render the application on the server side, but eventually it will send you the complete page ready for browsing.

So this approach also has some pros and cons. Let's see them. One pro, the application might be a bit more secure. That's because you might have server-side cookies, for example, for authentication, and you don't have to share those cookies with the client, which makes your application more secure. You can hide some requests from server to server without exposing them on the client. That limits the possibility for a man-in-the-middle attack, for example. Also, you end up having more compatible websites. If you don't have JavaScript enabled, you will still see the first render for your application. Search engine optimization is enhanced thanks to server-side rendering, because you basically end up having a product which is the same that you might have with Ruby on Rails, JavaScript Boot, Laravel, or whatever. The content can be highly dynamic, and you can have that kind of dynamism directly on the server. So, depending on the user that is currently logged in, for example, you might decide to render different things directly on the server. Of course, it also has some problems. For example, a server is required. Every single request gets rendered on the server and transmitted to the browsers once rendered. So, there will be an higher server workload, higher maintenance costs, because you will have to maintain a server. And this is costly.

3. Static Site Generation and Hybrid Rendering

Short description:

Static site generation is a third option that allows for easy scaling and outstanding performance. It serves static files directly to the browser, making it secure and eliminating the need for server-side rendering. However, it has limitations such as no dynamic content on the server side and the need to rebuild and redeploy the entire application for changes. React offers hybrid rendering, allowing different rendering strategies for different pages and parts of the application. Client-side rendering requires waiting for the JavaScript bundle to execute.

So, you have to scale the server horizontally, for example, if you want to add more servers to serve your application, because you need to scale, or you need to add more power to the server you already have if you want to scale vertically. That depends, of course, on how you want to scale your applications.

So, there is a third option that we are going to explore, which is called static site generation. So, just like server side rendering, this is what you get when you request a static site generated page. So, basically as soon as you make a request, you don't need to server side render it, because you already rendered it during build time. So, you will serve your application as static files directly to the browser.

This approach has pros and cons of course, one pro is that it's super easy to scale, and that's because again, you don't need a server. You already have static assets, you put them in a CDN, on S3, on wherever you want, on a bucket, and you just serve them as static assets, because you don't need to render the page every single time you get a request. So, that leads to outstanding performances, because the page is ready, you don't need to render it either on the client or server side. So, the page is done, you just have to transfer it. It is really secure because you don't have a server, so there's no way to attack the server directly, so that's another thing to keep in consideration.

Of course, again, it has some cons. Let's see them. So, no dynamic content is allowed on the server side, because you don't have a server, so you can't render specific things for a specific user on the server, because you don't have a server at all. It relies on client-side rendering for all the dynamics part of your application. So, for example, if you are on Instagram and you're scrolling the feed, you could generate the feed page with the client-side rendering, sorry with static side generation, but eventually you will need to wait for the client to understand who is the user that is logged in and then render the content which is specific to them. And one other thing, which is really annoying, I would say, is that if you need to change something, for example, a typo on the home page, you will need to reload and rebuild and redeploy the whole application. That can be fixed with incremental static regeneration, but we will see that in detail later on.

So one nice thing about React is that you don't have to compromise, you don't have to choose one rendering strategy for the whole website. But you can do that granularly at the page, when you basically render the single page. This is called hybrid rendering. So basically you might say, okay, the home page for this website will be a statically generated page. If you are in a blog, the post page can be dynamically generated with the server-side rendering, for example. That's cool. And some parts of the application can be rendered on the client-side only. So you can choose how long basically the user has to wait before assessing the content. Let's see in detail what I mean by waiting. So for example, this is client-side rendering, right? We make a request and as soon as we make the request, the server or the CDN will send us an empty page. As soon as the JavaScript bundle containing the React application gets executed, we will start seeing the application getting mounted on the browser. So as you can see, the server will be really fast in sending a response, but we will have to wait.

4. Incremental Static Regeneration and Caching

Short description:

With server-side rendering, we ask the server for a specific page, wait for it to be rendered correctly, and then transmit it to the client. Incremental static regeneration solves the problem of rebuilding the entire website for every change. By setting a revalidate value of five minutes, the page is regenerated for each new request after that time. If nothing changes, the cached version of the page will be served.

So as time passes by, we have to wait for the page to be loaded. With server-side rendering, it is a bit different. We ask for the server for a specific page. We wait milliseconds, hopefully, or seconds depending on how good we are at writing React or how slow the APIs behind our applications are. And then when the page is correctly rendered on the server, we transmit it to the client.

Static site generation looks like the perfect match. As soon as we make a request, we get a complete response. So this is why I like to talk about incremental static regeneration because it basically solves a big problem we are having with static site generation. So we don't want to rebuild the whole website every single time we make a change, because this is good, what we are seeing right now on the slide, it's good. But for example, if I change my mind and I start loving Irish setters, for example, I will have to rebuild the whole website. But thankfully, with incremental static regeneration, that's not the case.

So let's see how it works. So basically, this is our page right now. This is a home page for my website, because I love English setters. And so let's say we have a value in our getStaticProps that is called revalidate, set to five minutes. So every five minutes, we have to revalidate that page, meaning we have to rebuild it. So I publish the page. After one minute, one user comes to the website and they will see that page. After three minutes, another user comes to the website and will see the exact same page. The same of course for the third user that looks at our website after five minutes. Remember, this is lazy. So if no users will see the page again from now on, Next.js won't reload the application itself. It won't rerender I would say the home page in that case. But we say that every five minutes when a new request comes, we have to regenerate the page. So that's what's happening basically. We regenerate the page and the next user after five minutes will see a totally new page with a new background color with an Irish setter instead of an English one and that's what will happen after four minutes for another user and after five minutes for another user. And again, from now on after five minutes if another user comes to the website we will need to revalidate the page. So basically if nothing changes we will see server-side render the page. But we will put some caching headers so that it will be able for our cache to serve a cached version of the page. If nothing changes we will still see the same page.

5. Avoiding Server-side Rendering and Playing Smart

Short description:

React server-side rendering is not efficient yet. JSX requires a lot of server-side effort, slowing down the server and requiring scaling. Going serverless solves the scaling problem, but it comes at a cost. For example, using Google Cloud Functions can cost thousands of dollars per month. Compute Engine is cheaper but still has server-side rendering issues. To overcome this, it's important to play smart and consider the specific scenario.

Okay, but that said why would I want to avoid server-side rendering? So it's my opinion that React server-side rendering it's not really efficient yet. That's not Next.js fault. This is no one fault but JSX. JSX is not really efficient as a markup language or I don't know how to call it, but it's not really efficient when it comes to server-side rendering.

So every single request requires a lot of effort on the server-side which slows down the server, so you need to scale it, so you need to add more computing power, more servers to keep up with increasing demand for your application pages. So it might be easy for an architect at a certain point to say, yeah go serverless. You know you don't have that problem if you go serverless. You basically deploy your Next.js application on AWS, Lambda, Google Cloud Functions, Azure Functions, whatever, and you don't need to scale. That's correct but at what cost? It's not cheap.

So let's see a little example on Google Cloud Platform. Let's say this is the price of Google Cloud Functions. So let's say for the first two millions of invocation per month we don't pay anything. Beyond two millions we pay 40 cents every million of invocations. Sounds cheap right? Well we will see later on how much it will cost. As you can see you also pay computer time every 100 milliseconds. I have no idea how to pronounce those small numbers so forgive me. Networking. You also pay for networking. So first gigabyte of transfer traffic are free then you pay 12 cents per gigabyte. Sounds cheap right? So let's say we have an application that handles 100 concurrent server-side renders requests per second which leads to 259 millions and 200,000 requests per month. It's incredibly hard for me as an Italian to say English numbers! I'm super sorry but it's a huge number of requests right? The average execution time, let's say is 300 milliseconds. We can use the cheapest RAM option which is 128 megabytes and we will require around 100 kilobytes of bandwidth per execution and okay and we will need more but let's say for keeping it simple that this is how much we will be transferring. How much would it cost? Yes, using Google Cloud Functions for example it will cost three thousand dollars per month but it will scale of course it will scale but if you get more requests the price will get higher and higher so it's not really sustainable for large-scale applications. If you go back for example on Compute Engine with the two virtual CPUs eight gigabyte of rams you will pay like fifty two dollars per month which is way cheaper but still you'll have the problem of server-side rendering because you will need to scale it so eventually you want to go back to serverless but it will cost a lot so you want to go back again to Compute Engine for example but it won't scale or it will become really costly. So how do we get out of that bad situation? So my suggestion would be play smart depending on the scenario. So let's start with an example scenario. Let's say we want to build a social network app just like Instagram or whatever so I want to play a little quiz game with you. I will give you a couple of seconds for thinking of an answer so this is the first question. We already discussed this let's see if you were paying attention. So let's say we have to build a feed page feature for our application for example on Instagram when scrolling the feed page the the home page of Instagram so the content it's really dynamic and it's custom for every single user it doesn't need SEO and that's because the user is logged in so the feed it's really specific for users it serves a lot of static assets and it's basically one big common page for every single user.

6. Choosing Rendering Strategies and Security

Short description:

What would you choose for that? Would you choose server-side rendering? Would you choose server-side rendering with a caching layer? Would you choose static side generation and incremental static regeneration? Or would you choose static side generation and client-side rendering for displaying dynamic content? In my opinion, the correct answer is static side generation with client-side rendering. That's because you don't need server-side rendering. So let's go with a single post page. It serves big static assets, photos, videos, and there is one single page for every single post. Account setting page needs high security and is a good case for server-side rendering without any cache.

What would you choose for that? Would you choose server-side rendering? Would you choose server-side rendering with a caching layer? Would you choose static side generation and incremental static regeneration? Or would you choose static side generation and client-side rendering for displaying dynamic content? Let's think about it.

So in my opinion, the correct answer is static side generation with client-side rendering. That's because you don't need server-side rendering. We know that it will be different for every single user, but the page is the same. The header will be the same. The footer will be the same. It only changes the content. So the content can be lazy loaded on the client. Also, if you think of a scale of Instagram, this is too big for many of us, but you don't really want to server-side rendering that many requests. It's becoming really costly. So let's go with a single post page. So we see a nice photo. We click on the title, and we see the full post with the description and the comments and whatever. So there are a large amount of pages. It will need a good search engine optimization because this is how we get into Google with the individual posts, not with a homepage. It serves big static assets, photos, videos, and there is one single page for every single post. What would you use? So answers are the same as the previous answer but in my opinion this is a good case for server-side rendering to cache. Let me explain to you why. We will be server-side rendering this for the first time and we'll be serving a caching response every single time a new user asks for the same post. After, let's say, one hour, thirty minutes, one day, we will purge the cache and re-render it, mimic how incremental static regeneration works. If... okay, we will see later on, with another example, what might be a good alternative to that. But for the moment, let's keep our thoughts on SSR and cache.

Okay, last one. Account setting page needs high security. It doesn't need search engine optimization and it's protected under authentication. We know for sure that this is not the most visited page of every account, right? So that might be a good case, in my opinion, for server-side rendering without any cache. We don't want cache, otherwise the risk is that I do login and when another user logs in they will see my account. This is not what we want, you know. But also we have server-side cookies which are more secure than client-side cookies.

7. Rendering Strategies for E-commerce

Short description:

For an e-commerce website with a home page that requires high performance, search engine optimization, and occasional content updates, static site generation with incremental static regeneration is recommended. This approach allows for static rendering of the page with excellent performance and revalidates the page after a specified time. For individual product pages, static site generation with client-side rendering is suitable, as the content is relatively static and can be controlled on the client side using API calls.

So that's a good case for server-side rendering and we can afford it because there are not many requests to that page specifically. So let's go with another example. Let's say we want to build an e-commerce. So the home page, it's really important for every single e-commerce, right? We need high performances, awesome search engine optimization, and the content changes from time to time. Not really frequently, but let's say a couple of times per week, okay? So what would you choose? I'll give you a couple of seconds. My opinion is to go for static site generation and incremental static regeneration without a long revalidate time. So that you basically statically render the page, the performances will be awesome, and you will revalidate the page after, I don't know, one day, two days, one week. It really depends. You can choose. So let's go with a single product page. Let's say that in our e-commerce, we have 250 products, we need awesome SEO for every single product, need awesome SEO, great performances, some dynamic data, for example, stock quantity, I don't know, for example, delivery time, depending on where you come from or where to ship the merch, etc. What would you choose? I would choose static site generation and client-side rendering. And that's because the product page doesn't really change that much. Otherwise, we could have chosen incremental static regeneration, but it doesn't really change that much. And the stock quantity can be controlled on the client side via API calls, for example. And the same can be done with external APIs for delivery.

8. Incremental Static Regeneration with Fallback

Short description:

For large e-commerce or blogging platforms with a billion pages, rendering all pages at build time is not feasible. Instead, we can use incremental static regeneration with a fallback. This allows us to build the most popular posts at build time and defer rendering the rest to request time. Caching headers and revalidation enhance performance.

One thing to mention, and I wanted to mention this previously when talking about the social network, but it's worth mentioning now, is that if we have a very large e-commerce or a blogging platform, for example, where we have one billion pages to be rendered, of course we can't render one billion pages at build time. It will take forever. So we could choose to go with incremental static regeneration with a fallback. There is a fallback value in the incremental static regeneration setting, so that we can say, I will build, at build time, the hundred more popular posts or articles in my e-commerce, whatever, and I will defer the rendering phase for all the other posts or articles at request time with incremental static regeneration. So I will basically generate 100 posts that are the ones that get searched the most and the other ones will be rendered at request time and we will have some nice caching headers thanks to incremental static regeneration and revalidation of course.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
WorkshopFree
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit 2023React Summit 2023
139 min
Create a Visually Editable Next.js Website Using React Bricks, With Blog and E-commerce
WorkshopFree
- React Bricks: why we built it, what it is and how it works- Create a free account- Create a new project with Next.js and Tailwind- Explore the directory structure- Anatomy of a Brick- Create a new Brick (Text-Image)- Add a title and description with RichText visual editing- Add an Image with visual editing- Add Sidebar controls to edit props (padding and image side)- Nesting Bricks using the Repeater component- Create an Image gallery brick- Publish on Netlify or Vercel- Page Types and Custom fields- Access Page meta values- Internationalization- How to reuse content across pages: Stories and Embeds- How to create an E-commerce with Products’ data from an external database and landing pages created visually in React Bricks- Advanced enterprise features: flexible permissions, locked structure, custom visual components