headless cms - freeCodeCamp.org

How to Build a Headless WordPress Frontend with Astro SSR on Cloudflare Pages

Tech With RJ — Mon, 20 Apr 2026 17:07:58 +0000

This tutorial shows you how to run WordPress as a headless CMS with an Astro frontend deployed to Cloudflare Pages.

For a project I was recently working on, the requirement was to use WordPress as the site's backend. Content management, blog posts, and media were all handled through the WordPress admin. The frontend was open: it could be a theme, a template, or something customized through Elementor.

I could've built the same result in Elementor, but the process would've been slower and harder to maintain. Drag-and-drop works until the design gets specific, and then every small tweak costs more time than it should.

As a full stack developer, writing code turned out to be faster for me and produced cleaner output. Tools like Claude Code make the iteration cycle even tighter. So I kept the requirement – WordPress as the backend – and decided to build the frontend separately in code.

I wanted to share how I did this so that, if you're facing similar requirements, you'll know the way forward.

By the end of this tutorial, you'll have:

A WordPress install serving content through its REST API on a subdomain
An Astro SSR frontend rendering the content on the root domain
A Cloudflare Pages deployment triggered on every git push
Security hardening for a headless WordPress setup
Draft post preview working across both systems

Prerequisites: You should be comfortable with the command line, have basic familiarity with WordPress admin, and know enough JavaScript to read and write simple functions.

To follow along, you'll need a WordPress installation, a GitHub account, and a Cloudflare account.

Why Headless WordPress?
The Architecture
Why Astro?
Infrastructure Setup
- Step 1: Move DNS to Cloudflare
- Step 2: Create the CMS Subdomain
WordPress Configuration
The Astro Frontend
CI/CD with Cloudflare Pages
Final Thoughts
Good to Know

Why Headless WordPress?

Headless WordPress separates content management from content delivery. WordPress keeps doing what it handles well: storing content and giving editors a familiar admin interface. A separate frontend handles rendering, routing, and performance.

A few situations where this split pays off:

Your content team is trained on WordPress and moving them elsewhere would slow everyone down. Headless preserves their workflow and gives you a modern frontend.
Your site needs a design or interaction pattern that a WordPress theme or page builder struggles to deliver. Custom dashboards, interactive tools, data-driven layouts, or integrations with non-WordPress APIs all fit here.
You want edge delivery and modern tooling without rebuilding content management from scratch. WordPress handles content and media well. A JavaScript frontend on a CDN handles delivery well. Headless lets each side do its job.
You need the same content across multiple surfaces. One WordPress install feeds a marketing site, a mobile app, and an internal dashboard through the same REST API.

Headless is not a fit for every site. Skip it if your site is a simple brochure, if one person does everything in the admin, or if you have no developer time to maintain a second codebase. A regular WordPress theme is the better answer there.

The Architecture

The term "headless" means you strip WordPress of its frontend responsibility. Instead of WordPress generating and serving HTML pages to visitors, it only stores and serves content through its REST API. A separate frontend framework, in this case Astro, handles what the visitor actually sees.

When a visitor loads a page, the request hits Cloudflare Pages, which runs the Astro server. Astro fetches the relevant content from WordPress via the REST API, builds the HTML, and returns it to the visitor. WordPress never touches the visitor's browser.

Content editors log into the WordPress admin at the CMS subdomain. They write, publish, and manage content as they normally would. The moment they publish, the content is live. There's no rebuild step because Astro fetches fresh data on every request.

The REST API has been built into WordPress since version 4.7. You don't need a GraphQL plugin, a paid headless CMS service, or any extra infrastructure.

Why Astro?

You could use Next.js, Nuxt, or SvelteKit here as well. But I chose Astro because its defaults fit this use case.

Astro compiles components to plain HTML and ships zero JavaScript to the browser by default. You only add client-side JavaScript where you explicitly need it.

For a CMS-driven site, most pages need none. SSR mode means every request fetches fresh data from WordPress at runtime, so content changes go live immediately without a rebuild. Cloudflare has an official adapter that handles the build output. Tailwind v4 integrates through a Vite plugin with no config file needed.

If WordPress wasn't a requirement, I would have used Next.js with Payload CMS. Payload gives you a fully typed CMS built in TypeScript that sits inside the same Next.js project, with more control over your content schema from day one. But the requirement was WordPress, and for a WordPress REST API frontend, Astro is the faster and cleaner choice.

Infrastructure Setup

Here's my setup: domain at Namecheap, WordPress on Hostinger shared hosting, and a Google Workspace email. The steps below apply to any host, whether shared hosting with cPanel or hPanel, a VPS with Apache or Nginx, or a self-managed server.

Step 1: Move DNS to Cloudflare

First, you'll need to move your domain's nameservers to Cloudflare. This gives you free DDoS protection, SSL, and the ability to attach a custom domain to Cloudflare Pages.

Before switching, verify that all DNS records transferred correctly, including your website A or CNAME records. For email, get your MX, SPF, DKIM, and DMARC values from your email provider's admin panel and add them to Cloudflare DNS first, otherwise email breaks during propagation.

Step 2: Create the CMS Subdomain

Move WordPress to cms.yourdomain.com so the root domain is free for Astro. In Cloudflare DNS, add an A record pointing cms at your server IP, or a CNAME if your host uses a CDN hostname. Then create the subdomain in your hosting panel pointing to the same WordPress directory.

One thing people miss: your server needs its own SSL certificate for the connection between Cloudflare and your origin to work. Cloudflare handles SSL at its edge, but if the origin has no certificate, you get a 525 error.

On Hostinger, this isn't automatic for new subdomains. Install it manually through hPanel. On cPanel, use Let's Encrypt. On a VPS, use Certbot.

Moving WordPress off the root domain also means /wp-admin no longer exists at your main domain, which reduces exposure. But the default login path is still /wp-admin on the subdomain. That is the first thing you should change — more on this in the Good to Know section at the end.

WordPress Configuration

Tell WordPress it Lives on the Subdomain

In wp-config.php, before the "That's all, stop editing!" comment:

define('WP_HOME',    'https://cms.yourdomain.com');
define('WP_SITEURL', 'https://cms.yourdomain.com');

WordPress admin is now at cms.yourdomain.com/wp-admin. The old path at the root domain stops working. That's intentional.

Must-Use Plugin: Redirect and Preview

WordPress has a folder called mu-plugins inside wp-content. Files placed there are treated as must-use plugins. They load automatically on every request, before regular plugins, and there is no way to activate or deactivate them through the admin UI. This makes them the right place for behaviour you never want accidentally turned off.

Create wp-content/mu-plugins/headless-redirect.php:

post_type;
    return 'https://yourdomain.com/preview?type=' . \(type . '&id=' . \)post->ID . '&token=' . $token;
}, 10, 2);

The template_redirect action fires when WordPress is about to render a page. If the visitor isn't logged in and the request is on the CMS subdomain, it redirects them to the main frontend. Logged-in editors pass through to the admin normally. REST API requests to /wp-json/... don't go through template_redirect at all, so they are unaffected.

The preview_post_link filter changes what happens when an editor clicks Preview on a draft post. By default, WordPress previews using its own theme, which in a headless setup renders blank.

This filter replaces that URL with a request to your Astro /preview page, passing the post ID, post type, and a secret token. Your Astro preview page uses those values to fetch the draft via the REST API and renders it exactly as it would appear live.

Clean Up Plugins

Now it's time to remove everything that renders the frontend: page builders, caching plugins, and hosting onboarding plugins.

But you'll want to keep Akismet, Wordfence, and Yoast SEO. Yoast adds SEO meta and Open Graph data directly to the REST API response, which your Astro pages read through post.yoast_head_json.

Then switch the active theme to a lightweight default. WordPress requires one active, but nobody sees it.

The Astro Frontend

Start with pnpm create astro@latest, then install the Cloudflare adapter and Tailwind:

pnpm add @astrojs/cloudflare
pnpm add -D @tailwindcss/vite tailwindcss

astro.config.mjs

import { defineConfig } from 'astro/config'
import cloudflare from '@astrojs/cloudflare'
import tailwindcss from '@tailwindcss/vite'

export default defineConfig({
  output: 'server',
  adapter: cloudflare({ imageService: 'passthrough' }),
  vite: { plugins: [tailwindcss()] },
})

output: 'server' puts Astro into full SSR mode. Without it, Astro pre-renders pages at build time, which breaks dynamic routes like /blog/[slug] that depend on WordPress content that didn't exist at build time.

imageService: 'passthrough' is required specifically for Cloudflare Workers. Astro's default image service uses Sharp, which depends on child_process and fs. Those Node.js built-ins don't exist in the Cloudflare Workers runtime. The deployment fails with a module resolution error. Setting passthrough skips image processing entirely and renders standard tags instead.

.env

WORDPRESS_API_URL=https://cms.yourdomain.com

Add this same variable in Cloudflare Pages project settings under Environment Variables before deploying.

src/lib/wordpress.js

This file is the single place all WordPress API calls go through. Centralising them means if the API URL or authentication changes, you update one file.

The _embed parameter is important. By default, a post response only includes the post data. Featured images, author details, and categories are separate entities with their own IDs. Without _embed, you would need additional API requests to fetch each one. Adding it inlines all that related data into the same response.

cache: 'no-store' on every fetch call is not optional. Cloudflare Workers runs a fetch cache internally that's separate from HTTP Cache-Control headers. Without disabling it, Cloudflare caches your WordPress API responses at the edge. An editor publishes a post and sees the old version on the frontend because the cached response is being served.

const WP_URL = import.meta.env.WORDPRESS_API_URL

const fetchWP = (path) =>
  fetch(`\({WP_URL}\){path}`, { cache: 'no-store' }).then((r) => r.json())

export const getPosts = (page = 1, perPage = 10) =>
  fetchWP(`/wp-json/wp/v2/posts?_embed&per_page=\({perPage}&page=\){page}`)

export const getPostBySlug = async (slug) => {
  const posts = await fetchWP(`/wp-json/wp/v2/posts?_embed&slug=${slug}`)
  return posts[0]
}

export const getCategories = () =>
  fetchWP(`/wp-json/wp/v2/categories`)

export const getPostsByCategory = (categoryId, page = 1) =>
  fetchWP(`/wp-json/wp/v2/posts?_embed&categories=\({categoryId}&page=\){page}`)

export const getAllPostsForSitemap = () =>
  fetchWP(`/wp-json/wp/v2/posts?_fields=slug,modified&per_page=100`)

The sitemap function uses _fields instead of _embed to fetch only the fields it needs, keeping that request lightweight.

src/middleware.js

Middleware runs on every request before the page handler. This one adds Cache-Control: no-store to every SSR response so Cloudflare doesn't cache the rendered HTML pages.

export function onRequest(_context, next) {
  return next().then(response => {
    const newResponse = new Response(response.body, response)
    newResponse.headers.set('Cache-Control', 'no-store, no-cache, must-revalidate')
    newResponse.headers.set('CDN-Cache-Control', 'no-store')
    return newResponse
  })
}

The original Response from Astro has immutable headers, so you can't call .headers.set() on it directly. The fix is to construct a new Response using the original body and response as the init argument. The new Response has mutable headers, so .set() works. CDN-Cache-Control is a Cloudflare-specific header that controls caching at the edge independently from the standard Cache-Control header.

src/layouts/Layout.astro

Every page goes through this layout. HTML structure, meta tags, and global imports live here so you don't repeat them on every page.

---
interface Props {
  title: string
  description?: string
}
const { title, description = '' } = Astro.props
---


  
    
    
    {title}

Named slots let the navbar and footer sit outside

, keeping the HTML landmark structure correct for accessibility.

src/pages/blog/index.astro

---
import Layout from '../../layouts/Layout.astro'
import { getPosts, getCategories, getPostsByCategory } from '../../lib/wordpress'

const page = Number(Astro.url.searchParams.get('page') ?? 1)
const categoryId = Astro.url.searchParams.get('category')

const [posts, categories] = await Promise.all([
  categoryId ? getPostsByCategory(categoryId, page) : getPosts(page, 10),
  getCategories(),
])
---

  
    All
    {categories.map((cat) => (
      {cat.name}
    ))}
  

  
    {posts.map((post) => {
      const image   = post._embedded?.['wp:featuredmedia']?.[0]?.source_url
      const imageAlt = post._embedded?.['wp:featuredmedia']?.[0]?.alt_text ?? ''
      return (
        
          {image && }
          
          
        

      )
    })}
  


  {page > 1 && Previous}
  Next

Promise.all fetches posts and categories in parallel. The category filter reads from the URL query string so the same page handles both /blog and /blog?category=5 without separate routes.

Featured images live inside post._embedded['wp:featuredmedia'][0] because _embed inlines the media object into the post response.

src/pages/blog/[slug].astro

---
import Layout from '../../layouts/Layout.astro'
import { getPostBySlug } from '../../lib/wordpress'

const { slug } = Astro.params
const post = await getPostBySlug(slug)
if (!post) return Astro.redirect('/404')

const image    = post._embedded?.['wp:featuredmedia']?.[0]?.source_url
const imageAlt = post._embedded?.['wp:featuredmedia']?.[0]?.alt_text ?? ''
const author   = post._embedded?.author?.[0]?.name
const seoTitle = post.yoast_head_json?.title ?? post.title.rendered
const seoDesc  = post.yoast_head_json?.og_description ?? ''
---

  
    
    {author} · {new Date(post.date).toLocaleDateString()}
    {image && }

Use set:html for WordPress content, not {post.content.rendered}. Astro treats curly brace expressions as text and escapes the HTML, so you see raw tags printed on the page instead of rendered content.

Always guard with if (!post) return Astro.redirect('/404'). If someone visits a slug that doesn't exist, the API returns an empty array. Without the guard, accessing properties on undefined throws an error that crashes the Cloudflare Worker and returns a 500.

post.yoast_head_json is available when Yoast SEO is active. It contains the computed SEO title and description that Yoast generates. Using it means the SEO work done in WordPress carries over to the Astro frontend automatically.

src/pages/sitemap.xml.ts

import type { APIRoute } from 'astro'
import { getAllPostsForSitemap } from '../lib/wordpress'

export const GET: APIRoute = async () => {
  const posts = await getAllPostsForSitemap()

  const urls = [
    { loc: 'https://yourdomain.com/', lastmod: new Date().toISOString() },
    { loc: 'https://yourdomain.com/blog/', lastmod: new Date().toISOString() },
    ...posts.map((p) => ({
      loc: `https://yourdomain.com/blog/${p.slug}/`,
      lastmod: p.modified,
    })),
  ]

  const xml = `

\({urls.map((u) => `  \n    \){u.loc}\n    ${u.lastmod}\n  `).join('\n')}
`

  return new Response(xml, { headers: { 'Content-Type': 'application/xml' } })
}

This generates fresh XML on every request, so the sitemap always reflects currently published posts without a rebuild.

src/styles/global.css

@import "tailwindcss";

@theme {
  --color-brand: #your-color;
  --font-sans: 'Your Font', sans-serif;
}

Tailwind v4 uses CSS-first configuration through the @theme block. CSS variables defined here become Tailwind utilities automatically. --color-brand becomes bg-brand, text-brand, and so on. No tailwind.config.js needed.

CI/CD with Cloudflare Pages

With the Astro code in place, the last piece is getting it deployed. Cloudflare Pages connects directly to GitHub, so you don't have to maintain a separate pipeline.

Here are the steps:

Push your repo to GitHub.
Go to Cloudflare Pages, create a project, connect it to your GitHub repository.
Set the build command to pnpm build and the output directory to dist.
Under Environment Variables, add WORDPRESS_API_URL pointing to https://cms.yourdomain.com.
Deploy.

After the first deploy, every push to main triggers a new deployment automatically. Cloudflare runs the build, and within minutes the new version is live globally. Content updates in WordPress go live immediately, since Astro fetches from WordPress on every request. A developer pushing code and an editor publishing a post are completely independent operations.

Final Thoughts

This setup exists because of the specific requirement that the content team was already on WordPress and changing that was not on the table.

If you're starting fresh with no CMS in place, this is probably not the stack you want. Go with something like Next.js and Payload CMS where the backend and frontend are designed to work together from the start.

But if your situation matches where content editors are already familiar with WordPress, and you need a custom frontend that a page builder can't deliver cleanly, then this separation makes sense.

Pros:

Content editors keep using WordPress. No retraining, no migration.
The frontend has full control over design and behaviour. No theme or plugin constraints.
Deployments are automatic on every push. Content changes go live immediately without a rebuild.
No added cost for most sites. WordPress stays on its existing host. Cloudflare Pages is free within generous limits, and scales to $5 per month on the Workers Paid plan if you outgrow them.

Cons:

Two systems to maintain instead of one. You operate the WordPress install (updates, plugins, backups) and maintain the Astro codebase separately.
The WordPress REST API has limitations. Complex content structures or real-time features need more work to handle compared to a purpose-built headless CMS.
Adapter and deployment target are tied together. @astrojs/cloudflare v13 drops Pages support in favor of Workers, so staying on Pages means staying on v12. Details in the Good to Know section.
Frontend changes require a developer. With Elementor, anyone with admin access could adjust layouts directly in the browser. Here, any visual change outside of content goes through code, which means it goes through you.

The stack is WordPress on existing hosting, Astro on Cloudflare Pages, with GitHub as the bridge between development and production. It solves a specific problem cleanly. Outside of that problem, there are better options.

Good to Know

Change the default login URL immediately. Every bot targets /wp-login.php and /wp-admin. Install WPS Hide Login and move it to something custom. Anyone hitting the default paths gets a 404.

Remove the /wp-json/wp/v2/users endpoint. It returns a public list of usernames. In headless mode you get author data through _embed and have no use for this endpoint. Add to the mu-plugin:

add_filter('rest_endpoints', function($endpoints) {
    unset($endpoints['/wp/v2/users']);
    unset($endpoints['/wp/v2/users/(?P[\d]+)']);
    return $endpoints;
});

Disable XML-RPC and enable 2FA. Add add_filter('xmlrpc_enabled', '__return_false') to the mu-plugin — you aren't using it in headless mode and it's a common brute force target. Enable Wordfence's Brute Force Protection and add two-factor authentication through WP 2FA for all admin accounts.

Don't upgrade @astrojs/cloudflare to v13 if you deploy via Cloudflare Pages git-push CI. v12 outputs dist/_worker.js which Pages CI expects. v13 outputs a different format for wrangler deploy — Pages CI falls back to serving the dist folder as a static site and every SSR route returns 404 with no helpful error message.

The v12 adapter throws a deprecation warning on entrypointResolution. Silence it by adding entrypointResolution: 'auto' to the adapter options. Test before committing — it changes how the build locates the Worker entry file.

Custom Post Types follow the same pattern. Register the CPT with show_in_rest: true and a rest_base, and it shows up at /wp-json/wp/v2/your-base. The same fetch helpers, _embed, and slug routing work exactly the same way.

The REST API returns pagination headers. The raw response includes X-WP-Total and X-WP-TotalPages headers before you call .json(). If you want proper previous/next pagination, read those instead of guessing whether a next page exists.

Wrap API calls in try/catch. If WordPress is unreachable, an unhandled fetch throws and returns a 500. A try/catch returns an empty page instead, which is a much better failure mode.

Preview auth uses Application Passwords. WordPress 5.6 added Application Passwords under Users → Profile. That's what WP_APP_USER and WP_APP_PASSWORD in your .env should point to — not your regular admin password. Generate one per environment. Define the preview token as a constant in wp-config.php (define('HEADLESS_PREVIEW_SECRET', '...')) and reference that constant in the mu-plugin — never hardcode secrets in version-controlled files.

How to Build a Portfolio Site with Sanity and Next.js

freeCodeCamp — Fri, 28 Jul 2023 16:30:03 +0000

By Victor Eke

Knowing how to handle content is important when creating a personal website for yourself or a client.

This is because maintaining and updating a site can result in substantial expenses if you don't do it correctly. This is even more the case if you're building for someone with a non-technical background.

To address this, you can integrate your website with a headless CMS service that offers an API for content management and updates. In this case, we will utilize Sanity for this purpose.

What is Sanity?

Sanity is a headless CMS framework for managing content. It provides tools to leverage APIs to connect to your web app providing instantaneous, rich and automated infrastructure for managing content on the cloud.

With Sanity, you can hook up pages or content that require regular updating to the studio and manage them from the content lake without having to touch code frequently. This makes the content creation and management process accessible to more people regardless of their technical background.

In this post, you'll learn how to use Sanity as a data source to build a portfolio site with Next.js 13 and Tailwind CSS. You'll also learn how to host it on Vercel and set-up webhooks to trigger deployments.

Here is a screenshot of what the portfolio site will look like. Some of the designs for this site were inspired by Tailwind's Spotlight Portfolio Template.

Finished personal project

Want to play around with it? Check out the live demo. Also, you can find the source code for the project on GitHub.

Step 1: Install Next.js

Open a terminal and run this command to install the latest version of Next.js:

npx create-next-app@latest

Select all your preferred install options. Except for the project name, I'll go with the default options.

√ What is your project named? ... sanity-nextjs-site
√ Would you like to use TypeScript with this project? ... Yes
√ Would you like to use ESLint with this project? ... Yes
√ Would you like to use Tailwind CSS with this project? ... Yes
√ Would you like to use `src/` directory with this project? ... No
√ Would you like to use App Router? (recommended) ... Yes
√ Would you like to customize the default import alias? ... No

This should install all the required dependencies, including Tailwind CSS into the project folder. To see it live run the command below:

cd sanity-nextjs-site

npm run dev

Visit http://localhost:3000 to see the site.

Step 2: Setup Sanity Studio

Sanity studio is Sanity's open source single-page app for managing your data and operations. This is the interface from which you can create, delete, and update your data within Sanity.

Install Sanity Studio

Open up a new terminal outside of your Next.js application and type the commands below:

mkdir sanity-studio

cd sanity-studio

npm create sanity@latest

Once your run the command in your terminal, you'll be prompted to select a login provider from the list of options. If you already have an account, it will authenticate your account and automatically log you in or else you can create a new account on Sanity.

Once your account has been successfully authenticated, more prompts will be provided in the terminal to configure your project. Here are the options set for the studio:

$ Project name: Sanity Next.js Site
$ Use the default dataset configuration?: Yes
$ Project output path: C:\Users\USER\Desktop\sanity-studio
$ Select project template: Clean project with no predefined schemas
$ Do you want to use TypeScript? Yes
$ Package manager to use for installing dependencies?: npm

Once completed, this should install Sanity studio locally. To see the studio, run npm run dev and visit localhost:3333, log into your account using the same method used in creating your account, and you should see the studio running locally.

Step 3: Mount Sanity Studio into Next.js

You can choose to host your studio separately, but in this tutorial you'll be mounting it together with your Next.js application using the next-sanity toolkit.

End the server running your Next app and run this command:

npm install sanity next-sanity

And then on the sanity-studio directory running the studio locally, copy the schema folder and sanity.config.ts file and paste into the root of your Next.js app.

The folder structure should look like this:

├── .next
├── app/
├── node_modules/
├── public/
├── schemas/
│   └── index.ts
├── .eslintrc.json
├── .gitignore
├── next-env.d.ts
├── next.config.js
├── package-lock.json
├── package.json
├── postcss.config.js
├── README.md
├── sanity.config.ts
├── tailwind.config.js
└── tsconfig.json

Next, inside the sanity.config.ts file, add a basePath key and give it a value of /studio or any valid URL path where you would like your studio to live.

// sanity.config.ts

import { defineConfig } from "sanity";
import { deskTool } from "sanity/desk";
import { schemaTypes } from "./schemas";

export default defineConfig({
  name: "sanity-nextjs-site",
  title: "Sanity Next.js Site",
  projectId: "ga8lllhf",
  dataset: "production",
  basePath: "/studio",
  plugins: [deskTool()],
  schema: { types: schemaTypes },
});

Here's a breakdown of each property:

name: Used to differentiate workspaces. Not compulsory for single workspace setup.
title: Title of your project. This will show up on the Studio.
projectId: This is a unique ID that points to the Sanity project you're working with.
dataset: The name of the dataset to use for your studio. Common names are production and development.
basePath: This is the URL path where your studio will be mounted.
schema: The object where your schema files will be defined.

Create the Studio Component

This is where the studio page will be mounted within your Next app. You can name this file whatever you prefer, but it must match with the basePath key specified inside the sanity.config.ts file. In my case, the file name will be studio.

To create the studio route, we'll utilize Next.js dynamic segments. Inside the app directory, create a studio/[[...index]]/page.tsx file.

app/
└── studio/
    └── [[...index]]/
         └── page.tsx

With this, when you visit any route that matches with /studio, the studio component page.tsx will be rendered.

To complete this setup, paste this code inside the component:

// app/studio/[[...index]]/page.tsx

"use client";

import { NextStudio } from "next-sanity/studio";
import config from "@/sanity.config";

export default function Studio() {
  return <NextStudio config={config} />;
}

First, NextStudio is imported from the next-sanity library and the configuration file is imported from the sanity.config.ts file you created earlier.

Now run npm run dev and visit localhost:3000/studio. You will get a prompt to add localhost:3000 as a CORS origin to your Sanity project. Just click continue to add the URL.

Once added, log into your Sanity account using the same method you used in creating your account and you should see the Studio mounted into your Next.js application as shown in the image below:

With the studio now running in your Next.js app, you don't need the separate sanity-studio directory anymore. You can delete or close it.

By default, the studio will be blank because you haven't created any schemas files. Let's do that in the next section.

Step 4: Create Content Schemas

Schemas are essentially a way of organizing datasets in a database depending on what type of content you need.

Since we're building a portfolio site, we'll create schemas to handle projects, profile, and so on. To be more specific, you'll create three schemas files for this portfolio project:

profile: Schema file for defining your personal information like name, about, skills, and so on.
project: Schema file for your projects.
work: Schema file for defining your work experience.

Let's start with the profile schema.

Profile Schema

Inside the schemas directory, create a profile.ts file.

touch schemas/profile.ts

Let's start by defining the basic properties of a schema file.

// schemas/profile.ts

import { defineField } from "sanity";
import { BiUser } from "react-icons/bi";

const profile = {
  name: "profile",
  title: "Profile",
  type: "document",
  icon: BiUser,
  fields: [],
};

export default profile;

Each schema file must contain a name, title, and type property. Here's a brief breakdown of the function of each property:

The name key is the property that is used to reference a schema in the query language. The value must be a unique value to avoid conflating schemas.
title defines what the schema type is called in the Studio UI.
type defines what schema type you're working with. The document value will tell the studio that it should make it possible to make new documents.
The icon is an optional property you can add alongside the title. To use the icon, install the react-icons library with the command npm install -D react-icons
The fields array, is where the individual input fields will be defined. Here are the fields for the profile schema:

fields: [
    defineField({
      name: "fullName",
      title: "Full Name",
      type: "string",
      validation: (rule) => rule.required(),
    }),
    defineField({
      name: "headline",
      title: "Headline",
      type: "string",
      description: "In one short sentence, what do you do?",
      validation: (Rule) => Rule.required().min(40).max(50),
    }),
    {
      name: "profileImage",
      title: "Profile Image",
      type: "image",
      description: "Upload a profile picture",
      options: { hotspot: true },
      fields: [
        {
          name: "alt",
          title: "Alt",
          type: "string",
        },
      ],
    },
    {
      name: "shortBio",
      title: "Short Bio",
      type: "text",
      rows: 4,
    },
    {
      name: "email",
      title: "Email Address",
      type: "string",
    },
    {
      name: "location",
      title: "Location",
      type: "string",
    },
    {
      name: "fullBio",
      title: "Full Bio",
      type: "array",
      of: [{ type: "block" }],
    },
    {
      name: "resumeURL",
      title: "Upload Resume",
      type: "file",
    },
    {
      name: "socialLinks",
      title: "Social Links",
      type: "object",
      description: "Add your social media links:",
      fields: [
        {
          name: "github",
          title: "Github URL",
          type: "url",
          initialValue: "https://github.com/",
        },
        {
          name: "linkedin",
          title: "Linkedin URL",
          type: "url",
          initialValue: "https://linkedin.com/in/",
        },
        {
          name: "twitter",
          title: "Twitter URL",
          type: "url",
          initialValue: "https://twitter.com/",
        },
        {
          name: "twitch",
          title: "Twitch URL",
          type: "url",
          initialValue: "https://twitch.com/",
        },
      ],
      options: {
        collapsed: false,
        collapsible: true,
        columns: 2,
      },
    },
    {
      name: "skills",
      title: "Skills",
      type: "array",
      description: "Add a list of skills",
      of: [{ type: "string" }],
    },
 ],

To understand how fields work, visualize each field object as a HTML that will be available in the studio. The value in each input will be exported to a JSON object you can use to inject your data. You can add as many fields, but each must contain a name, title, and type property.

The defineField() helper function helps enable auto-completion of field types in your schema file.

Sanity comes with its own built-in schema types: number, datetime, image, array, object, string, url, and more. You can check out the full list of schema types here.

To expose this newly created schema file to the Studio, you need to import it into the schemas array inside the schemas/index.ts file:

// schemas/index.ts

import profile from "./profile";

export const schemaTypes = [profile];

Now you can start working with it from within the studio. Visit your studio at localhost:3000/studio or whatever path you used to mount it. Then click on the Profile tab and select the edit button on the top corner to start editing the fields.

This is what that looks like:

Fill in all the fields and click publish once completed. This will append the data into a parsed JSON document. To view this JSON output, click the menu button on the top right corner and hit "Inspect" or simply hold down Ctrl Alt I on your keyboard.

Here's what the structure for the profile schema looks like:

Inspect schema document

With this, you can easily query the data to fetch the exact content you need in your front-end. Let's do that in the next section.

Step 5: Query Data using GROQ

GROQ (Graph-Relational Object Queries) is Sanity's query language designed to query collections of largely schema-less JSON documents. The idea behind the query language is to be able to describe exactly what information you need from your schema, or filter certain data, and return only specific elements from your data

To start using GROQ, first create a sanity/sanity.client.ts file in your project root directory.

mkdir sanity && touch sanity/sanity.client.ts

Paste the code into this file:

// sanity/sanity.client.ts

import { createClient, type ClientConfig } from "@sanity/client";

const config: ClientConfig = {
  projectId: "ga8lllhf",
  dataset: "production",
  apiVersion: "2023-07-16",
  useCdn: false,
};

const client = createClient(config);

export default client;

apiVersion: The version of the Sanity API you're using. For the latest API version, use your current date in this format YYYY-MM-DD.
useCdn is used to disable edge cases

What this file does is provide a few configurations that will be defined in each query so this is just to avoid repeating it every time. Now for the main query, create a sanity/sanity.query.ts file.

touch sanity/sanity.query.ts

Note: There is not clear-cut way to arrange or name these files so feel free to change it up as needed.

Here's the basic query for the profile schema:

// sanity/sanity.query.ts

import { groq } from "next-sanity";
import client from "./sanity.client";

export async function getProfile() {
  return client.fetch(
    groq`*[_type == "profile"]{
      _id,
      fullName,
      headline,
      profileImage {alt, "image": asset->url},
      shortBio,
      location,
      fullBio,
      email,
      "resumeURL": resumeURL.asset->url,
      socialLinks,
      skills
    }`
  );
}

Here we created an exported async function called getProfile() that returns a groq fetch query wrapped with the client config created in the first step.

The groq query starts with an asterisk (*) which represents every document in your dataset followed by a filter in brackets. The filter above returns the schema that has a _type of "profile".

_Schema JSON showing profile schema type

The filter is followed by curly braces which contains specific content from the dataset needed like: fullName, headline, profileImage and so on. This is called projections in the Sanity docs and it returns the entire data as an array.

If you want to learn more about querying using GROQ, I suggest you go through the how queries work section in the documentation. For syntax highlighting of your GROQ query, install the sanity.io extension available on the Visual Studio Code marketplace.

We're done with the configuration you need to start using your content. Let's look at how to display this content in your Next application.

Step 6: Display Content in your Next.js App

This section is broken down into two separate parts: Displaying the hero section, and about page content.

Add Types to Data Content

Since you're using TypeScript for this project, it is important to first provide the types for the data coming from the studio.

Create a types/index.ts file in the root directory and add the profile type below:

// types/index.ts

import { PortableTextBlock } from "sanity";

export type ProfileType = {
  _id: string,
  fullName: string,
  headline: string,
  profileImage: {
    alt: string,
    image: string
  },
  shortBio: string,
  email: string,
  fullBio: PortableTextBlock[],
  location: string,
  resumeURL: string,
  socialLinks: string[],
  skills: string[],
};

PortableTextBlock is a unique type coming from Sanity that properly defines the data type for the rich text editor.

Now you've defined the types for your content, it's easier to visualize the data you're expecting in your studio.

Display Hero Section

First, remove all the styling inside the global.css file, except for the necessary Tailwind imports at the top. Then clear everything inside the root page.tsx file of your Next.js app and paste the following code inside:

// app/page.tsx

import { getProfile } from "@/sanity/sanity.query";
import type { ProfileType } from "@/types";
import HeroSvg from "./icons/HeroSvg";;

export default async function Home() {
  const profile: ProfileType[] = await getProfile();

  return (
    <main className="max-w-7xl mx-auto lg:px-16 px-6">
      <section className="flex xl:flex-row flex-col xl:items-center items-start xl:justify-center justify-between gap-x-12 lg:mt-32 mt-20 mb-16">
        {profile &&
          profile.map((data) => (
            <div key={data._id} className="lg:max-w-2xl max-w-2xl">
              <h1 className="text-3xl font-bold tracking-tight sm:text-5xl mb-6 lg:leading-[3.7rem] leading-tight lg:min-w-[700px] min-w-full">
                {data.headline}
              h1>
              <p className="text-base text-zinc-400 leading-relaxed">
                {data.shortBio}
              p>
              <ul className="flex items-center gap-x-6 my-10">
                {Object.entries(data.socialLinks)
                  .sort()
                  .map(([key, value], id) => (
                    <li key={id}>
                      <a
                        href={value}
                        rel="noreferer noopener"
                        className="flex items-center gap-x-3 mb-5 hover:text-purple-400 duration-300"
                      >
                        {key[0].toUpperCase() + key.toLowerCase().slice(1)}
                      a>
                    li>
                  ))}
              ul>
            div>
          ))}
        <HeroSvg />
      section>
    main>
  );
}

First the getProfile query is imported from the sanity.query.ts file which is a filtered-down version of our data coming from the schema.
ProfileType is imported to add types to the data.
The profile array is mapped inside the component to return the headline, shortBio, and socialLinks.
is essentially an svg element imported as a react component added just for UI aesthetics. You can download the HeroSVG icon component.

Here's the resulting output:

hero section output

To speed things up, I've created the navbar and footer navigation components. Simply download the directory and import them into the layout.tsx file like so:

// app/layout.tsx

import "./globals.css";
import type { Metadata } from "next";
import { Inter } from "next/font/google";
import Navbar from "./components/global/Navbar";
import Footer from "./components/global/Footer";

const inter = Inter({ subsets: ["latin"] });

export const metadata: Metadata = {
  title: "Sanity Next.js Portfolio Site",
  description: "A personal portfolio site built with Sanity and Next.js",
  openGraph: {
    images: "add-your-open-graph-image-url-here",
  },
};

export default function RootLayout({children}: {children: React.ReactNode}) {
  return (
    <html lang="en">
      <body className={`${inter.className} bg-zinc-900 text-white`}>
        <Navbar />
        {children}
        <Footer />
      body>
    html>
  );
}

With these components, the home page should look like this:

home page with navbar and footer components

Display About Page

Let's build the about page using content from the getProfile query as well. In this section you'll need to install a React library called PortableTextBlock by Sanity. This library will allow you easily de-structure the block content of the rich text editor.

To install this package run npm install -D @portabletext/react and I'll explain how to use it later on.

Create an about folder inside the app directory and add a page.tsx file inside this new folder. You can also do this quickly using the following command:

mkdir app/about && touch app/about/page.tsx

Here's the code snippet for the about page:

// app/about/page.tsx

import Image from "next/image";
import { getProfile } from "@/sanity/sanity.query";
import type { ProfileType } from "@/types";
import { PortableText } from "@portabletext/react";
import { BiEnvelope, BiFile } from "react-icons/bi";

export default async function About() {
  const profile: ProfileType[] = await getProfile();

  return (
    <main className="lg:max-w-7xl mx-auto max-w-3xl md:px-16 px-6">
      {profile &&
        profile.map((data) => (
          <div key={data._id}>
            <section className="grid lg:grid-cols-2 grid-cols-1 gap-x-6 justify-items-center">
              <div className="order-2 lg:order-none">
                <h1 className="lg:text-5xl text-4xl lg:leading-tight basis-1/2 font-bold mb-8">
                  I'm {data.fullName}. I live in {data.location}, where I
                  design the future.
                h1>

                <div className="flex flex-col gap-y-3 text-zinc-400 leading-relaxed">
                  <PortableText value={data.fullBio} />
                div>
              div>

              <div className="flex flex-col lg:justify-self-center justify-self-start gap-y-8 lg:order-1 order-none mb-12">
                <div>
                  <Image
                    className="rounded-2xl mb-4 object-cover max-h-96 min-h-96 bg-top bg-[#1d1d20]"
                    src={data.profileImage.image}
                    width={400}
                    height={400}
                    quality={100}
                    alt={data.profileImage.alt}
                  />

                  <a
                    href={`${data.resumeURL}?dl=${data.fullName}_resume`}
                    className="flex items-center justify-center gap-x-2 bg-[#1d1d20] border border-transparent hover:border-zinc-700 rounded-md duration-200 py-2 text-center cursor-cell font-medium"
                  >
                    <BiFile className="text-base" /> Download Resumé
                  a>
                div>

                <ul>
                  <li>
                    <a
                      href={`mailto:${data.email}`}
                      className="flex items-center gap-x-2 hover:text-purple-400 duration-300"
                    >
                      <BiEnvelope className="text-lg" />
                      {data.email}
                    a>
                  li>
                ul>
              div>
            section>

            <section className="mt-24 max-w-2xl">
              <h2 className="font-semibold text-4xl mb-4">Expertiseh2>
              <p className="text-zinc-400 max-w-lg">
                I've spent few years working on my skills. In no particular
                order, here are a few of them.
              p>

              <ul className="flex flex-wrap items-center gap-3 mt-8">
                {data.skills.map((skill, id) => (
                  <li
                    key={id}
                    className="bg-[#1d1d20] border border-transparent hover:border-zinc-700 rounded-md px-2 py-1"
                  >
                    {skill}
                  li>
                ))}
              ul>
            section>
          div>
        ))}
    main>
  );
}

Similar to the home page, we're also fetching the data from the getProfile query and assigning the ProfileType for type safety.
The profile data is also mapped to get the individual properties: fullName, location, fullBio, profileImage, resumeURL, email, and skills array.
The portable text editor was de-structured using the component which takes in a value prop that receives the content of the rich text editor.

Adding the image from Sanity's CDN should throw an error in Next.js since you haven't added Sanity's image source hostname in your next.config.ts file. Here's how to do it in Next.js 13:

// next.config.ts

/** @type {import('next').NextConfig} */
const nextConfig = {};

module.exports = {
  images: {
    remotePatterns: [
      {
        protocol: "https",
        hostname: "cdn.sanity.io",
        port: "",
      },
    ],
  },
};

Here's the resulting output:

About page

Work Experience

In a typical portfolio site, you may need to create a list of past work experience. This is what the schema would look like:

Create a schemas/job.ts file and paste the following code:

// schemas/job.ts

import { BiBriefcase } from "react-icons/bi";

const job = {
  name: "job",
  title: "Job",
  type: "document",
  icon: BiBriefcase,
  fields: [
    {
      name: "name",
      title: "Company Name",
      type: "string",
      description: "What is the name of the company?",
    },
    {
      name: "jobTitle",
      title: "Job Title",
      type: "string",
      description: "Enter the job title. E.g: Software Developer",
    },
    {
      name: "logo",
      title: "Company Logo",
      type: "image",
    },
    {
      name: "url",
      title: "Company Website",
      type: "url",
    },
    {
      name: "description",
      title: "Job Description",
      type: "text",
      rows: 3,
      description: "Write a brief description about this role",
    },
    {
      name: "startDate",
      title: "Start Date",
      type: "date",
    },
    {
      name: "endDate",
      title: "End Date",
      type: "date",
    },
  ],
};

export default job;

To expose this new schema file to the studio, add it to the schemaTypes array inside the schemas/index.ts and you should see it in your studio.

Here's the resulting output:

job schema fields in sanity studio

Click the create button and add as many records as you want. Now you can move on to querying the data.

Similar to how the profile schema was queried inside the sanity.query.ts file, you will do that for the job schema too:

// sanity/sanity.query.ts

export async function getJob() {
  return client.fetch(
    groq`*[_type == "job"]{
      _id,
      name,
      jobTitle,
      "logo": logo.asset->url,
      url,
      description,
      startDate,
      endDate,
    }`
  );
}

Next add the types for the returned dataset:

// types/index.ts

export type JobType = {
  _id: string;
  name: string;
  jobTitle: string;
  logo: string;
  url: string;
  description: string;
  startDate: Date;
  endDate: Date;
};

And then to display it in your front-end, create a Job.tsx file inside the components directory and add the following code:

// app/components/Job.tsx

import Image from "next/image";
import { getJob } from "@/sanity/sanity.query";
import type { JobType } from "@/types";

export default async function Job() {
  const job: JobType[] = await getJob();

  return (
    <section className="mt-32">
      <div className="mb-16">
        <h2 className="font-semibold text-4xl mb-4">Work Experienceh2>
      div>

      <div className="flex flex-col gap-y-12">
        {job.map((data) => (
          <div
            key={data._id}
            className="flex items-start lg:gap-x-6 gap-x-4 max-w-2xl relative before:absolute before:bottom-0 before:top-[4.5rem] before:left-7 before:w-[1px] before:h-[calc(100%-50px)] before:bg-zinc-800"
          >
            <a
              href={data.url}
              rel="noreferrer noopener"
              className="min-h-[60px] min-w-[60px] rounded-md overflow-clip relative"
            >
              <Image
                src={data.logo}
                className="object-cover"
                alt={`${data.name} logo`}
                fill
              />
            a>
            <div className="flex flex-col items-start">
              <h3 className="text-xl font-bold">{data.name}h3>
              <p>{data.jobTitle}p>
              <small className="text-sm text-zinc-500 mt-2 tracking-widest uppercase">
                {data.startDate.toString()} - {data.endDate.toString()}
              small>
              <p className="text-base text-zinc-400 my-4">{data.description}p>
            div>
          div>
        ))}
      div>
    section>
  );
}

To view the component, you can import it into the home page:

// Note: This is a truncated version of the home page (app/page.tsx) file to illustrate how the Job component is declared.

import { getProfile } from "@/sanity/sanity.query";
import type { ProfileType } from "@/types";
import HeroSvg from "./icons/HeroSvg";
import Job from "./components/Job"; // import job component

export default async function Home() {
  const profile: ProfileType[] = await getProfile();

  return (
    <main className="max-w-7xl mx-auto lg:px-16 px-6">
      <section> // code truncated for brevity
        <HeroSvg />
      section>
      <Job /> // declare job component
    main>
  );
}

Here's the resulting output:

work experience section

By now, you should have a clear understanding of the necessary steps to showcase content with Sanity: Create schema file, > Query the dataset > Display the content in your application.

Let's now focus on configuring data for dynamic routes in your application and leveraging it to construct the projects page.

Project Schema

As always, you'll start by creating the schema file:

touch schemas/project.ts

Here's the code for the schema fields:

import { BiPackage } from "react-icons/bi";
import { defineField } from "sanity";

const project = {
  name: "project",
  title: "Project",
  description: "Project Schema",
  type: "document",
  icon: BiPackage,
  fields: [
    {
      name: "name",
      title: "Name",
      type: "string",
      description: "Enter the name of the project",
    },
    defineField({
      name: "tagline",
      title: "Tagline",
      type: "string",
      validation: (rule) => rule.max(60).required(),
    }),
    defineField({
      name: "slug",
      title: "Slug",
      type: "slug",
      description:
        "Add a custom slug for the URL or generate one from the name",
      options: { source: "name" },
      validation: (rule) => rule.required(),
    }),
    {
      name: "logo",
      title: "Project Logo",
      type: "image",
    },
    {
      name: "projectUrl",
      title: "Project URL",
      type: "url",
    },
    {
      name: "coverImage",
      title: "Cover Image",
      type: "image",
      description: "Upload a cover image for this project",
      options: { hotspot: true },
      fields: [
        {
          name: "alt",
          title: "Alt",
          type: "string",
        },
      ],
    },
    {
      name: "description",
      title: "Description",
      type: "array",
      description: "Write a full description about this project",
      of: [{ type: "block" }],
    },
  ],
};

export default project;

Next, expose the schema to the schemaTypes array:

import job from "./job";
import profile from "./profile";
import project from "./project";

export const schemaTypes = [profile, job, project];

Visit your studio, click the project schema, and add as many projects as you want. You can download the asset files used for each project from the repository.

Sanity studio showing project schema fields

Here's the query to get all the projects:

// sanity/sanity.query.ts

export async function getProjects() {
  return client.fetch(
    groq`*[_type == "project"]{
      _id, 
      name,
      "slug": slug.current,
      tagline,
      "logo": logo.asset->url,
    }`
  );
}

Next, add the types.

// types/index.ts

export type ProjectType = {
  _id: string;
  name: string;
  slug: string;
  tagline: string;
  projectUrl: string;
  logo: string;
  coverImage: {
    alt: string | null;
    image: string;
  };
  description: PortableTextBlock[];
};

And then display the content in your front-end.

mkdir app/projects && touch app/projects/page.tsx

This will create a page.tsx file inside a directory called project. Here's the code for the projects:

// app/projects/page.tsx

import Image from "next/image";
import Link from "next/link";
import { getProjects } from "@/sanity/sanity.query";
import type { ProjectType } from "@/types";

export default async function Project() {
  const projects: ProjectType[] = await getProjects();

  return (
    <main className="max-w-7xl mx-auto md:px-16 px-6">
      <section className="max-w-2xl mb-16">
        <h1 className="text-3xl font-bold tracking-tight sm:text-5xl mb-6 lg:leading-[3.7rem] leading-tight">
          Featured projects I've built over the years
        h1>
        <p className="text-base text-zinc-400 leading-relaxed">
          I've worked on tons of little projects over the years but these
          are the ones that I'm most proud of. Many of them are
          open-source, so if you see something that piques your interest, check
          out the code and contribute if you have ideas for how it can be
          improved.
        p>
      section>

      <section className="grid xl:grid-cols-3 md:grid-cols-2 grid-cols-1 gap-5 mb-12">
        {projects.map((project) => (
          <Link
            href={`/projects/${project.slug}`}
            key={project._id}
            className="flex items-center gap-x-4 bg-[#1d1d20] border border-transparent hover:border-zinc-700 p-4 rounded-lg ease-in-out"
          >
            <Image
              src={project.logo}
              width={60}
              height={60}
              alt={project.name}
              className="bg-zinc-800 rounded-md p-2"
            />
            <div>
              <h2 className="font-semibold mb-1">{project.name}h2>
              <div className="text-sm text-zinc-400">{project.tagline}div>
            div>
          Link>
        ))}
      section>
    main>
  );
}

Here's the resulting output:

project page

Display Dynamic Routes

Each project card is wrapped in a link that points to their respective page based on the slug: /projects/${project.slug}. With this, the dynamic component can be easily created in next.js

Create a folder called [project] (wrapped in square brackets) inside the projects directory, and add a page.tsx file.

You can also do this via the terminal:

mkdir app/projects/[project] && touch app/projects/[project]/page.tsx

This folder enclosed in square brackets is known as a dynamic segment in Next.js, and it allows the component to be mounted based on the params property.

Since you've already created the project schema type, all that's left is to query the dataset to fetch single projects.

Here's the query to get single projects:

// sanity/sanity.query.ts

export async function getSingleProject(slug: string) {
  return client.fetch(
    groq`*[_type == "project" && slug.current == $slug][0]{
      _id,
      name,
      projectUrl,
      coverImage { alt, "image": asset->url },
      tagline,
      description
    }`,
    { slug }
  );
}

To fetch the slug from the route, we've added a parameter called slug into the function, which will allow the getSingleProject function to be called with the respective slug using the Next.js params property.

// app/projects/[project]/page.tsx

import Image from "next/image";
import { Metadata } from "next";
import { getSingleProject } from "@/sanity/sanity.query";
import type { ProjectType } from "@/types";
import { PortableText } from "@portabletext/react";
import fallBackImage from "@/public/project.png";

type Props = {
  params: {
    project: string;
  };
};

// Dynamic metadata for SEO
export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const slug = params.project;
  const project: ProjectType = await getSingleProject(slug);

  return {
    title: `${project.name} | Project`,
    description: project.tagline,
    openGraph: {
      images: project.coverImage?.image || "add-a-fallback-project-image-here",
      title: project.name,
      description: project.tagline,
    },
  };
}

export default async function Project({ params }: Props) {
  const slug = params.project;
  const project: ProjectType = await getSingleProject(slug);

  return (
    <main className="max-w-6xl mx-auto lg:px-16 px-8">
      <div className="max-w-3xl mx-auto">
        <div className="flex items-start justify-between mb-4">
          <h1 className="font-bold lg:text-5xl text-3xl lg:leading-tight mb-4">
            {project.name}
          h1>

          <a
            href={project.projectUrl}
            rel="noreferrer noopener"
            className="bg-[#1d1d20] text-white hover:border-zinc-700 border border-transparent rounded-md px-4 py-2"
          >
            Explore
          a>
        div>

        <Image
          className="rounded-xl border border-zinc-800"
          width={900}
          height={460}
          src={project.coverImage?.image || fallBackImage}
          alt={project.coverImage?.alt || project.name}
        />

        <div className="flex flex-col gap-y-6 mt-8 leading-7 text-zinc-400">
          <PortableText value={project.description} />
        div>
      div>
    main>
  );
}

Since the data coming from the dataset is a single project and not an array, no de-structuring is required.

Here's the resulting output:

Dynamic project page

Add Loading States

Next.js 13 introduced a special file loading.js that helps you create an instant loading state from the server while the content of a route segment loads. This helps users understand the app is responding and provides a better user experience.

With this special file, you can create a loading state that mimics the UI of the single project page easily.

Create a loading.tsx file inside the [project] directory and add the code snippet:

// projects/[project]/loading.tsx

export default function Loading() {
  return (
    <div className="max-w-3xl mx-auto lg:px-0 px-8">
      <div className="flex items-center justify-between mb-6">
        <span className="w-52 h-11 bg-[#1d1d20] rounded-sm animate-pulse">span>
        <span className="w-20 h-11 bg-[#1d1d20] rounded-sm animate-pulse">span>
      div>
      <div className="w-full h-96 mb-8 bg-[#1d1d20] rounded-sm animate-pulse">div>
      <div className="flex flex-col gap-y-2">
        <span className="w-full h-5 bg-[#1d1d20] rounded-sm animate-pulse">span>
        <span className="w-full h-5 bg-[#1d1d20] rounded-sm animate-pulse">span>
      div>
    div>
  );
}

Here's the resulting output:

dynamic project page showing next.js instant loading state

Fix Studio Layout

You may have noticed the navbar and footer components are showing up in the studio route. This is because these components we're defined in the root layout —which applies to all routes in the application.

navbar and footer components in studio page

To fix this, you'll have to create a separate layout.tsx file for the studio component:

Create two folders wrapped in parenthesis inside the app directory. Name one folder (site), and the other (studio). These folders are wrapped in parenthesis to prevent Next.js from mounting them as routes.

Move all the files in the app directory that relates to the next app except the studio folder, global.css and favicon.ico into the (site) directory, and then move the studio folder inside the (studio) directory.

The only files that will live in the app root is global.css and favicon.ico.

Here's what your new folder structure should look like:

app/
├── (site)/
│   ├── about/
│   ├── components/
│   ├── icons/
│   ├── projects/
│   ├── layout.tsx
│   └── page.tsx
├── (studio)/
│   └── studio/
├── favicon.ico
└── global.css

Once completed, create a layout.tsx file inside the (studio) directory and paste the following code snippet inside:

import "../globals.css";

export default function StudioLayout({children}: {children: React.ReactNode}) {
  return (
    <html lang="en">
      <body>{children}body>
    html>
  );
}

Update all the imports that may have changed, run your server again and you should see your studio up and running, without the components.

Studio page without navbar and footer components

Step 7: Deployment

Deploying a Sanity powered Next.js application is a pretty straightforward process. Follow this guide to set-up your account and deploy with Vercel.

After successfully deploying your site, visit the studio route; your-site-name/studio, and you should get a prompt to add the URL to the CORS setting in Sanity:

Sanity CORS settings prompt

Simply click "continue" and follow the on-screen instructions to do so. If successful, you should be able to see your studio.

Setup Sanity Webhooks for Studio Update

Updates made to your site would be triggered only on build time. What this means is that if you update a field in your studio using the hosted link, you would have to manually trigger a deployment on Vercel to see the changes.

Having to trigger the deployment server each time can be a cumbersome task, especially when building for a client.

In this section, I'll guide you through the steps to manually deploy your site whenever a change is made to your studio using Sanity GROQ-powered Web Hooks.

Create a Deploy Hook on Vercel

First, you will need the URL endpoint from your hosting service to trigger the deployment.

Navigate to your project settings on Vercel and click the Git tab. Under the Deploy Hooks section, choose a name for your hook and the select the branch that will be deployed when the generated URL is requested.

creating the hook

Submit the form and copy the URL endpoint generated by Vercel.

Trigger Hook Using Sanity GROQ-powered Webhooks

Visit sanity.io/manage, pick your project, navigate to the API section and click on the "Create webhook" button.

Sanity GROQ-powered Webhooks

Fill in the form with information about the hook you want to create.

Name: Portfolio Deployment.
Description: Trigger rebuild when portfolio content is created, updated, and deleted.
URL: [Paste the URL endpoint generated by Vercel here].
Dataset: The dataset to apply the hook to.
Trigger on: Check the "create", "update", and "delete" boxes.

Leave filter and projection inputs blank so the hook will be applied to all documents, and for the rest of the fields, leave it as is and hit save.

sanity groq powered hook created

Now visit your hosted studio and update any document. Once you click publish, this should trigger the deploy hook and update your site when completed.

deploy hook triggering deployment on Vercel

Another good alternative to setting up live updates in your Sanity/Next.js app is using Incremental Static Regeneration (ISR), which is a better option if you're building a large scale application.

And that's it! You can see the Live Preview here and find the GitHub URL here.

What Next?

Although this tutorial covered a lot of useful information, there are still many more possibilities with Sanity that you can explore.

You can customize your studio, integrate third-party APIs, build a storefront with Shopify, and much more.

If you found this article enjoyable and want to dive deeper into the world of Sanity, I recommend checking out the following resources:

Thanks for reading. Share, and subscribe to my blog for future updates.

GitHub | Twitter | Blog | LinkedIn

Headless CMS Explained – What it is and When You Should Use it

Daniel Madalitso Phiri — Tue, 27 Jul 2021 17:53:47 +0000

By Daniel Madalitso Phiri

CMSs are pretty hard to ignore because they're everywhere on the internet. WordPress, for example, powers nearly 40% of the internet today.

In this article, we'll cover what CMSs are and why you should care about them. I'll also introduce you to a new type of CMS that seems to be everywhere at the moment – the Headless CMS. And we'll do all this with a story!

Life has a funny way of making you try things. And after years of ignoring CMSs as a technology, in mid 2020 I got a job at Strapi, a headless CMS tool. Since then, I have developed a pretty good understanding of what these things do – so let's get into it.

What is a CMS?

A Content Management System (CMS) is a tool that helps users create, manage, and modify digital content.

In this article, however, I won’t get into the nitty-gritty of it. Instead, if you want to learn more you can have a look at an article I wrote that goes deeper into various types of CMSs.

What is a Headless CMS?

A headless CMS has a back end where content is prepared – and that's it. The content and its data are only accessible via calls made to the API, whether it's REST or GraphQL.

I like to use this diagram to illustrate how Headless works, so hopefully it paints a clearer picture.

Monolithic vs decoupled vs headless architectures

Besides serving content to multiple platforms, there are a couple other reasons why you would want to use a Headless CMS.

You don’t want to give up developer flexibility

Adopting a Headless architecture by default means that you have the flexibility of selecting a front end tool of your choosing. And for many developers, this is a critical advantage.

You need a secure content solution

Decoupling the front end from the back end makes targeted attacks much harder. This is something some traditional CMSs still struggle with today.

You want to future proof your tech stack

Going headless also means that you’re less dependent on a single solution for a front end. Should you need to upgrade to a more modern front end or add a new front end altogether, headless makes this much easier.

You need to create custom and personalized experiences

This is becoming a really important benefit for headless CMSs for many organizations.

With headless you have the opportunity to tailor different experiences for different platforms all from a single content source.

How I got into Headless CMSs

So I really like GraphQL, and that’s how I got started with Strapi. Working for a CMS was like diving head first into this ecosystem. I thought I understood Headless CMSs because to me they were “data, API, frontend” and that’s how I thought about it.

Well, we use these things to build our front ends, but we often overlook the content management side of things when we think about building a front end like that. And it wasn't until I started working with Strapi that I recognized my assumption.

“Content Management” sounds kinda boring, right? And CMS? “Ewww why would I want to use such a tool?” I know! Me too, but hear me out. CMSs actually pretty useful. So let’s talk about how and why a CMS might help you out.

Why Do You Need a Headless CMS?

For starters, there’s no downplaying the role of content in today's world. Content is everywhere and manifests itself in so many forms through text, audio, video, and more.

For a long time, computers and browsers were the main tool for content consumption. We read blogs, watched YouTube videos, and listened to podcasts on our personal computers.

Gradually our computers got smaller and less obvious. Content in its many shapes and forms started to appear all around us. It showed itself in mobile phones, on our smart televisions, in our cars, in our virtual assistants and wearable devices.

The way people consumed content changed, and so did the way we had to build content-consuming experiences.

So How Does Headless CMS Help?

Traditionally, CMSs were monoliths with the front end and back end tightly coupled. The content you added in the CMS back end only showed up on the front end it was coupled to - think WordPress and Drupal.

This proved inefficient as developers needed a better way to build and adapt to this new consumer behavior.

The solution? Rip the head off a traditional CMS and make it possible for your back end to deliver content to multiple platforms. This was how Headless was born.

Why You Might Not Need a Headless CMS

Headless isn't necessarily the right solution for all use cases, though. It might not be for you if...

You have a small team

Adopting and building a headless architecture takes quite a bit of effort. To reap all its benefits you would have to have a dedicated developer team to build your front end as well as people on your team to work on adding content to your CMS.

You rely heavily on a simple live preview implementation

Live previews on Headless CMSs aren’t the most intuitive to set up (as of writing this) and take some effort from developers to implement.

You only require simple publishing capabilities

As we just learned, headless takes a reasonable amount of effort to get it working efficiently and effectively.

If you need only simple publishing capabilities without features like internationalization or role-based access control, then it’s best to wait till you need those additional features to use a Headless CMS.

Use Cases for a Headless CMS

A lot of my early CMS projects centered around corporate sites and personal blogs, which are both solid use cases for headless. But I don’t build sites full time so I don’t ship code often.

Personally I’ve used a CMS to help build a Restaurant Catalog, an Event Website, and an Online Quiz.

There’s folks using headless CMSs to build eCommerce sites, Covid tracking projects, hospital management systems, inventory management applications, mobile catalogs, VR games, and some people even run email campaigns with them. So many possibilities.

Conclusion

Seeing what people are building with CMSs is very inspiring. And I’ve gained a huge appreciation for CMSs as a technology. What I once thought was a boring tool actually powers so much of the world around me.

There are lots of use cases for Headless CMS these days. And while at the moment there is a huge focus on serving developers (which many CMSs are doing well), we still have a ways to go to make the content editor's experience better.

It’s exciting having a foot in the race, and all I can tell you is that it's going to be an amazing next few years for Headless technology in general.

So hopefully this article helps you jump on the bandwagon and get a better understanding of what the technology can and cannot do.

After all, at the end of the day, the choice is yours!

Resources

Headless CMS | Jamstack.org
What is a Headless CMS
What’s a Headless CMS and Why Should You Care
CMS Comparison

How to Create a Travel Bucket List Map with Gatsby, React Leaflet, & Hygraph

Colby Fayock — Tue, 23 Jun 2020 14:45:00 +0000

Traveling is fun and we all have a lot of places we want to visit, but rarely do we have time to do it all at once. That’s what bucket lists are for! How can we create a custom mapping app that we can show all of our the destinations on our bucket list?

Note: As of July 2022, GraphCMS is now Hygraph.

What are we going to build?
Step 1: Creating a new app with Gatsby Starter Leaflet
Step 2: Creating and managing a list of travel locations with GraphCMS
Step 3: Querying our GraphCMS location data with Gatsby and GraphQL
Step 4: Creating a bucket list of destinations and adding them to the map
What else other features can we add to our app?
Want to learn more about maps?

What are we going to build?

We’re going to build a mapping app with Gatsby managed by a CMS that will both display markers on a map and show our locations in a simple text-based list for our bucket list locations.

Demo of a Travel Bucket List mapping app

We’ll spin up the app with a Gatsby Starter for Leaflet and then we’ll use GraphCMS to create and manage the list of locations for our map!

Woah, a mapping app?

Yup. If you haven't played with maps before, don't be discouraged! It's not as bad as you probably think. If you'd rather start with mapping basics, you can read more about how mapping works first.

Step 1: Creating a new app with Gatsby Starter Leaflet

We’ll start off with Gatsby Starter Leaflet. This is going to give us a basic React application with our mapping tools already built in.

Creating a new Gatsby app with Gatsby Starter Leaflet

To get started, navigate to where you want to create your new app and run:

gatsby new my-travel-bucket-list https://github.com/colbyfayock/gatsby-starter-leaflet

Note: you can replace my-travel-bucket-list with whatever you want. This will be used to create the new folder for the app.

Once you run that, Gatsby will pull down the Starter and install the dependencies. After it’s complete, navigate to that directory and run the development command:

cd my-travel-bucket-list
yarn develop
# or
npm run develop

Once it’s finished location, your app should be ready to go!

Cleaning our some demo code

Because we’re using a Starter, it has a little bit of demo code. Let’s clean that out to avoid any confusion.

Open up the src/pages/index.js file.

First, remove everything inside of mapEffect except the first line and set up an alias for leafletElement to map:

async function mapEffect({ leafletElement: map } = {}) {
  if ( !map ) return;
}

With that gone, we can remove the markerRef definition at the top of the IndexPage component, remove the ref={markerRef} prop from our component, and the useRef import next to React.

Now, we can remove all of the variables that start with popup and time, including:

timeToZoom
timeToOpenPopupAfterZoom
timeToUpdatePopupAfterZoom
popupContentHello
popupContentGatsby

Lastly, you can remove all of the following lines:

import L from 'leaflet';
...
import { promiseToFlyTo, getCurrentLocation } from 'lib/map';
...
import gatsby_astronaut from 'assets/images/gatsby-astronaut.jpg';
...
const ZOOM = 10;

Once done, we should be ready to go with a basic app with a map!

New app with Gatsby Starter Leaflet

Follow along with the commit!

Step 2: Creating and managing a list of travel locations with GraphCMS

Creating a GraphCMS account

To get started with GraphCMS, you’ll need an account. I’m not going to walk you through this part, but the good news is they have a generous free tier that makes it easy to sign up for us to use for our demo!

Alternatively, if you already have an account, you can make sure you’re logged in.

Creating a new GraphCMS project

Once logged in, we’ll want to create a new project. We’re going to create one manually, so once at the GraphCMS Dashboard, select Create new project:

Creating a new project in GraphCMS

Here, you can enter whatever you’d like for the Name and Description such as:

Name: My Travel Bucket List
Description: The locations that I want to travel to some day!

Below that you’ll see a map where you’ll select a Region. This is where your database data will live, so while it probably doesn’t matter too much for our purposes, you can choose the one that’s closest to you.

Configuring a new project in GraphCMS

After you select your options, go ahead and click Create Project.

Selecting the Personal plan in GraphCMS

Next, you’ll be presented with billing options. Since we’re just creating a demo, under Personal select Continue at which point we’ll be dropped into our new GraphCMS project dashboard.

Creating a new Content Model Schema with GraphCMS

In GraphCMS, a Content Model refers to a specific type of data that has specific properties associated with it. In our case, our Model will be a Destination, which will be defined by a Name and a Location.

First, navigate to the Schema section of GraphCMS in the left sidebar and select Create Model.

Creating a new Schema Model in GraphCMS

Once selected, you’ll see a popup that asks for a bit more information. Here, you can type in “Destination” as the Display Name, which will also fill in most of the other fields. We’ll leave those as is.

Configuring a new Model in GraphCMS

Feel free to add a description if you’d like, but it’s not required. Then select Create model.

Now that we have our Model, we need our properties.

First, select Single line text in the right list of fields and add a Display Name of “Name”. This will also fill out App Id which you can leave as is. Then click Create.

Adding and configuring a new text field in GraphCMS

Next, scroll down in the field options on the right and under Location select Map. Add “Location” as the Display Name, which will set the App Id as “location” which you can leave as is. Then same as before, click Create.

Adding and configuring a new map field in GraphCMS

Now we have a Content Model which we’ll use to create our locations!

Destination content Model in GraphCMS

Creating our locations

Finally, let’s create our locations. Navigate over to Content in the GraphCMS dashboard, make sure you’ve selected Destination under System (should be the only one), and select Create New.

Create new Destination Content in GraphCMS

Now we can start adding all of our locations! First, add the name of your location in the Name field, then you can use the Search box under Location to find that location on the map.

Adding a new Destination Content item in GraphCMS

Once you’re good, hit Save and publish. This will create your first location!

Follow those same steps and create as many locations as you want.

List of Destination Content items in GraphCMS

We’ll use these for our map and bucket list.

Step 3: Querying our GraphCMS location data with Gatsby and GraphQL

Now that we have our locations, let’s use them!

Adding a plugin to Gatsby to query our GraphQL data

First, we need to add a new plugin to our Gatsby project to query our GraphQL data. In your terminal make sure your development server isn’t running and run:

yarn add gatsby-source-graphql
# or
npm install gatsby-source-graphql

Next, open up your gatsby-config.js file in the root of your project and add the following to your plugins:

{
  resolve: 'gatsby-source-graphql',
  options: {
    typeName: 'GCMS',
    fieldName: 'gcms',
    url: '[API ENDPOINT]',
  }
}

This will be what sources our data from GraphCMS, but we need an endpoint.

Finding our API endpoint for GraphCMS

Open back up your browser and head over to your GraphCMS project. After selecting Settings in the left navigation, select API Access.

API Access in GraphCMS

Before we copy our API Endpoint, first we need to update our permissions so we can query our API. Under Public API Permissions, check the box next to Content from stage Published and click Save.

Configuring API permissions in GraphCMS

Next, copy the URL under Endpoints:

Copying API Endpoint in GraphCMS

And paste that in to your gatsby-config.js file that we modified above:

{
  resolve: 'gatsby-source-graphql',
  options: {
    typeName: 'GCMS',
    fieldName: 'gcms',
    url: 'https://[region-id].graphcms.com/v2/[project-id]/master',
  },
},

Note: your URL will have actual values inside of [region-id] and [project-id].

Save your gatsby-config.js file and start your development server backup (yarn develop) and we’re ready to go!

Querying our locations via GraphQL

Finally, let’s actually query our data so that we’ll be able to use it in our app.

We’re going to create a new React Hook that we’ll be able to use to grab our locations anywhere within our app.

Under src/hooks/index.js, add the following line to the existing list:

export { default as useDestinations } from './useDestinations';

This will allow us to more conveniently import our hook which we’ll create next.

Under src/hooks, create a new file useDestinations.js and paste in this code:

import { graphql, useStaticQuery } from 'gatsby';

export default function useDestinations() {
  const { gcms = {} } = useStaticQuery( graphql`
    query {
      gcms {
        destinations {
          id
          name
          location {
            latitude
            longitude
          }
        }
      }
    }
  ` );

  let { destinations } = gcms;

  return {
    destinations,
  };
}

Here, we’re:

Importing the graphql and useStaticQuery utilities from Gatsby
We’re creating a new function (or hook) that is exported by default
In that function, we’re using useStaticQuery to create a new GraphQL query which asks GraphCMS to return the data structure we defined.
That query returns a value which we destructure immediately to grab the gmcs object
We destructure destinations from gmcs and return it as part of a new object from our hook

With this, we can now use our hook anywhere in our app!

Head over to your src/pages/index.js file, first import our new hook:

import { useDestinations } from 'hooks';

And at the top of the IndexPage component, query our data:

const { destinations } = useDestinations();

This puts all of our locations into the destinations variable. We can test that this works by console logging it out:

console.log('destinations', destinations);

And once we open up our browser and look in our web developer tools console, we can see our location data!

Logging destinations data to the web console

Step 4: Creating a bucket list of destinations and adding them to the map

We’re going to start with creating a simple text list of our destinations. This will let us see all of our destinations in an easy to read format.

Creating a text list of our destinations

Inside of our IndexPage and above “Still Getting Started?”, let’s add the following code:

My Destinations
<ul>
  { destinations.map(destination => {
    const { id, name } = destination;
    return <li key={id}>{ name }li>
  })}
ul>

This code:

Adds a new header for our list
Creates a new unordered list
Loops through our destinations and creates a new list item for each destination that include’s the location’s name

Once we hit save and reload, we should see our list under our map!

New basic list of destinations in the app

The list looks a little odd though right? We probably want to format it a little better to fit into the page.

Open up src/assets/stylesheets/pages/_home.scss and inside of the .home-start class, add:

.home-start {

  ...

  ul {
    list-style: none;
    padding: 0;
    margin: 1.2em 0;
  }

Let’s also modify the h2 to space things out a little better:

.home-start {

  ...

  h2 {

    margin-top: 2em;

    &:first-child {
      margin-top: 0;
    }

  }

Once you hit save and reload, it should look a little better.

Destinations in the app with cleaned up styles

Feel free to make additional changes, but we’ll leave it there for now.

Adding our destinations to the map

Now we can finally add our destinations to the map!

Inside of our component, we already have a . This allows us to easily add a marker to the map given a position. We’ll take this concept and combine it with our text list to add our locations to the map.

Let’s update our code to match the following:

<Map {...mapSettings}>
  { destinations.map(destination => {
    const { id, name, location } = destination;
    const position = [location.latitude, location.longitude];
    return <Marker key={id} position={position} />
  })}
Map>

Here we:

Loop through our destinations to dynamically create a new list of components inside our
Inside each loop instance, we destructure our date from destination
We create a new position array with the latitude and longitude
Create a new Marker where we use our position to add it to the map

This gives us our markers on the map!

Markers for each destination in the mapping app

But we want to know what each of those locations are, so let’s also add a popup to each marker that will show the name.

First, we need to import Popup from react-leaflet:

import { Marker, Popup } from 'react-leaflet';

Then, let’s update our component to return:

return (
  <Marker key={id} position={position}>
    <Popup>{ name }Popup>
  Marker>
);

And once we save and open back up our map, you can now click on each marker and see our destinations name!

Popup for each destination marker in the mapping app

Before we’re done, center the map

Previously, our demo map centered on Washington, DC. Let’s update that to the center of the world since our map doesn’t focus on the United States.

Update the LOCATION variable to:

const LOCATION = {
  lat: 0,
  lng: 0,
};

And with that, we have our map!

Final mapping app with markers and popups for each destination

Follow along with the commit!

What else other features can we add to our app?

Add a way to check off each location

Inside GraphCMS, you can add a new field to your Destination content model that allows you to select whether you visited each location or not.

With this value, we can add it to our query and update our map with some kind of indicator like a checkmark to show that we’ve checked it off our bucket list!

Customize your map background styles

We’re using a public version of OpenStreetMap which is open source, but Mapbox offers some cool maps we can use to make it look a little more impressive.

If you want to get started changing your map styles, you can check out this other walkthrough of mine to learn how to use Mapbox.

Check out the blog post or watch the video!

Style the map markers with a custom image

You can check out my video walk through on how to change the markers to a custom image.

Take that a step further and use the feature above to dynamically show a different marker image when you’ve checked off a location.

Check out the video on Egghead.io!

Want to learn more about maps?

Check out some of my other tutorials and videos:

Mapping with React Leaflet (egghead.io)
Mapping Apps with React, Gatsby, & Leaflet (youtube.com)
How to create a Coronavirus (COVID-19) Dashboard & Map App with Gatsby and Leaflet (colbyfayock.com)
How to Create a Summer Road Trip Mapping App with Gatsby and Leaflet (colbyfayock.com)
How to build a mapping app in React the easy way with Leaflet (colbyfayock.com)
Anyone Can Map! Inspiration and an introduction to the world of mapping (colbyfayock.com)

What’s on your travel bucket list?

Let me know on Twitter!

headless cms - freeCodeCamp.org

How to Build a Headless WordPress Frontend with Astro SSR on Cloudflare Pages

Table of Contents

Why Headless WordPress?

The Architecture

Why Astro?

Infrastructure Setup

Step 1: Move DNS to Cloudflare

Step 2: Create the CMS Subdomain

WordPress Configuration

Tell WordPress it Lives on the Subdomain

Must-Use Plugin: Redirect and Preview

Clean Up Plugins

The Astro Frontend

astro.config.mjs

.env

src/lib/wordpress.js

src/middleware.js

src/layouts/Layout.astro

src/pages/blog/index.astro

src/pages/blog/[slug].astro

{author} · {new Date(post.date).toLocaleDateString()} {image && }

src/pages/sitemap.xml.ts

src/styles/global.css

CI/CD with Cloudflare Pages

Final Thoughts

Good to Know

How to Build a Portfolio Site with Sanity and Next.js

Table of Contents:

What is Sanity?

Step 1: Install Next.js

Step 2: Setup Sanity Studio

Install Sanity Studio

Step 3: Mount Sanity Studio into Next.js

Create the Studio Component

Step 4: Create Content Schemas

Profile Schema

Step 5: Query Data using GROQ

Step 6: Display Content in your Next.js App

Add Types to Data Content

Display Hero Section

Display About Page

Work Experience

Project Schema

Display Dynamic Routes

Add Loading States

Fix Studio Layout

Step 7: Deployment

Setup Sanity Webhooks for Studio Update

Create a Deploy Hook on Vercel

Trigger Hook Using Sanity GROQ-powered Webhooks

What Next?

Headless CMS Explained – What it is and When You Should Use it

What is a CMS?

What is a Headless CMS?

You don’t want to give up developer flexibility

You need a secure content solution

You want to future proof your tech stack

You need to create custom and personalized experiences

How I got into Headless CMSs

Why Do You Need a Headless CMS?

So How Does Headless CMS Help?

Why You Might Not Need a Headless CMS

You have a small team

You rely heavily on a simple live preview implementation

You only require simple publishing capabilities

Use Cases for a Headless CMS

Conclusion

Resources

How to Create a Travel Bucket List Map with Gatsby, React Leaflet, & Hygraph

What are we going to build?

Woah, a mapping app?

Step 1: Creating a new app with Gatsby Starter Leaflet

Creating a new Gatsby app with Gatsby Starter Leaflet

Cleaning our some demo code

Step 2: Creating and managing a list of travel locations with GraphCMS

Creating a GraphCMS account

Creating a new GraphCMS project

Creating a new Content Model Schema with GraphCMS

Creating our locations

{author} · {new Date(post.date).toLocaleDateString()}
{image && }