Building Blazing-Fast Websites with Next.js and

Rate this content

Join us for a hands-on workshop where we'll show you how to level up your React skills to build a high-performance headless website using Next.js, Sanity, and the JAMstack architecture. No prior knowledge of Next.js or Sanity is required, making this workshop ideal for anyone familiar with React who wants to learn more about building dynamic, responsive websites.

In this workshop, we'll explore how Next.js, a React-based framework, can be used to build a static website with server-side rendering and dynamic routing. You'll learn how to use Sanity as a headless CMS to manage your website’s content, create custom page templates with Next.js, use APIs to integrate with the CMS, and deploy your website to production with Vercel.

By the end of this workshop, you will have a solid understanding of how Next.js and can be used together to create a high-performance, scalable, and flexible website.

71 min
25 May, 2023


Sign in or register to post your comment.
  • is there a repo for this project?

Video Summary and Transcription

This workshop covers building blazing fast websites with Next.js and Sanity. It explores the benefits of headless architecture and CMS tools like Sanity. The workshop guides participants through setting up the repo, working with Sanity and Next.js, and deploying to production on Vercel. Content modeling in headless CMS and schema creation in Sanity are explained. The workshop also covers using Grok to query content, connecting content with Next.js, and deploying to production with Vercel.

Available in Español

1. Introduction to the Workshop

Short description:

This is Building Blazing Fast Websites with Next.js and Sanity. Natalia Iaffe, a software developer at RangleIO, specializes in front-end development and has experience with headless architecture and CMS like Sanity and Contentful. Nancy, an associate director of digital strategy at Rangle, is also a developer with expertise in headless CMS projects. The workshop will cover the platforms used, setting up the repo, working with Sanity and Next.js, and deploying to production on Vercel. The website being built is for a fictional organization called Pangea, focused on gardening.

So welcome everybody. This is Building Blazing Fast Websites with Next.js and Sanity. Um, so let's get right into it. Just a little intro. My name is Natalia Iaffe. I am a software developer at RangleIO. I'm mostly specialized in the front end. And, uh, most of my work has been with partnering with organizations to like upgrade, um, our technical stacks to react and a lot of projects working, um, with headless architecture and, um, content editing abilities with, uh, with CMS like Sanity, Contentful, et cetera.

Um, yeah. Nancy. Yeah. Hey everyone. My name is Nancy. Um, I also work at Rangle along with Natalia. I am a associate director of digital strategy. Um, but I'm actually just a developer by trade. So I've been doing a lot of headless CMS work in the last year, year to two years. Um, a lot of work with Sanity Contentful. So super excited to be here today to kind of share a lot of our learnings, um, with all of you guys on how we implement headless CMS projects.

Yeah. So, uh, hopefully everybody's seeing my screen. Um, let me know if there's any issues with the zoom guys, but I'll go ahead and chat about, uh, just a little overview of what we're going through today. Um, cause there is quite a bit. Um, so first we'll talk about just kind of what we're building. Um, you have the link that we've sent in the chats to take a look at that right now. Um, we are going to go through the platforms that we're using sanity next for sell, um, as well as storybook, um, and talk a bit about headless architecture and why, um, why use it. Um, we're going to set up the repo. So we'll have a bit of a pause, uh, bathroom break, whatever you've already set up your repo, um, and, uh, give you the scripts to get, to get going. Um, then we're going to dive into sanity. We'll dive into like the pieces that, um, uh, that you need to understand to get set in sanity working. Um, and then we'll have a little pause to set up cause you'll need to get a sanity account and all these things. Um, so we'll have a bit of a pause to set that up and then go into some breakout rooms to configure, uh, to do some activities based off of kind of the set we've talked about, uh, and Nancy and I will be hopping in and out of breakout rooms. Um, so, uh, that should be fun. Um, then we'll go into talking about next JS, which I think some of you have some experience with so far. Some not. Um, we'll talk a bit about that, the site builder, how it powers our app. And we will also go into a little breakout room to like, um, render some of the components that we have in this repo on the page with Next. And then, uh, lastly, we are going to be deploying to production on Vercel. Um, and we'll do some breakout rooms there as well. Um, and then hopefully you'll have a whole working app, um, website that you can customize, um, to your pleasure later. So that's what we'll be kind of going through. And, um, we have some guided times here. Um, but if people are faster, slower, um, we'll kind of work. We'll, we'll see how it goes. Um, so let's chat about, um, what we are building. So, um, just to confirm everyone, Nancy did my screen slide over. Okay, great. So, um, everyone should have this link, but, uh, this is the actual website app that we are building. This is a fictional organization called Pangea, um, for all of your gardening needs. Um, so we're just kind of mirroring an organization website.

2. Introduction to Headless Architecture and Tools

Short description:

This website offers various services and provides all the tools to create a full app. Headless architecture separates the presentation layer from the content layer, allowing for framework agnostic development and customizability. Headless CMS tools are optimized for SEO and performance, and the decoupling of data and visuals enables content reuse across different channels. The CMS platform, like Sanity, manages content, while the site builder, like Next.js, combines content with React components to create a fast application. Sanity is an API-based headless CMS with a native preview functionality, and Next.js is great for static site generation and server-side rendering.

This website has, or this organization offers various services. Um, so we'll, you'll have all of the tools to create this full app by the end of this workshop. Um, the other piece of this is the actual sanity CMS authoring experience, which looks a bit like this. We'll dive into it more later. Um, but this is the author experience that we will be building. Have some screenshots and slides for you guys as well, just for reference later.

But let's dive into what is Headless Architecture? Um, if you've, uh, worked with Contentful before, you may know a little bit about this, but if not, um, headless with headless architecture, um, well, you may have heard of, um, various CMS's like, uh, um, WordPress or, um, Squarespace, which are kind of what we call like Headful, where on the platform itself, you build and create components, um, as well as edit content in the same platform. Often they have features that are tied to that platform that you need to use with headless architecture, which is kind of what we're going to be working with. That presentational visual layer is completely decoupled separated from the, um, content layer, meaning like the data, like the different headings you want to use for various components, things like that, um, completely separated. Um, and the data is served, um, to your site via an API from the CMS. So instead of having everything all in one platform, it's separated and just connected with API. So there's two parts of that. Um, we've got the CMS, um, where you manage your data, um, all of your content, images, all of that. Um, something like sanity, which we're using today, or Contentful as some of you might have that some experience with Contentful. And then we have a second part, which is a site builder, um, in our case, it includes, um, using Next.js, but you can use something like Gatsby, if you have some experience with that, um, a component library and page templates. Um, so that site builder will actually end up combining your content from your CMS, um, with your React components, uh, into a really fast, um, Next.js application. Um, so there are some benefits to going headless, um, over having everything all in one platform. First of all, especially, uh, for us, devs, uh, we really love that it is framework, uh, agnostic. So, um, you can be building in the presentation layer or the visuals, um, using any tool of your choice. So, um, if you prefer React, use React, if you prefer Angular, use Angular, Vue, et cetera. So, you can be building all of your components in the language that, um, that you know or that your dev team knows. Um, it's super customizable, um, you can build in, bring in your own components, you're not tied to what, like, a certain platform, you know, like WordPress or whatnot requires of you and you can build in, or you can bring in a bunch of third party libraries for a lot of various features. Um, your, uh, the headless CMS tools are, uh, super optimized for SEO and performance. Um, and like what the app that we're building today, I usually can, um, you leverage, uh, static site generation, which just makes the app super fast. Um, and one of the greatest benefits as well is that, um, since your, uh, data is completely separate from visuals, different platform, that same content can be used across all different kinds of channels and digital touch points like mobile, um, apps, um, VR, maybe in the future, um, and just web applications and websites. Um, because it's all served via API, um, from your, um, from your CMS. So those are some really, um, important benefits of going headless, um, just real quick, sometimes I'm a super visual person person. So, um, visualizing kind of how this journey looks is useful, um, for me. So, uh, in our case, going from the left, you can see our headless CMS circle there is Sandy authors, uh, content editors, marketers will input their content into that CMS platform and the, and the editor interface. And then that API, um, the, uh, CMS API sends that information, um, uh, as Jason to our site builder. In our case, again, we're using next JS. So the site builder gets that data and, um, combines with your component library to build the front end and then a bundle that it bundles that code, uh, and sends it to your distribution platform. In our case, we're going to be using for sale. Um, and in the end, as we know, when we deploy, um, your browser, all it sees is the beautiful HTML with s JS and your, um, really great app that you built. And then zooming in just a bit, um, on the headless, uh, CMS workflow starting on the left. Um, and we'll see this kind of in practice and also do this as well in breakout rooms, but like an author we'll be using the editor interface, um, to create content, published content. And again, all of that content is sent via API or retrieved from the API with as Dayson data to next. So these, um, little info graphics might be just helpful in the future to take a look at just to, um, cause visual they're a little bit more helpful for me at least. Um, so we can just go right into the platforms and tools that we've kind of been mentioning. Um, first I'll talk about sanity, which, um, a couple of you mentioned have not used before, um, is API based headless CMS. Um, you can use the APIs to manipulate, like retrieve and manipulate content. Um, and in our case, we're going to use, um, react to, um, render all of our content into like beautiful components. And then, um, in sanity, something that we really love is that has a native built in preview functionality so that a marketer or something goes into the CMS, they're making a change. Um, you should be able to, to see the change that you're making before going live. Um, and it's really easy to work with sanity, uh, with Next.js. So this is just a little homepage of sanity. You can definitely go ahead and explore if you like. Um, Next.js, um, is I what we're using for our site builder. Um, it's great for static site generation, um, server side rendering and dynamic routing. We'll talk a little bit more about that as well.

3. Next.js, Storybook, Repo Setup, and Sanity

Short description:

Next.js and static site generation create fast apps. Vercel and Next.js work great together. Storybook is an interactive development environment for showcasing React components. Set up the repo by forking and cloning it, then run NPM install and the dev scripts. Sanity will be set up later. Thumbs up in Discord when ready. Nancy will guide through sanity setup. Storybook is running, but app and sanity need configuration. We'll be working with the media module today.

Um, and, uh, the great thing about Next.js and, uh, server side or sorry, uh, static site generation is that, um, it creates a really fast app because everything is, um, compiled and bundled at build time. So, um, right when you deploy your application, what somebody sees it has already been built ahead of time. So, it's super performant. That's why we love to use it. And then we'll dive a little bit more into Vercel, but there's, uh, it works really, really great with Next.js because I think they're actually from the same parent company. Um, and, uh, it's got great monitoring tools for performance, um, um, et cetera. So, we'll dive a little bit further into that later.

And then lastly, one of the tools, which hopefully some of you are familiar with. But if not, Storybook is a really great, um, development, uh, environment. It's interactive, which can showcase a component, like your React components that you've built in a completely isolated environment. So, let me actually show you what that looks like. Um, I already am serving localhost, our Storybook here. So, um, you can see here we've got on the left various components that we've already built for this app. We've got Main Hero, for example. We've got Media Module with Image and Text. So, this is a place where all different kinds of people can go and look and play with components and all of the configurable options without having to be in the app. So, you can prototype things really quickly. Et cetera. So, that's Storybook.

Let's get started. Unless anybody has any immediate questions. What we're gonna do right now is set up the repo. We have dropped the links to the repo in Discord and in the Zoom chat. Please let us know if you can't access that or don't see where that is. Maybe somebody, we can just drop that starter repo one more time in the chats. And what we'll do... you can also access it with this deck link. We'll fork the repo and clone that forked version. Run NPM install. And once you've done that, you can run your dev scripts to get these Storybook, the app, and Sanity running. Sanity won't actually be like working entirely yet because we haven't set it up yet. But these are the only scripts that you will need to get everything going. Let's see here. So we dropped the starter repo in the chat. And then why don't we everyone in the Discord just throw a thumbs up when they've got their repo and their scripts going? Let me see. Let me add a little... OK, I just dropped... Sorry go ahead. Oh, I just want to remind everyone to make sure to fork the repo and not just clone it. This is mostly because eventually we want to be able to deploy your version onto Ursel. So forking your own copy onto your own GitHub and then cloning that locally is going to be really critical. OK, Nancy will talk us through after this pause through sanity. So I'll go ahead and switch my share to you, Nancy, now. Yeah, it's totally normal to see a 404 right now for your app because nothing is configured just yet. So as long as your Storybook is running, that's the only thing that should be working right now. We have not yet configured the app or our sanity portal. So that's going to be our next step right after we have the repo ready locally. If you're not early, it'll be really good to take a look at the different components we have in Storybook. We're going to be working specifically with the media module today. We have a couple of, we have all of the components completed today, so you guys won't be needing to create any new components.

4. Setting Up Sanity Interface

Short description:

In this section, we'll be setting up sanity, a customizable platform for creating interfaces. The desk structure with folders like pages and global is configured by the developer. The pages folder contains the pages and paths of our application. SanityHacka has a built-in preview feature for live updates. Components can be added and rearranged within sections. Sanity also provides an asset management system and a vision tab for querying data using the Grok querying language.

But it'll be good to get familiarized with some of the components we'll be working with. I'm going to move on to the next section which will be setting up sanity.

Okay, awesome, looks like everybody's good to go. So in this particular section, we're actually going to be creating the sanity interface. So before we jump into how to actually do all of that, let's just take a quick walkthrough of what the complete sanity interface will actually look like.

So this is our sanity platform. And if, for those of you who are not familiar with sanity, it's actually really customizable what you can actually create using sanity. So all of this, what they call a desk structure over here with our pages folder and global folder, this is all configured by the developer. So you have the choice to create these structures and this interface based off of the needs of your project.

So in our particular case, it's a very simple application that we're building today. So we've only really got our pages folder and global folder. So the global section is already set up for you. And you can see in here, we've just got some of our global elements, like our navigation and our footer, which is not configured per page. It's kind of configured once globally. The second folder we have is the pages folder, which is going to compose of all of the pages and paths within our application. So if we click into this root route, this homepage, you'll see that our page composes of a title, the slug that you can find this page at, and all of the different components and sections of our page.

Like what Natalia mentioned earlier, SanityHacka comes with a built-in preview. So if I hit this preview button, if I do a split screen, I can look at what I'm editing on the left side, and on the right side, I can open up my preview. It's going to take a second to load in, but once it does, you can see the homepage actually rendered out on the right side here. And as I'm editing content on my page over here, you'll be able to see the live update. So this is really great for content authors, because it gives them kind of immediate feedback on what they're actually doing on the page.

But each of these items within our Chef sections is one of these component blocks that you see on the page, they can add additional components onto our page and also rearrange the ordering depending on how they want the layout to look.

Some other things that Sanity also provides for you is a built-in asset management system. So if you head on over to the media section, you'll see that this is where we have all of our images stored. So when I'm actually creating a new component here, I can reference those images those images stored in my media.

The last thing that we're going to be using today, not just yet is this vision tab. So if you head on over to this vision tab, you'll see it's kind of a little sandbox playground to query our content from Sanity. We'll be using this a little later to kind of play around with querying data, specifically using the Grok querying language that Sanity provides.

5. Understanding Content Modeling in Headless CMS

Short description:

Before setting up our experiences, we need to understand content modeling in the headless CMS space. Content models define and model the interface using a schema. They act as blueprints for rendering content and can be used to model various types of data. The three types of content models are page content model, page module, and data object. The page content model mirrors the page structure, the page module mirrors components, and the data object stores non-presentational data.

Awesome. So moving back to actually setting all of this up for ourselves, before we can actually set up our experiences, we have to kind of level set on how we actually build author experiences in the headless CMS space. Usually we typically do this with what they call content modeling, and a content model is usually just a way for us to define and model the interface that we want. So all of the interfaces that we're seeing here with all of our inputs and fields are defined by the developer using insanity, what they call a schema. And we'll get to take a look at exactly what that syntax will look like. But the schema acts as a blueprint to tell sanity how to render a particular content model. And even though content models don't actually have specific types within sanity or content full or any other headless CMS, content models are pretty ubiquitous. They're not defined by pages or page modules. You can use them to model whatever you want. In the context of building a front end application, we like to kind of think of these three types of content models that will help structure our data in a way that makes sense to consume for our front-end application. The first type is the page content model, which will mirror our page structure. So, this is what you're really seeing here. It's usually got two kinds of content. And we'll kind of dive into those. The second type is the page module, which tends to mirror your components. And the last type, which we're not going to be working with too much today, is the data object, which tends to mirror miscellaneous data that aren't usually presentational. So, things like your SEO data or your settings, typically you want to just return those and utilize those in the form of a JSON object, this is a really great way to capture any other content.

6. Defining Content Models and Types

Short description:

The page content model mirrors the information needed to create a page, including metadata and page layout. The page module mirrors a single component and its configuration. Sanity uses a specific syntax to create a schema for content models, which is a JSON object with specific fields. The schema includes a schema name, title, and a list of fields. Documents and object schemas are used to define page and page module content types. Documents are queryable, while objects are used to define custom field types. It's important to consider how the content will be queried when deciding whether to use a document or object type.

So, diving a little bit deeper into our page content model, so the page content model, like I mentioned before, actually mirrors the information we need to create a page. So, the two types of content we typically see in here are either metadata, which are things like our title or meta description or our slug. So, nothing very visual. And the second one is going to be capturing our page layout, so this is our sections area over here, which is going to determine the kind of component that we want to render, the content that's going to be rendered on the page, and also the order in which these components are going to render.

The second type, the page module, is going to be mirroring a single component. So, on the right here, you're seeing the CTA banner, which is one of the components in our component library and also available in the CMS. This kind of content model mirrors all of the content pieces an author can enter in to configure a component. So, how do we actually go about creating these content models? Like I mentioned earlier, Sanity has a very specific syntax when it comes to creating a schema that defines a content model. This is the syntax you're seeing on the right-hand side over here. For the most part, it's pretty much a JSON object with very specific fields that you have to fill out in order to tell Sanity what you're actually wanting to render. So in here, we've got the schema name at the very top here. This is you can almost think of as the equivalent of an ID for the content model. We've got our title over here, which is what is actually going to be displayed in the Sanity interface. So coming back to our example here, we've got our CTA banner. The title is actually what's physically rendered in the UI. So this is typically more user readable, just so it's a friendlier experience for your content authors. Then we've got a list of the different fields, which is actually what helps render all of the different sections of fields that we see in our UI over here. One thing to note here is that you'll see us use the define field and define type function. This is actually optional, but it does help provide some type checks for all of the shape of the object that you're passing in. So for example, if you forget to add the type or the name, it'll just provide you with type errors to help guide you along. But if you don't want to add in the boilerplate, you can also discard all of the functions and it will just be kind of a flat object structure that you're familiar with. So last thing I want you guys to know on the schema is the type over here. So you can kind of see here that we've got the type set as an object and there's a couple of different types of schemas that we can have in Sanity. The two that we're going to be really working with on a schema level is the document and the object schema and that's going to help us define either the page or the page module content types that we were just talking about. So when it comes to documents you can think of them as a parent schema type. All of the other types of schemas that we're going to be creating including the object is going to live within the very similar to what we were looking at earlier. This page will be considered a document type and you can see all of these individual components which are object type are going to live within the page itself. Interesting to note here is that documents are the only ones that can be queried when it comes to actually fetching your data. So things like pages are things that we want to be able to fetch all of the pages, so it needs to be a document type. So when we're modeling for a website, the document again is usually what creates the page content model that we're seeing versus the object. This is usually used to define custom types of fields, numbers, arrays and this is not queryable. So, although this can live within a document you can specifically query for example all of our CTA banners. And we do use this to model all of our components and the page module content models that we were just talking about.

I know that's going to be kind of a difficult topic to grasp. Any questions right now from anybody on what we talked about so far with content modeling?

Okay, I'm going to move on but there will be opportunities. Oh yes, please. Okay. So, what happens when you want to fetch some content from only an object? You have to create another page for it? Exactly. So, it's really important to kind of think about how you want to use your content. So, if you know that the content needs to be queryable, then you want to make it a document type. So, for example, here we know for a fact that our pages, we need to be able to query all of our pages. In that case, this needs to be a document type. The CTA banner only simply lives within the page. We don't need to query all of the CTA banners across our pages. So, this could be an object type. Using similar kind of logic here with our navigation, we need to be able to query the navigation and the footer individually to render our top navigation and footer. So, in this case, these all need to be document types. Or we won't be able to fetch the data for those. All right. So, diving a little bit deeper to look at how we actually define each of the fields.

7. Field Types and Schema Creation in Sanity

Short description:

The fields in Sanity are determined by the field type you enter, such as text inputs, toggles, or image selectors. Field validation and initial values can be configured to create a user-friendly interface. It's important to match the names of schemas and fields to component properties. Schema documentation provides a list of available types. The title property is used as a user-friendly label. Naming is case sensitive. Natalia will now provide a real example using the CTA banner component and guide through the schema creation process in Sanity.

So, the fields are primarily determined by the field type that you enter. So, sanity provides a bunch of different types that you can have. And depending on the types, it will render either text inputs or toggles or even image selectors. Additional things you can actually configure per field is things like field validation or initial values. And those are just going to be really helpful for creating a friendly user interface to provide more guidance for your content authors when they're entering content.

I'm just sharing here the schema documentation if you guys want to take a look at all the schema types that are available. I'll have this link up again when we get on to the hands-on portion where you'll need to dive in a little bit into the documentation and figure out how to actually create a field. But breaking down the field a little bit further just to look at what each of these properties actually render out.

We've got our property right here that's set to boolean, which will render our toggle input provided by Sanity. We've got our title again over here. Similar to on our schema level, you'll see that it's just used to display this user-friendly label on the Sanity interface. Looking at a second example, we've got our string type over here, which instead of a boolean, it renders a text input, and with our validation added in, you'll see that if the user has left this field empty, Sanity will provide this nice little error message just to indicate that this field is required. The last thing to know here when you're actually creating your own schema is that naming for all of our schemas and fields are very, very important, and we'll get to revisit this a little bit more in the next JS section as to why we are very... it's very critical to actually match the name of your fields to the property names and the name of your schema to the name of your component. But for now, just kind of remember that we need to do this when we're creating schemas. Do remember that it is case sensitive, so if you have camel case over here for your props, you need to make sure that both of these are the same casing and the same spelling. So at this point, I'm going to hand this over to Natalia, who's going to just go through a real example using the CTA banner in our component and walking through the end-to-end process of putting together a schema in Sanity.

8. Building the CTA Banner Schema

Short description:

Let's dive into the codebase and see how we build a schema for the CTA banner component. The name and title of the schema match the component name. The schema's fields mirror the component's props, including heading, CTA, and image. The CTA field references another schema called CTA, which has boolean and string fields. These schemas and content models are the building blocks for the authoring experience in the sanity interface.

Awesome, thank you, Nancy. So let me just share my screen here. 2023, post COVID, still trying to figure out how to share screens gracefully. Never gonna happen for me, guys. Okay, hopefully you're seeing my entire desktop. Yes. Okay, awesome. So what we're gonna do right now, so we learned a bit about some abstract concepts kind of about content modeling and all of that, what we're gonna do right now is just try to make that a little bit more concrete with like the project that we're working on right now. So taking a look at like the homepage of our project, we have this CTA banner image, heading with CTA. So let's dive in to the codebase and see how we build a schema for that. So first, hopefully you guys are looking at some code right now. First we'll take a look, thank you for confirming. We'll take a look at our components file in our or the folder here and we'll take a look at CTA banner. So if y'all are React developers, y'all are very familiar with a component like this. A presentational component that just accepts props and renders them. So we've got the CTA banner that accepts these props, we've got a heading, image and the alt text for the image and a CTA. So what Nancy was saying about creating a schema where various names are matching with your component is really important. So we'll just notice that these are the names of our props and CTA banner is the name of our component. So I'm going to scroll down in this file structure down to the sanity folder and open up our schemas, which is where we're putting all of our schemas. So Nancy mentioned that there's objects and documents, document being something like a page is here, and then we've got open up our objects which mirror our, what Nancy was mentioning is a page module or components. So I'm going to open up CTA banner here. So this is the schema for the CTA banner and we'll notice first off that the name of our CTA banner matches the name of our component. Very important. And we'll, once we dive into the site builder section, we'll kind of show you why. And again, case sensitive. And then we'll also notice that the title is CTA banner. So, when we actually dive into sanity, we'll actually notice that when you drop an actual, like, when an author goes in and creates a CTA banner, the name of it is here. When you edit it, it says, edit CTA banner. That's all created from the title here. Then we take a look at the fields of the CTA banner. We'll notice that these mirror the props that the CTA banner requires. We've got our heading. We've got a CTA. We've got an image. The heading is a string type. The image is an image type. It's a sanity image type. Now, if we take a look at the CTA, the type of CTA, now, this is not an out-of-the-box sanity type. This is us referencing another schema that we've already built. So, if you have another, like, we have another object here called CTA, which we want maybe other modules to be able to include a CTA. Take a look at that object. It has a couple Boolean fields and a couple string fields. The name of it is CTA, and that's how we reference it here. And then, if we take a look at that schema again, if we open up, later, you'll have all this kind of to look through. But if we open up the CTA banner, we mention that building these schemas, these content models, all of that is to create the, like, the Lego blocks of building our authoring experience in the sanity interface. So, that's exactly what we've done. We've said that the CTA has two Boolean fields. It looks like this. Has two string fields. Looks like this.

9. Schema Building and Content Querying

Short description:

We've built the schema for the CTA banner component and added it to the sanity configuration. Now, let's explore how to query our content using Grok, Sanity's open-source query language. In the Sanity studio, we can test our Grok queries in the vision section and see the shape of the data. Grok is similar to GraphQL but offers even more flexibility and power. It allows us to query data to the shape we want.

Heading and image. So, we've built that all with our schemas. We also have down here, we won't dive too deep into this piece, but this is a pretty customizable piece of a schema called the preview. And you'll notice here that we're selecting a couple of the props, heading and image, and we're preparing it. So, what that directly mirrors is the experience of seeing that you've dropped a CTA banner on this page, and you have the heading, you have the name of the component, and the image. So, the preview directly mirrors what you actually see in this list when you build, when you drop a CTA banner onto the page.

The last piece after you've kind of built your schema with your fields is that you want to scroll down to the very bottom of this file structure, and you will see a sanity.config.ts. So, this is our sanity configuration, you guessed it from the name. Up at the top, we've got a bunch of imports, including on line 25, a CTA banner from our schemas objects folder. So, we're importing this into sanity config, and then including this CTA banner in our configuration object for our schemas here. Super important to make sure to add that to the schemas object or else sanity will have no idea that your CTA banner exists. You built the schema. You can't use it. So, adding it here to this section makes the schema available to use.

Now that you have your page schema set up and we've got a couple of pages built out. It's time to kind of take a look at how we actually can go about querying our content. So, sanity actually provides you a couple of nifty little tools to do this. So one of which is just to get a sense of what the shape of the data actually looks like. You can go into this three dots section and click inspect. So, this will actually show you what this page data will look like. You can kind of see that we've got our type. We've got all of our sections and our components in here with our type equaling the name that we've given to the schema and all of our different components, the properties and inputs that we created, the fields with the name that we've chosen. So, the background image, the body, and all of the different sections in here. So, in order for us to query this content, we're actually going to be using Grok to do that. So, for those of you who've never used Sanity before, Grok is actually Sanity's open-source query language. It's very similar to GraphQL, but I would say that it's actually even more flexible and powerful when it comes to being able to query data to the shape that you actually want. So, we can actually test out all of our Grok queries within the Sanity studio. So, if you head on to the vision section that I showed earlier, we're able to put in our query in here and test out what our Grok query actually returns.

10. Using Grok to Query Content

Short description:

We'll be using Grok, Sanity's open-source query language, to query our content. Grok is similar to GraphQL but more flexible and powerful. We can test our Grok queries in the Sanity studio's vision section. By using square brackets, we can filter the documents we want to select, such as selecting all documents with the page type. Within the squiggly brackets, we can dictate the shape of the content we want to fetch back. We can also change the shape of the returned data, like simplifying the slug object to just return the URL. Additional filters can be added, and the dot, dot, dot notation returns all values inside the document. You can test the queries in the Vision section of Sanity studio.

So, in order for us to query this content, we're actually going to be using Grok to do that. So, for those of you who've never used Sanity before, Grok is actually Sanity's open-source query language. It's very similar to GraphQL, but I would say that it's actually even more flexible and powerful when it comes to being able to query data to the shape that you actually want. So, we can actually test out all of our Grok queries within the Sanity studio. So, if you head on to the vision section that I showed earlier, we're able to put in our query in here and test out what our Grok query actually returns. So, I shared here just the link to the query cheat sheets. When you click in there, you'll see that there are so many different things you can do with your Grok queries to be able to sort, filter, and quite a lot of different complex calculations. But all we're going to be utilizing today is actually quite simple. So, just taking a look at the anatomy of a Grok query, what we have here is just the syntax we're going to be using to select all of the documents. And within the square brackets here is how we're going to filter what kind of documents we want to select. So, here I just want to select all of the documents that have the page type. So, that's all of the pages that we've created. And then within the square brackets or within those squiggly brackets in here, very similar to GraphQL for those of you who are familiar, we can actually dictate the shape of the content or the shape of what we want to actually fetch back. So, even though if we look back at all of the data that exists on our page, you see that we actually shown this inspector before. Like how to get here. Yeah, it's just yeah. Yeah. So, in this section over here, we can see that there's so much different metadata in here, including one of the fields that we have at the bottom, which is our slug. So, what we can do here is instead of returning the entire object, we can actually choose to just return the slug field within this page object. And what we can also do is actually change the shape of it. So, even though this is a slug object containing the type and the URL, if we just want to simplify the structure of this to just return our URL as, like, a flat string, we can do that by assigning slug.current to our slug type. Alternatively, we look at the second example. You can see that we can actually add additional filters here. So, not only are we selecting the page type, we can actually also select a specific page. So, here I'm just selecting a page type that has the slug at our home page. In here, if we're not interested to select and manipulate the shape of our data, in our case, oftentimes, we just want to return all the data that the content author has inputted. We're just going to use the dot, dot, dot notation, which will return all of the values inside your document. So, it will return everything that you're kind of seeing in here. So, we're going to move along here pretty quickly, but if you want to take a look at what this actually looks like, you can pop into Vision. In here, for example, if I'm just selecting this particular query, I can run this, and immediately we're able to see the page that I've created that's on the home page and all of the contents in here. Similarly, if we did just our slug, you'll see here that we're only now just returning the slug field.

11. Connecting Content with Next.js

Short description:

We're going to connect the content created in Sanity to our Next.js repository. The code base primarily consists of the pages folder, which contains page layouts and routing. The folder and file structure determines the routing in Next.js. The app TSX file includes global elements like SEO, navigation, and footer, which are automatically rendered on every route. The utils folder contains the build component utility function, which converts JSON data from Sanity into React components. Next.js uses a file system-based router, where adding files and folders to the pages directory automatically creates routes. Dynamic routes are accomplished using square brackets and the file name. Catch-all segments and optional catch-all segments allow for more flexible routing.

All right. So, we're going to hop on to the Next.js part to finally connect all of the content that we just created in our Sanity platform into our Next.js repository. So, before I jump into that, I'm just going to quickly show you guys where in the code base we're going to primarily be looking at.

So, we're looking at the code base here. We've got our pages folder. This is really primarily where all of our page layouts and routing is going to be located. So, Next.js does utilize a file based routing structure which means that the folder, how we name them, and all of the file and folder structure is actually what determines your routing within your Next.js app. It's a little bit different in React where you don't actually have to configure anything manually. It's all about how you structure and name your files and folder.

You immediately see this weird folder name. We'll get into that a little bit later, but this is actually where, this is the template that we're going to be using to create every single one of our pages within Next.js. And it is a dynamic, this is a syntax for a dynamic route. So, with this one template, we're going to be able to generate all of our routes. You're going to see some other routes in here that you're not really going to be touching at all, we've got this API route, which basically helps us generate our sanity preview. We have a studio path. This is our integrated sanity studio. So, this is why when you navigate to slash studio, you're able to access sanity because we've got all of our sanity content under the studio route. Some other things to take note of is this app TSX. So, this is one of the next JS files that we use to create anything that's sort of global for every single template. So, in here, we usually have things like SEO. We've got things like our navigation and footer. And anything that's placed in the app TSX is automatically going to be rendered on every single one of our routes. What's really nice about this is now you don't have to add in the navigation and footer and all of those global elements to every single one of your templates. If you put it here, it's just going to show up everywhere. The last area that we're really going to be touching today is the utils folder. So, inside the utils folder, you'll see a singular build component utility function. This is actually going to be our page builder, and we're going to run through what all of this code is doing. But this is what's going to help convert all of our JSON data from sanity into React components that we can actually render on the page. So, jumping back into our routing. So, like I mentioned, Next.js has a file system based router. So, when you're adding new files and folders into the pages directory, it's automatically available as a route in your application. When we're dealing with dynamic routes, however, you can't just hard code the file name. So, the syntax to actually accomplish dynamic routes is with your square bracket and your file name inside of it. This is a singular dynamic route segment. So, what that means is that it will allow you to create like a slash services route because it's a singular URL segment, but it does not let you create something like a nested path like slash services slash garden design because now there are two file segments. Example that will look like is using slug as our variable. We've got our square bracket, slug.tsx. So, it doesn't quite look like what we've got going on here just yet. And in order for us to actually capture all of the slugs, we need to do a little bit more. So, in order for us to actually capture all of the slug segments, we're going to have to extend it to a catch-all segment. And we can do that by adding the ellipsis in here. So, all of a sudden, it's not just going to work with services. It's also going to work for services slash garden design or however many URL segments you want to tag along into it. A really important thing to note here is it's actually not going to capture the root homepage route because it only works if you have path segments. So, in order for us to capture the home route, which is the last kind of route that we'll need to create our application, we want to make it a optional catch-all segment. And we do this by adding the last square bracket around here, which this is the actual file name that we're actually seeing with our page template in our code base. So, you may be wondering, okay, what does that actually mean? Catch-all versus optional catch-all? So, with a catch-all, we're only able to catch routes that have segments. So, here we've got shop slash A slash AB and slash AB and C, so, these are all going to be available to be created with the catch-all route. But it is not going to be able to create a route route that doesn't have any subpaths to it. When we do make it an optional catch-all, we all of a sudden allow the route route to be created without any subslugs in it.

12. Creating Dynamic Routes and Fetching Data

Short description:

To create dynamic routes in Next.js, we use the Get Static Paths function to define a list of paths. We fetch the page path information from Sanity and map it to the expected structure. To query data from Sanity in Next.js, we use the next-sanity library's createClient function. This establishes a connection to the Sanity API. We fetch the page paths and content using the sanity client and the getStaticProps function in Next.js.

When we actually go in and want to create a dynamic route, we need to actually define a list of paths to be statically generated by Next.js. We can do this by utilizing a built-in function that Next.js already has called Get Static Paths. This function is expecting you to return a list of parameters with your slug segment. You can see here if I want to create the about us path, it's just about us. If I'm looking to create something like services slash garden design, because it's two segments, we actually have an array of both of those slug segments within. This is kind of what it will look like in terms of the structure that Next.js is expecting us to return, but oftentimes, we'll not be hard coding this because these are dynamic routes that we actually want to create based off of the contents that a content author entered in Sanity. We'll actually be fetching all of the page path information from Sanity directly and mapping it to the structure that we're expecting. So in order to do that, we need to actually query data from Sanity. So to query data in Sanity, not only do we have to have the PREQ rock queries, which is kind of what we worked on previously, we also need to have some sort of way to be able to fetch that data specifically in Next. So to do that, we're using a helper library called next Sanity, which has this really nifty live function called create client. So this kind of asks, as the SDK, we will need to provide it with our project ID or data set, which has all been already configured in your EMV local. So all of these informations, we're going to be passing into the create client to make our connection to the sanity API. Once we've got that going on, we're able to then create our function to actually fetch our Grok query. So here you can see we are calling the sanity client. We're going to be fetching a query that we have created to get all of the page paths. Similarly, once we've created all the paths, we will need to then fetch all of the page content for every single path. Because all of this is dynamic, we're going to be using something called get static props, which is another built-in Next.js function to pre-render the page with all of the props that we'll need to create this page.

13. Fetching Data from Sanity with GetStaticProps

Short description:

GetStaticProps fetches different data from Sanity, such as page, navigation, and footer data. The fetched data is returned as a global object, accessible in the underscore app file. All the fetched data is used to render the navigation and footer for each page. None of the data is hard coded.

So on the right here, you'll see an example of a get static props from the code base. The context here is going to give you back the URL that you're actually on. So the params.slug is the current component that is being built. From there you can use that information to fetch the correct page data from Sanity. So you will see here that I'm fetching a couple of different things from Sanity. I'm fetching the page data, I'm fetching the navigation data, and the footer data. So with all of these different data, fetched and ready to be used, I'm able to then return it from the GetStaticProps and make this available to be used inside of our React component. So here I'm returning a global object with the navigation and footer and also our page data. A really interesting thing to note here is that anything that's kind of returned from the GetStaticProps will be available to be accessed in that underscore app file. So things like our navigation and footer, if we're fetching this content in our page, we're able to access all this information and be able to render the navigation and footer using the data fetched here for every single page. So similarly to what we did with the path, we will be fetching all of this data from Sanity to be displayed. So none of this is going to be hard coded.

14. Converting JSON to React Components

Short description:

Now we need to convert the JSON data into React components using the build component function. The component mapper is created to match the schema name with the component name. If the data has the underscore type, the component is selected from the component map. The other properties in the JSON are used as props. In the Slug template, we map the path to the shape expected by Next.js. In the build component, we import the necessary modules into the components map. Finally, in the page component, we use the build component to generate React components for all the sections. Any questions? Let's get started!

So now that we have all of our JSON data, just remembering what that kind of looks like, this is kind of the shape that Sanity sends back to us, we have access to all of this inside our component. It is time to actually convert this JSON into React components. And we typically do this utilizing a function called build component. So remembering back to what we had in our utils folder, this is where the magic happens, where the JSON will be converted to something we can actually render on the frontend.

So let's take a quick look at what the build component function is actually doing. So the first thing it's going to do is create this component mapper. Thinking back to why we were very adamant about naming the component a certain way, this is really the schema a certain way is because this is where it needs to match. So your schema name, if you look at the JSON that gets returned, you'll see that the type is going to be your schema name. We really want to be able to match the schema name to the actual component name in our component mapper. So here we're going to import all of our CMS modules, make it available in the components map. And then as we get into the build component function, you'll see that it's doing a couple of things. We've got a couple of null checks going on just to make sure that the data has the underscore type. If it does have the underscore type, we want to go ahead and select that component from our component map. So by this point we should have a valid component here. But if for whatever reason we forgot to import one of our CMS components in here or if we accidentally named things incorrectly, we will just want to throw an error. The components here will be undefined. It will not be able to select a valid component. We just want to throw an error to just say that no component has been registered. But if everything goes well, we should be able to return our selected components. And from what you're noting here, aside from the type that's being used to select the component, all of the other properties within our JSON is going to be used as props. So again, why it's really important for us to be matching the name of the fields to the property within the component. This is where it's coming in. If for a reason you didn't match the name, then your component won't be able to receive the proper content from Sanity because the names will not match up here.

All right, so that was quite a lot of information. But hopefully all of this will make a little bit more sense once you get into the code base and start connecting things on your own. So just to get a sense of what we'll be working with today, the first thing we're going to be doing is heading into our Slug template. This is where we're going to be first. Taking the path, so we've already got some queries here set up. We're already fetching all the data from Sanity. We're just going to be taking the path and making sure we're mapping it to the shape that Next.js is expecting. If you got some bonus time, feel free to try writing your own rock queries to be able to query the page path and also the page content. If you don't have any time, that's okay. We've got it already written here. The next thing we want to do is head to the build component and make sure we're importing all of the modules that we need into our components map. Once we have all that ready, we're able to head on to line 37 where we've got our page component. It's currently empty, which is why you don't see anything rendered on the page. We want to use our build component, map through all of our sections, and generate all of our React components so that everything will be displayed on the page. Awesome. Any questions? We're ready to jump in.

Yeah. Do we want to do like a full 20? Do we want to do a 10 and then do it together? Yeah, we'll have to, yeah we'll probably timebox this a little bit more so that we can get to the deployment section. So we'll probably do maybe 10-15 minutes to get people to try some stuff on their own. And then we'll finish the rest together. Okay, cool. I'm going to walk through what we'll need to do to kind of get through setting up the page template as well as rendering our components. So kind of following some of the to-dos that we have on the page. The first thing we'll need to do is head into our Get Static Paths. So within here we've already got the paths kind of coming from Sanity. What we need to do is actually map those paths to the shape that we're looking for. So just to remind everybody, this is the shape that Next.js is expecting us to create.

15. Deploying to Production with Vercel

Short description:

We map through the Sanity data, create a list of params object with our slugs. In build components, we import the components and plug them into the components map. In the page template, we map through the sections array and build components using the build component function. We deploy to production through Vercel by creating a new project, importing the GitHub repo, setting up environment variables, and creating a deploy hook in Vercel.

And we just want to go ahead and actually map through the Sanity data so that we are creating, what we're returning is a list of params object with our slugs. The gotcha here is really remembering that the segments needs to be separate array items in here. So we're just going to be doing a split in here so that we're able to create the individual segments for the routes that require multi segmented paths.

The second thing that we're going to be doing is actually hopping into our build components. So within our build components, we're just going to be importing all of the components that we're going to be using in the CMS, the CTA, featured items, all of that from our components folder, and then we're going to be plugging it into our components map. So once we do that, all of those components are ready to be synced up with the schemas that we created in sanity. You shouldn't need to actually do any configuration to the build components function. Everything should just work once you've imported in all of the components.

Once all that is done, we can actually head on over to our page template again, and in here, we've already have everything set up in the guest static props. So we're already fetching our page content, navigation, and footer data, and we are returning it in the props here. So we should be able to access it within our within our template here. So we've got our page props, and you'll see we've got our pages here. So in here, what we need to do is we know that everything that's UI-related that we'll need to render is in the sections array. So what we want to do is map through every single object within our sections and build out our component using the build component function and passing the section data or component data to it. And what we should be getting in the end is our fully complete app where depending on what you've inputted into your own CMS, you should be able to see those components rendered out. So for us we have quite a few components on here rendered and we should be able to see all of those content displayed.

Well, do you have any questions? Well, this is a big information of hopefully, hopefully you can refer back to this recording as well when you're creating your own projects to get things going. Yeah, this might be something you kind of take a look a little bit closer after the workshop. There is a lot of different moving pieces here. It'll be definitely kind of interesting to see if you can create your own rock queries for some of these areas that needs querying data. Yeah, awesome. In the meantime, we're going to move on to our last section. So hopefully by this point, we have all of our pages rendering for each of our paths. What we want to do at this point is be able to deploy it to production through Vercel. Nance, do you want to take over? Sure, if you want to do the same. Okay, let's give you a rest. Okay, so we are going to go through what it is like to deploy to production. And previously, we talked about using the tool Vercel for this so that we can get all of our code from Next.js and have that showing up on a browser. So there are a number of steps. So we'll have you kind of do that on your own after this, or we can do it together. But the steps, first of all, obviously, you need to get a Vercel account, we always sign up with our GitHub. It's best to connect with GitHub. And this is like a free hobby account. Vercel has different paid accounts, but this is just for fun. So go with the hobby account. And in Vercel, there's a way to create a new project. And in that new project, you import this GitHub repo that you're working on. If you didn't sign up through GitHub, you'll need to I think connect GitHub to Vercel. So that's why we definitely recommend just signing up with GitHub. And then you'll need to set up some environment variables first so that Vercel has everything it needs to actually understand the product ID and all the different things that connect it to sanity and deploy it. So don't deploy yet. So setting up those environment variables, you guys all have that in your environment.local right now. So you'll just want to paste those all into your Vercel's project environment variables section. You can paste them one by one and add them each or you can just paste the entire file right in this area here. And then once those have been added, then you can hit deploy. So we don't want the website just be static and never change. So we want to set up, like theoretically, if you're building an organization's website or something like that, you know, somebody is going into Sanity and authoring new things and updating the pages, you want to set up a webhook so that Vercell can rebuild every time an author publishes in Sanity. So let's say you change the name of the site from Pangea to, you know, Marianas great website, you want to publish that in Sanity and you want Vercell to pick that up. So you'll create a deploy hook in Vercel. We just have some instructions here where to find that within the settings.

16. Completing Vercell and Sanity Connection

Short description:

Just give any name to the trigger, copy the generated URL, go to Sanity's API section, paste the URL in the web hook section, select create, update, and delete triggers, and save. Once deployed, updates in Sanity will reflect on the live URL. Take some time to customize your website with images, color palettes, and text. We'll be available for 10 more minutes to answer questions and provide support. Thank you for joining us!

And just give it any name and set the trigger to main. And they will generate for you a URL for you to use. So make sure to copy that URL and then go into sanity and make sure you complete that connection.

There is over on the sanity side, there is an API section with web hooks. And you want to paste that URL that you got from Vercell into their web hook section to complete that connection. So now Vercell and sanity are working together. And just some gotchas here. Make sure you select the triggers create, update, and delete and save.

So definitely use those instructions here to just follow and get this connected to Vercell. And I don't know. I guess we can give you some time to do that. And once things are deployed, if you make updates to your site and make updates with Insanity, you'll be able to see those changes happen on the live URL that you get. So, yeah. The result of this, you'll have a deployed link for your project and see your updates.

What do we think? I guess we'll stay in here if anybody has any questions as you do that. It would be great to see anybody's like cool custom stuff that they've built. After this, we'll just say customize your website, drop whatever images you want, drop whatever color palette you want, you know, change some of the text that you see and create something kind of custom for you. So yeah, for now we'll just get all the Vercell stuff set up and let us know if you have any questions about connecting Vercell with Sandy, getting those environment variables in, any of that. So we'll take, I don't know, five, ten minutes for that.

Yeah, we have technically two more minutes left in the workshop. If people have any general questions that they have not necessarily just about the activities for any of the content that we kind of presented today, I'm happy to take questions if you just want some more time to kind of work through some of the deployment stuff, we'll stick around. If there's anything that you have questions about or you run into any issues. But this is kind of the end of the workshop, so hopefully everybody learned something and they're able to kind of have their own website deployed at the end of it.

Good on you for checking time I would have just kept going and going and going. In case anyone has to leave, this is kind of the last steps that we'll need to complete. Does anybody have final questions, any thoughts, any like errors that you immediately ran into, or anywhere previously that you got caught up and couldn't continue, even if it's just sanity stuff or Next.js paths stuff. We're happy to answer those questions now as well.

Okay, if not, then we really appreciate you guys joining us and getting through all of that information. It was a ton. Once you get used to building sites like this, it goes really, really quickly. And the good thing now with this repo is you've got some really nice boilerplate to kind of go from here. And there's so many different kinds of ways to configure sanity and the authoring experience. There's a lot of different ways to query data and use the builder. So definitely have fun with it. And yeah, you get some nice boilerplates to go off of. So yeah, thank you guys for joining us. We'll see you next time, I guess. Thank you, Nancy. Thank you, everybody. Thanks, everyone. We'll stick around for like another 10 minutes in case there's last-minute questions or anything like that.

Watch more workshops on topic

React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
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
Top Content
- 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
102 min
Fetch, useEffect, React Query, SWR, what else?
In this workshop, first, we’ll go over the different ways you can consume APIs in React. Then, we’ll test each one by fetching content from a headless CMS (with both REST and GraphQL) and checking in detail how they work.
While there is no advanced React knowledge required, this is going to be a hands-on session, so you’ll need to clone a preconfigured GitHub repository and utilize your preferred React programming editor, like VS Code.
You will learn:- What diverse data fetching options there are in React- What are advantages and disadvantages of each- What are the typical use cases and when each strategy is more beneficial than others
React Summit 2023React Summit 2023
139 min
Create a Visually Editable Next.js Website Using React Bricks, With Blog and E-commerce
- 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
React Day Berlin 2023React Day Berlin 2023
119 min
Crash course into Astro and Storyblok
Headless architecture has gained immense popularity in recent years for its ability to decouple the frontend and backend, empowering developers to create engaging, interactive, and scalable web applications. 
In this workshop, we will quickly take a dive into the Headless World and Architecture. 
Additionally, we will build a blog website super quickly using Storyblok, a headless CMS that offers a real-time preview feature with nestable component approach, and Astro (3.0) which is already creating a buzz with the new app directory. 
- Master headless CMS fundamentals- Master an Astro & headless CMS approach- Use Atomic design in your Astro & Storyblok application- Creating pages, adding content and understanding how the dynamic routing works with headless
GraphQL Galaxy 2021GraphQL Galaxy 2021
161 min
Full Stack GraphQL In The Cloud With Neo4j Aura, Next.js, & Vercel
In this workshop we will build and deploy a full stack GraphQL application using Next.js, Neo4j, and Vercel. Using a knowledge graph of news articles we will first build a GraphQL API using Next.js API routes and the Neo4j GraphQL Library. Next, we focus on the front-end, exploring how to use GraphQL for data fetching with a Next.js application. Lastly, we explore how to add personalization and content recommendation in our GraphQL API to serve relevant articles to our users, then deploy our application to the cloud using Vercel and Neo4j Aura.

Table of contents:
- Next.js overview and getting started with Next.js
- API Routes with Next.js & building a GraphQL API
- Using the Neo4j GraphQL Library
- Working with Apollo Client and GraphQL data fetching in Next.js
- Deploying with Vercel and Neo4j Aura

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 Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
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
27 min
The New Next.js App Router
Next.js 13.4 recently released the stable version of the "App Router" – a transformative shift for the core of the framework. In this talk, I'll share why we made this change, the key concepts to know, and why I'm excited about the future of React.
React Advanced Conference 2023React Advanced Conference 2023
28 min
A Practical Guide for Migrating to Server Components
Server Components are the hot new thing, but so far much of the discourse around them has been abstract. Let's change that. This talk will focus on the practical side of things, providing a roadmap to navigate the migration journey. Starting from an app using the older Next.js pages router and React Query, we’ll break this journey down into a set of actionable, incremental steps, stopping only when we have something shippable that’s clearly superior to what we began with. We’ll also discuss next steps and strategies for gradually embracing more aspects of this transformative paradigm.
TypeScript Congress 2022TypeScript Congress 2022
10 min
How to properly handle URL slug changes in Next.js
Top Content
If you're using a headless CMS for storing content, you also work with URL slugs, the last parts of any URL. The problem is, content editors are able to freely change the slugs which can cause 404 errors, lost page ranks, broken links, and in the end confused visitors on your site. In this talk, I will present a solution for keeping a history of URL slugs in the CMS and explain how to implement a proper redirect mechanism (using TypeScript!) for dynamically generated pages on a Next.js website.

Add to the talk notes: 
React Advanced Conference 2021React Advanced Conference 2021
21 min
Killing BFFs with GraphQL and Next.js
Top Content
Frontend applications are getting more and more complicated, often delivering far more than just a UI. With this growing complexity comes a growing need for knowledge from the developers creating it, as they have to deal with matters like state-management, authorization, routing and more. In this talk, I'll show you how to use GraphQL in your Next.js application to create a data layer for your application, that exists between your frontend and your backend. In this data layer, you can handle complex matters to help you to keep your frontend application clean and "stupid".