Leigh Halliday

> This is a contribution from [Leigh Halliday](https://www.leighhalliday.com/). Leigh recently created a memory project using GraphCMS and Next.js, covering Static Site Generation & API Routes using a Headless CMS.

In his video, see how to use `getStaticPaths` and `getStaticProps` alongside GraphCMS, additionally creating an API Route which will create new data inside of the CMS using [GraphQL Mutations](/docs/content-api/mutations).

<iframe width="100%" height="480" src="https://www.youtube-nocookie.com/embed/LJhWOUNkNwc" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

[Fork the repo](https://github.com/leighhalliday/graphcms-nextjs) and build your own example as you follow along!

## About the project

[GraphCMS](https://graphcms.com/) is headless CMS which exposes your data through a [GraphQL API](https://graphql.org/). Immediately I thought of it as read-only, querying data that had been entered through their interface, but that's not the case. You can also perform mutations on your data, allowing users to create content through your own application, while still controlling publishing and approval flows yourself.

In this example we will integrate GraphCMS with [Next.js](https://nextjs.org/), taking advantage of [Static Site Generation (SSG)](https://nextjs.org/docs/basic-features/data-fetching#getstaticprops-static-generation) for an incredibly performant experience, client-side data loading using [SWR](https://swr.vercel.app/) for rapidly changing data, and API routes which securely create content within GraphCMS through the exposed mutations.

Source code can be [found on GitHub](https://github.com/leighhalliday/graphcms-nextjs).

## Our Data Model

The example we will be working with today contains two models: Events and Memories. An Event represents a historical event (Obama becoming the first African American president, England winning the World Cup in 1966), where each of these events can have many Memories from people telling their story.

If I were to query the data through GraphQL it may look like:

```gql
query Event {
  event(where: { slug: "england-world-cup-1966" }) {
    id
    slug
    title
    date
    description
    image {
      url
    }
    memories(last: 10) {
      name
      story
    }
  }
}
```

## Dynamic Static Site Generation

Static Site Generation isn't typically paired with the word **dynamic**, but that is exactly what this is. We must first export a function called [getStaticPaths](https://nextjs.org/docs/basic-features/data-fetching#getstaticpaths-static-generation) which will allow us to tell Next.js which Events to pre-render during build-time.

The goal of this function is to query the Events from GraphCMS, returning them as the `paths` to be used later inside of `getStaticProps` which we'll cover later. I have used [graphql-request](https://github.com/prisma-labs/graphql-request) to perform the GraphQL query, just asking for each event's `slug`.

The URL (endpoint) is being stored inside of an ENV variable, which locally lives inside `.env.local` and is not committed to the repository. Wherever you end up deploying your application will provide you a place to enter these ENV variables into that environment.

```ts
// pages/events/[slug].tsx
const client = new GraphQLClient(process.env.NEXT_PUBLIC_GRAPHCMS_URL);

export const getStaticPaths: GetStaticPaths = async () => {
  const query = gql`
    query Events {
      events {
        slug
      }
    }
  `;
  const data = await client.request(query);

  return {
    paths: data.events.map((event) => ({ params: { slug: event.slug } })),
    fallback: "blocking",
  };
};
```

The `fallback: "blocking"` attribute signifies to Next.js that if a request is made to a path NOT returned from this function, it should be generated on the fly in a blocking manner and then cached for future requests. This would allow you to only pre-render your most popular pages, handling the remaining ones in an on-demand basis.

## Statically Generate Each Event

If `getStaticPaths` has returned 10 events to generate pages for, this function will be called once for each. [getStaticProps](https://nextjs.org/docs/basic-features/data-fetching#getstaticprops-static-generation) receives the `params` returned from `getStaticPaths`, and has the job of loading the data which will then be passed as `props` to the actual Page Component.

```tsx
// pages/events/[slug].tsx
import { serialize } from "next-mdx-remote/serialize";

export const getStaticProps: GetStaticProps = async ({ params }) => {
  const slug = params.slug as string;

  const query = gql`
    query Event($slug: String!) {
      event(where: { slug: $slug }) {
        id
        slug
        title
        date
        description
        image {
          url
        }
      }
    }
  `;
  const data: { event: IEvent | null } = await client.request(query, { slug });

  // Handle event slugs which don't exist in our CMS
  if (!data.event) {
    return {
      notFound: true,
    };
  }

  // Convert the Markdown into a compiled source used by MDX
  const source = await serialize(data.event.description);

  // Provide Props to the Page Component
  return {
    props: { event: { ...data.event, source } },
    revalidate: 60 * 60, // Cache response for 1 hour (60 seconds * 60 minutes)
  };
};
```

There are a few special things happening in this code. The first is that the GraphQL query we are sending to GraphCMS contains a variable: `await client.request(query, { slug });`. The `slug` is passed in so that we can find the matching Event.

The second special thing is that our `description` field doesn't contain just regular text, it is actually Markdown which we will compile into a source that can be used by [MDX](https://mdxjs.com/) to render it as HTML (or any custom component you pass to the MDX renderer). Normally MDX exists locally as a static file, but in this case we are using [next-mdx-remote](https://github.com/hashicorp/next-mdx-remote) that allows us to use MDX content with `getStaticProps` inside of Next.js. We'll see how to render this later.

Lastly, I have defined a TypeScript interface called `IEvent` which is used to let our code know what to expect back from GraphCMS and to be passed into our Page Component.

```ts
interface IEvent {
  id: string;
  slug: string;
  title: string;
  date: string;
  image: {
    url: string;
  };
  description: string;
  source: { compiledSource: string };
}
```

## Rendering The Event

It is now quite simple to render the event inside of our page level component. It receives the `event` data as a prop, and then we can embed it into the function's response. Here we are using the `MDXRemote` component to render the compiled Markdown.

```tsx
// pages/events/[slug].tsx
import { MDXRemote } from "next-mdx-remote";

export default function Event({ event }: { event: IEvent }) {
  return (
    <main>
      <h1>{event.title}</h1>
      <h2>{event.date}</h2>
      <img src={event.image.url} alt={event.title} />
      <div>
        <MDXRemote {...event.source} />
      </div>

      <Memories eventId={event.id} />
      <NewMemory eventId={event.id} />
    </main>
  );
}
```

We haven't touched on `Memories` and `NewMemory` yet, but those are coming next!

## Client Side Querying Data

We'll be using [SWR](https://swr.vercel.app/) to load the event's memories on the client after the initial page load. The `useSWR` hook typically receives two parameters: The `key`, which in our case is the `eventId`, and then a fetcher function which will load the data.

Thankfully, `graphql-requst` works both client-side and server-side, so we can reuse the same `client` variable from before to perform the GraphQL Query.

```tsx
// pages/events/[slug].tsx
import useSWR from "swr";

const fetchMemories = async (id: string) => {
  const query = gql`
    query Memories($id: ID!) {
      memories(where: { event: { id: $id } }) {
        id
        name
        story
      }
    }
  `;
  return client.request(query, { id });
};
```

Once we have the `data` back from `useSWR`, after checking to make sure data exists (it won't when there is either an error or is still loading the memories), we can render them out as blockquotes.

```tsx
function Memories({ eventId }: { eventId: string }) {
  const { data } = useSWR(eventId, fetchMemories);

  if (!data) return null;

  return (
    <div>
      <h2>Memories</h2>
      {data.memories.map((memory) => (
        <blockquote key={memory.id}>
          {memory.story} - {memory.name}
        </blockquote>
      ))}
    </div>
  );
}
```

## Submit New Memory Form

We've loaded memories, but how do new memories actually get created? It all starts by rendering a form that will collect a `name` and `story`. When the user submits the form we will send this data to a serverless function defined at `/api/memories/add` within our Next.js app.

The reason we are doing it this way (rather than calling the mutation directly) is that mutating data inside of GraphCMS requires additional permissions, and a special API Token which we don't want to expose publicly to our users. The flow of the data looks like this:

1. User enters data into form.
2. Form data is submitted to `/api/memories/add`.
3. This serverless function receives the form data and prepares variables for the mutation.
4. The form data is then sent to GraphCMS via a GraphQL mutation.

```tsx
function NewMemory({ eventId }) {
  const [name, setName] = useState("");
  const [story, setStory] = useState("");

  // Send the form data to our API route /api/memories/add
  const onSubmit = async (event) => {
    event.preventDefault();

    await fetch(`/api/memories/add`, {
      method: "POST",
      body: JSON.stringify({ name, story, eventId }),
      headers: {
        "Content-Type": "application/json",
      },
    });

    setName("");
    setStory("");
  };

  return (
    <form onSubmit={onSubmit}>
      <input
        type="text"
        required
        name="name"
        placeholder="Your name"
        value={name}
        onChange={(event) => setName(event.target.value)}
      />
      <textarea
        name="story"
        value={story}
        placeholder="Your story"
        onChange={(event) => setStory(event.target.value)}
      />
      <button type="submit">Add</button>
    </form>
  );
}
```

## API Routes and Mutations

Within our serverless function, we can receive the data sent from the form and use this data as the variables within the mutation that will be called to create a new memory within GraphCMS.

Something important to keep in mind is that special permissions are required to perform a mutation. You will have to create a [Permanent Auth Token](https://graphcms.com/docs/authorization#permanent-auth-tokens) within your GraphCMS settings and ensure that it has `read`, `update`, and `read versions` permission on the `Event` model, and `read`, `create`, and `read versions` on the `Memory` model.

```ts
export default async (req: NextApiRequest, res: NextApiResponse) => {
  const variables: { eventId: string; name: string; story: string } = req.body;

  const mutation = gql`
    mutation CreateMemory($eventId: ID!, $name: String!, $story: String!) {
      createMemory(
        data: {
          name: $name
          story: $story
          event: { connect: { id: $eventId } }
        }
      ) {
        id
      }
    }
  `;

  const client = new GraphQLClient(process.env.NEXT_PUBLIC_GRAPHCMS_URL, {
    headers: {
      Authorization: `Bearer ${process.env.GRAPHCMS_MUTATION_TOKEN}`,
    },
  });
  await client.request(mutation, variables);

  res.status(200).json({ success: true });
};
```

After the Memory is created in GraphCMS, it will not be immediately available for users to see on your website. This is because it has been created in a `draft` state, and won't be seen until it has been `published` by an admin.

## Conclusion

By combining powerful technologies such as GraphCMS, GraphQL, Markdown and Next.js, we can create an amazing user experience quickly and performantly. This example showed how to generate Event pages using dynamic Static Site Generation in Next.js, loading additional data client-side with SWR, and finally how to use API routes in Next.js to create data in GraphCMS via a GraphQL Mutation.

In this example we will integrate GraphCMS with Next.js, taking advantage of SSG for an incredibly performant experience, client-side data loading using SWR.

Next.js with GraphCMS: Static Site Generation & API Routes

Emily Nielsen

Content Marketing Manager

It can be quick and easy to create a simple static Jamstack site; however, things get more difficult when you want to create even a slightly more complicated interactive experience, such as a form or create a search function. There are a wide range of services and approaches, from a custom implementation to specialized services which can be quickly connected to your existing architecture.

I am taking a look at some of the most common ways to add dynamic functionality to a tech stack in order to further enhance user experience. While strictly static sites have a wide range of benefits, from performance to security to an SEO boost, at times, they do not meet the needs of the use case. Modern use cases often require a blend of static elements with dynamic functionality. These blended sites are most often as static as possible with dynamic elements which are use case specific.
  

## User Experience (UX) and the Jamstack

  

In this guide, we will take a look at how to enhance user experience by adding elements of dynamic functionality to static sites. I’ve broken this down by the various types of functionality that is commonly needed to build a better user experience. The suggestions range from simply connecting a service to a broader toolset suggestion that could point you in the right direction. The creativity and high volume of Jamstack creators help teams have a wide range of options when it comes to solution building; however, this can also be daunting when trying to meet aggressive project timelines. These tools enable teams to provide more dynamic functionality while still retaining the core statically generated elements. At the end of the day, your technical abilities will be highly dependent on the chosen stack and the use case. Our goal is for this guide to be a starting point to kickstart the evaluation process.

In this guide, we have outlined 28 tools that can help add dynamic experiences to your Jamstack sites.  
  

## Forms and Processing

Users expect to be able to get in contact with teams, submit feature requests, or request whitepapers on any marketing site, regardless if it is a static site. Forms and the processing of forms is a basic functionality that is essential to providing a modern web experience. While it is possible to hard code forms and processing for your Jamstack site, it can be time consuming and there are many existing services which offer this functionality. The Jamstack ecosystem has come up with a wide range of answers to form processing on a static site with microservices and integrations. 

Here are 4 tools that can help teams create forms within Jamstack sites. 


### Formium

![Formium](https://media.graphcms.com/8MN6mzJNTZf6RPUPRcHz)

[Formium](https://formium.io/) is an API-first form builder service that enables teams to build forms via a drag and drop editor. It allows teams to natively render forms and surveys on their website or application. Formium enables teams to quickly add the form, processing, and analytics functionality without having to start from scratch.

### Formkeep

![Formkeep](https://media.graphcms.com/CfpVsQkQRi6H491fRFe9)

[Formkeep](https://formkeep.com/) allows teams to build forms via their visual editor, templates, or programmatically. They emphasize their native integrations to many helpful services, such as Slack or Google Sheets, for notifications and clean data transfers.

### Netlify Forms

![Netlify Forms](https://media.graphcms.com/owrmYGwLREeShqRokTuT)

[Netlify Forms](https://www.netlify.com/products/forms/) is just one of the many dynamic functionalities that lives under the Netlify brand umbrella. In addition to forms, Netlify also enables split testing and authentication, just to name a few. Staying within the Netlify universe can be an excellent option for those hosting their site on Netlify.

### GraphCMS for forms

![Nextjs Forms with GraphQL and GraphCMS](https://media.graphcms.com/4Ndqi9d4Rnmo0g5PxxoA)

GraphCMS can also be used to programmatically create forms. When used in tandem with GraphQL and Next.js, GraphCMS can create dynamic forms and capture the responses as well. We have a [comprehensive guide on how to set up forms using GraphCMS](/blog/forms-and-submissions-with-nextjs-and-graphql) to help teams get started.   
  

## Shopping Carts

Shopping carts are one of the critical elements of an ecommerce user experience. They are also notoriously time consuming to build a high quality experience from scratch. There are several services that make it easy for teams to provide this high quality experience that can make or break the end user experience. These services are not exclusive to the Jamstack space; but instead, integrate easily into Jamstack projects.

Here are 4 tools that can help teams add shopping carts to their Jamstack project. 

### Snipcart

![Snipcart](https://media.graphcms.com/X3wQZWbsQ5qEm48lUzd2)

[Snipcart](https://snipcart.com/) allows teams to seamlessly integrate a flexible shopping cart into their chosen tech stack. Snipcart is fully technology agnostic and enables teams to work with best-of-breed technologies that best match their use case.

### Shopify Buy Button

![Shopify Buy Button](https://media.graphcms.com/4DKGg0pRw64nTf4Fi1gD)

[The Shopify Buy Button](https://www.shopify.com/buy-button) allows teams to embed products or services to purchase directly into an existing site. The Buy Button is great for simple purchases and allows users to fully customize the design to match the user’s own branding.

### CartQL

![CartQL](https://media.graphcms.com/UvHGND1SW6d4mIAtNRRD)

[CartQL](https://cartql.com/) is a GraphQL shopping cart and checkout API that is a flexible tool to help create a fluid checkout experience with your existing stack. Teams are able to bring their existing inventory and store any type of data for their cart and cart items. 

### Foxy

![Foxy](https://media.graphcms.com/SMOV9qJTRsOL6uXSIbbZ)

[Foxy](https://www.foxy.io/) is a hosted shopping cart and payment platform. It’s simplicity makes it easy to customize a checkout experience that matches the needs of the brand. Foxy allows for teams to choose from over 100 different payment providers from Braintree to Square.
  

## Authentication


Authentication is another complex process that is critical for many use cases across the Jamstack. In verifying the identity of the users, teams are able to work with more sensitive information and ensure that only those with proper clearance have access to content. Authentication with the Jamstack can be slightly counterintuitive as there are no servers to run code server-side; however, there are services which can help bridge the gap and provide an authentication layer while still using the Jamstack.

Here are 2 tools that can be used to add an authentication layer to their Jamstack project. 

### Auth0

![Auth0](https://media.graphcms.com/4dVM1sTfSMi09Pqlo4Gl)

[Auth0](https://auth0.com/) is an industry heavyweight when it comes to implementing an authentication layer on services and websites. Auth0 makes it easy for teams to authenticate users while still providing a high quality user experience and the necessary privacy.

### OneLogin 

![OneLogin](https://media.graphcms.com/NghAQM3VT8ytRYK56xOO)

[OneLogin](https://www.onelogin.com/) offers a broad suite of privacy and security services for websites and applications. They provide authentication services including Single Sign On (SSO) and Multi-factor authentication (MFA).
  

## Payments


Payment systems enable secure transactions quickly and efficiently. They are a crucial component to the ecommerce flow and can make or break a customer’s decision to “trust” the website. There are many approaches to simply add a payment workflow to your ecommerce site, we are highlighting some of the true API driven approaches.

Here are 3 tools that can add secure payment systems to your Jamstack site. 

### Stripe

![Stripe](https://media.graphcms.com/9slgA2rkRVmhlFjTZsVt)

[Stripe](https://stripe.com/) is one payment option that needs no introduction and it’s various products serve a wide range of needs for the checkout and payment workflows. The sophisticated tooling of Stripe enables teams to build modern payment solutions with a focus on high quality user experience. Stripe has a wide range of approaches that can suit your specific needs from [Stripe.js](https://stripe.com/docs/js) to [Stripe Checkout](https://stripe.com/docs/payments/checkout) and [Stripe Payment Links.](https://stripe.com/en-de/payments/payment-links)

### Adyen

![Adyan](https://media.graphcms.com/M7pWXhvVTS6VuYVs1BO2)

[Adyen](https://www.adyen.com/) is an API driven payment solution that handles payments from B2B, B2C, and subscriptions. In addition to handling digital payments, it also accepts in person payments using payment terminals to enable flexibility. Their powerful documentation and easy get started guide create a high quality user experience for this flexible platform.

### Braintree 

![Braintree](https://media.graphcms.com/EbZq91AJSHekyEvHYD6Q)

[Braintree](https://www.braintreepayments.com/) is a subsidiary of Paypal which focuses on bringing seamless digital payments to modern commerce experiences. They boast global reach and streamlining operations to ensure that teams receive the maximum return on investment. Braintree has a GraphQL API for devs to seamlessly integrate Braintree into their system.

  

## Search

There is very little that needs to be said about search functionality. When well implemented, it greatly improves user experience and breathes new life into content which may be tucked away in a rarely visited part of the site. When poorly implemented, they can lead to frustration and degrade the user experience. We’ve chosen two of the reliable services to choose when looking to implement search on your site.

Here are 3 tools that can enable search functionality on your Jamstack site.  

### Algolia

![Algolia](https://media.graphcms.com/FRzWzW8OQXO3VU4nrcpi)

[Algolia](https://www.algolia.com/) is one of the popular API-driven search solutions that works seamlessly with the Jamstack. With offerings from classic site and mobile search to more specialized options like Voice and Geo Search, Algolia is a flexible tool that is beloved by devs all around the world.

### Elastic

![Elastic](https://media.graphcms.com/sXP0YPdSyW0kf5e8GjN3)

[ElasticSearch](https://www.elastic.co/) is another popular option for an API-driven search solution that can easily be integrated on your Jamstack site or application. ElasticSearch is highly flexible and is designed to scale with the team's needs, making it a great option for growing teams.

### MeiliSearch

![MeiliSearch](https://media.graphcms.com/cigjoshaQy5bZVH6Wpsx)

[MeiliSearch](https://www.meilisearch.com/) is an open-sourced, API-driven search solution that makes it easy to add a scalable, typo tolerant search to your Jamstack project. MeiliSearch is highly customizable and promises high quality user experiences, making it a popular choice for teams wanting to get up and running quickly. 


## Push notifications


Push notifications can enable teams to bring the most important information to the forefront. They serve many purposes from sharing message previews, to updating delivery times, or even just status changes. Each implementation has individual notification needs and uses which must be customized.

Here are six tools that enable push notifications for Jamstack projects.   

### Pusher

![Pusher](https://media.graphcms.com/LA4aqpjOTFmg74Guy0h0)

[Pusher](https://pusher.com/) is an API driven service that enables teams to build complex features quickly. Pusher enables developers to quickly set up custom push notifications quickly while still ensuring easy scalability, security, and analytics for your implementation.

  

### OneSignal

![OneSignal](https://media.graphcms.com/OHQmW3UQkSeLKmaGPOJc)

[OneSignal](https://onesignal.com/) offers a broad range of push notification implementations from mobile, to in app to website options. OneSignal is a robust tool that promises high user engagement and re-engagement when implemented.


## Lambda Functions


Lambda Functions are one of the most straightforward ways to connect a variety of dynamic services or functionalities to a static site. There are a variety of ways to implement them from more labor intensive DIY approaches to connecting services that handle most of the logic behind the curtain.  

### Netlify Functions 

![Netlify Functions](https://media.graphcms.com/pG5cYe7gRhGf8mePVVx9)

[Netlify functions](https://www.netlify.com/products/functions/) are an excellent choice for teams who have already implemented Netlify in other capacities and wish to stay within the same ecosystem for as much of their tooling as possible. Netlify functions are easy to implement and make it easy to create workflows for deployment.

### Vercel

![Vercel](https://media.graphcms.com/RHBCsWGRRqhqIMx5wu06)

[Vercel](https://vercel.com/docs/serverless-functions/introduction) also enables teams to implement serverless functions to boost functionality possible with the Jamstack. Serverless functions can be used to handle user authentication, database queries, and other customized commands. Their documentation makes it easy to implement serverless functions in your own projects.

### AWS Lambda

![AWS Lambda](https://media.graphcms.com/diNRxEz5QnWcNAFowpbc)

[AWS Lambda](https://aws.amazon.com/lambda/) is a serverless service that enables teams to run code for nearly any type of application or backend service. They have a generous free tier with 1 million free requests per month and offers simple scalability. AWS Lambda is highly flexible with a broad range of implementations that are possible.

### Begin.com 

![begin](https://media.graphcms.com/yvp2OCwoRYaqyZA0JyzS)

[Begin](https://begin.com/) aims to make serverless implementations quick and easy for teams to set up serverless functions. Begin has open source tooling at its core and enables teams to reap the benefits of serverless without the long implementation setup or troubleshooting know-how.


## Commerce

 Commerce is a very common use case for Jamstack sites. Finding the balance of how much dynamism is needed is not always clear and the headless commerce space is filled with players that offer a wide range of solutions.

Here are 2 headless commerce platforms that work well with the Jamstack. 
  
### Commerce Layer

![Commerce Layer](https://media.graphcms.com/DKQk4q7XQnG0kq1T1Nlg)

[commercelayer](https://commercelayer.io/) is an API-driven headless commerce solution that enables teams to create modern customer experiences while still having a high emphasis on performant infrastructure. The decoupled approach to commerce enables teams to separate content and ecommerce functionalities making it easy to update and modify content.

  

### commercetools

![commercetools](https://media.graphcms.com/rLsZQT8ScuzEPnGfeOA3)

[commercetools](https://commercetools.com/) is a headless commerce platform built on the MACH principles. It enables teams to manage all of their necessary commerce functionalities while easily connecting with a variety of desired frontend layers. Commercetools offers a broad range of functionalities that enables teams to build a custom commerce experience.

  
  

## Static site generators  

Static site generators are an essential element of the Jamstack. We’ve gone in depth into [static site generators for various use cases](/blog/top-12-ssgs-2021) and preferences in a blog post earlier this year. We took a look at some of our favorite SSGs which includes all of the usual subjects but also some new, up and coming players.

  

## Static hosting solutions

Static hosting solutions bring the final Jamstack site to fruition. There are a variety of solutions depending on the use case and specific needs of the project. Some players offer more out-of-the-box while others enable devs to take a largely custom approach.

Here are 4 static hosting solutions for your Jamstack site. 
  

### Vercel

![Vercel](https://media.graphcms.com/EAIGNpEFRFWtukWIGp4y)

[Vercel](https://vercel.com/) is a beloved option for static hosting by developers around the world. Created by the folks behind [Next.js](https://nextjs.org/), Vercel makes it easy to deploy any frontend application using high powered developer tooling which enables scalability and collaboration. Teams of all sizes have embraced Vercel.

  

### Netlify

![Netlify](https://media.graphcms.com/FHfexHNMQ2ercgVHAArw)  

[Netlify](https://www.netlify.com/) was the company which coined the term Jamstack in 2016 and helped popularize the approach. The static hosting solution has grown into an entire ecosystem of functionality to enable static sites. Users of Netlify range from devs working on hobby projects to enterprises that are looking to modernize and everything in between.

  

### GitHub Pages

![GitHub Pages](https://media.graphcms.com/Mth7EHbSRFmUHuWP2AM9)

[Github Pages](https://pages.github.com/) make it easy to host content directly from your Github repository. The simple workflows keep teams efficient and avoid overly complicated setups for simple content needs. Github Pages streamlined approach does not have a lot of bells and whistles but it makes creating static pages quick and simple.

  

### Amazon S3

![Amazon S3](https://media.graphcms.com/GlMkO6I7QdqiZYUyR5OA)
  
[Amazon S3](https://aws.amazon.com/s3/) enables teams to build projects with the future in mind when it comes to easy scalability, data availability, and security. Teams have access to the wide range of tooling within the AWS ecosystem and have fine-grained control of data and how it is organized.


In this guide, we break down 28 tools that will help you add dyanmic user experiences to a static, Jamstack project. 

Tools to expand User Experience with the Jamstack

Narcisa Lupu

Marketing Executive

*This post was written by one of our implementation partners, [Digital Detox](https://digital-detox.co.uk/), who specializes in building thoughtful digital products with user experience at their core. As a disclaimer, the guidelines mentioned in this post are intended to serve as considerations, and not meant to highlight a recommended practice or process.*


In the last two years, companies have had to adapt to drastic changes in working culture and new technologies. Many organizations have switched office and physical meetings for virtual calls, digitized their offline practices, and undergone rapid digital transformation. It's important to remember each digital interaction comes at a cost. For every piece of content, code, and digital design that’s created, there’s an impact on our collective digital carbon footprint.


Measuring the [sustainability of code and programming]([https://hbr.org/2020/09/how-green-is-your-software](https://hbr.org/2020/09/how-green-is-your-software)) is something more teams are beginning to be conscious about and factor in when making architectural decisions.


Your development team can be instrumental in helping you push forward with your digital sustainability goals. Developers are knowledgeable about the inner workings of your digital platforms and technical infrastructure and would be best positioned to help you make better decisions on the sustainability of your digital operations.

  
Make time to listen to their ideas about how to [detox your development processes](https://blog.digital-detox.co.uk/a-digital-detox-for-your-development-team/), existing systems, and tech stack. This is useful for getting new ideas and fresh perspectives, but also valuable for gaining buy-in from the team as you embark on your journey to becoming more energy efficient.

  
## What is digital pollution?

Everything we do online requires energy; from plugging in devices to distributing content globally via CDNs. In turn, this energy creates carbon, which contributes to the overall footprint of a company - where inefficient digital practices not only harm the environment but tend to stack up costs. The more excess carbon in the atmosphere, the more we witness changes in weather patterns, and depletion of natural resources.


The problem is that most people aren’t aware of how their traditional design and development practices affect the planet, so they code, connect and digitize as they’ve always done. As we learn more about [digital carbon footprints](https://digital-detox.co.uk/work/greenreport/), we’re realising that there’s a lot we can do to combat the environmental impact of our online activities. This has given rise to a new consciousness around digital sustainability.

## What is digital sustainability?

Digital sustainability is an ethical approach to design and development that aims to reduce our individual and collective digital footprint.


It is a holistic view of how we, as those who work in the software development sphere, can actively try to minimize the amount of carbon we create when we’re coding, designing, and consuming online content.


The good news is that as a developer there are some simple actions you can take to become more energy efficient.


### Get buy-in from the leadership team  

Adopting a sustainable approach to development requires buy-in at all levels. Creating a plan that outlines how you want to make your development more sustainable is a crucial first step. It may be helpful to employ a [digital agency](https://digital-detox.co.uk) with experience in building a digital sustainability strategy.


Some key elements that can help teams create a more sustainable approach to development, particularly for SaaS software development, require management to make the decisions and allocate the resources. Considerations such as adopting greener server architectures and data centers, building efficient code, and holding teams accountable for the new, greener standards.

  
It’s important to set the intention and deliver clear development briefs to the team that incorporates digital sustainability as a standard. This means everyone needs to buy into the concept and understand the importance of detoxing your development approach.


The development team is just one piece of the puzzle; you’ll also need to find ways to be more energy efficient in your design, product management, business analysis, commercial function, and customer strategy.

  
Detoxing isn’t something that happens by chance; it takes planning, commitment, and a company-wide cultural change. It’s hard work but is clearly worth the extra investment
  

### Make a plan for greater digital sustainability


Teams can start this process by creating a set of goals for the quarter on how to make the team and processes more sustainable. These can then be evaluated at the end of the quarter and progress can be shared with the team.


To create greener processes in the long term, teams must make a plan to understand how to transition and create meaningful change. This doesn’t mean that the team cannot also benefit from some quick wins. Here are a few ideas to get you started:

-   Use technology that bills by execution time and challenge the developers to build efficient code
    
-   Consider whether your team has the capacity to [adopt serverless computing](https://hbr.org/2020/09/how-green-is-your-software) could be adopted for your use case to give teams more control
    
-   Streamline outdated processes within the team to ensure time spent online is productive
    
-   Review your existing or next sprint and identify at least one change to make it more energy efficient
    
-   Before you build anything new, check whether you can reuse any existing components from previous work, instead of starting from scratch, if the answer is no then make sure to delete the outdated solutions
    
-   Use prototyping to prove concepts before development to save on unnecessary iterations and wasted development time
    
-   Adopt an agile methodology this way you won’t waste time and energy trying to salvage a concept or approach that won’t work
    
-   Encourage developers and designers to work closely to check the technical feasibility of designs upfront, to avoid unnecessary work further down the line
    
-   Set an example of holding yourself accountable for your own digital detox (set goals for yourself to take a greener approach to software development, repair existing technologies instead of buying new, switch to a greener broadband provider, adopt green software practices in side projects)


While these changes may seem small, they represent a change in mindset to the approach of energy consumption when it comes to software development. These small changes push teams to consider how to optimize for sustainability to the forefront.

### Continually evaluate your progress and successes

Detoxing your development processes isn’t a one-off exercise. The good news is that simply streamlining clunky, labor-intensive offline practices, is an excellent first step. 


Building in digital sustainability as part of the team’s KPIs means you’ll be able to factor in energy efficiency at every stage of your development process. From planning to coding, your developers can become more conscious of their digital carbon footprint. Monitor the progress and celebrate the successes in order to keep teams motivated.

 
The principles of digital detox for your development team are simple:

  

- More efficiency

- Less waste

- Conscious coding

- Sustainable KPIs

- Ongoing change

- Customer-focused

- Shared accountability

  

Whether your objective for becoming more energy-efficient, digitally, is to improve customer satisfaction, achieve your CSR goals, or simply do something good for the environment, the end result helps shift the industry away from wasteful practices towards a more sustainable approach to development with greener resource consumption.

Our friends at Digital Detox discuss how development teams can be a key component of companies' reaching their sustainability goals.

How your development team can help reach your digital sustainability goals

Migrating to a new tech stack means change for the entire team, from development to content. While some team members may be excited about the prospect of [moving to a new system that offers more flexibility](/blog/moving-from-page-builders-to-structured-content), others may be hesitant to make the move, wanting to maintain their current workflows and toolset. This guide will break down the benefits of moving to the [Jamstack](/academy/what-is-the-jamstack) in a way that will make clear why the Jamstack is an excellent choice for many use cases, even to the more hesitant team members. 

## Benefits of Jamstack 

There are many benefits to Jamstack, but we decided to keep it simple for this guide and highlight just three of the key benefits of the stack. I tried to look at the benefits from three perspectives, the end-user, the development team, and the content team. Each group is considered in this breakdown as they all serve as a valuable piece of the decision-making process. 

### Faster performance 

The faster performance promised by Jamstack implementations is due to several things. First, the data is globally distributed on CDNs which serve the webpage to the client. Because the clients are able to receive the data from the CDN server which is closest to them, page load times are drastically reduced.

The second consideration when it comes to performance is that the webpages are pre-rendered and cached on the CDN servers in the regions closest to where they were called by the user. As long as there are no changes to the webpage, the CDN will serve the cached, pre-rendered site. With the Jamstack, teams can store the data close to the users, and pre-rendering the webpages create faster page load times leading to a better user experience. 

### Modern tooling

Modern toolsets offer more flexibility and opportunity to create a customized stack without having to build everything in-house. The Jamstack community is a diverse, far-reaching community that has built many projects in a public-facing way. Teams are able to evaluate their potential tool stacks based on community feedback but still have the freedom to build a performant stack based on up-and-coming technologies.

With the Jamstack, teams are able to build a static site with a headless CMS, modern frontend frameworks, CDNs, analytics tools, or [static site generators](/blog/top-12-ssgs-2021). We dive into what an [architecture for a modern website could look like in a recent post](/blog/architectures-for-modern-websites). Using the Jamstack, teams can reach a globally distributed audience with the content to match that audience’s needs and enabling them to quickly [deploy localized content](/blog/handling-localization-in-graphcms).

### Better user experience 

The Jamstack enables a better user experience from the developer, to the content editor, to the user. Developers benefit from the Javascript-focused, modular tooling that enables them to specialize and work quickly with tools in their skillset. For devs that want to take time learning new tooling and approaches, the Jamstack lets them flex their creative muscles. These elements can be essential for hiring and retaining highly skilled web developers. 

Content teams benefit from the Jamstack as well. While it may not be the page builder they are used to, content teams benefit from the greater flexibility enabled by a headless CMS, a key element of the Jamstack architecture. Content teams can integrate additional tooling into the backend to give them the insights they need to create successful content and reach their audience. 

Users benefit from the faster page speeds and the reliable user experience. Because Jamstack sites are more secure than their decoupled counterparts, users have a highly reliable user experience. 

## Understand your use case

With any tech stack, it is important to have a good understanding of the end product and the needs of the team along the way. In development, there is a near-constant stream of new products coming to the market with various levels of hype surrounding them.

While some of these tools and approaches may be validated in the long run, it is important to define which context is the ideal use case. Ideal use cases help ensure that teams are choosing the best toolset for what they actually need, rather than just riding the wave of what is popular. Jamstack is an excellent approach for teams looking to build static sites, quickly but it can become clunky when teams try to build a site with a high level of dynamic content. There is a certain level of dynamic content that may be expected with almost any site; however, sites that need a high level of dynamic content to provide a high-quality user experience may want to consider another approach.

There are many workarounds or integrations for creating dynamic content within the Jamstack, but you may find that other stacks provide more native support for dynamic content.


In this post, we break down the benefits of Jamstack to help convince teams that it is the right choice for their use case. 

Is Jamstack the right approach for your use case?

Darshan Gajara

Senior Product Designer

As the Lead Product Designer at GraphCMS, I’d like to share our design process at GraphCMS.


This will be a multi-part series, so let me start by giving you a high-level overview of our team and project setup. We're a fairly small team, so we only need one team account in [Figma](https://figma.com). Under our team, we've got separate projects for:


- ⚡️ Feature
- 🎨 Baukasten (our Design System)
- 🔥 Marketing

![Handling Design at GraphCMS - Projects](https://media.graphcms.com/Iwwcdt1S1qRPDscuHgao)

We also maintain other non-regular projects like Feedback, Figma Crash Course, Reference Applications, etc.

## What goes into each project

### ⚡️ Feature

![Handling Design at GraphCMS - Feature](https://media.graphcms.com/04QqkNoSkC6XbQf2iOrb)

This project is dedicated to new [features](/features) and improvement work on the product. At present, our web app is our only product, so it's relatively easier to keep everything feature-related under one project.


### 🎨 Baukasten

![Handling Design at GraphCMS - Baukasten](https://media.graphcms.com/4mt61LocT2a1Jgt6MlOF)

[Baukasten](https://de.wikipedia.org/wiki/Baukasten) is a German word for construction kit. Think of it as legos – the building blocks of our product. This project holds our style guides and components.

Note: We’ll do a separate post on our design system later. Keep an eye on this space.


### 🔥 Marketing

![Handling Design at GraphCMS - Marketing](https://media.graphcms.com/qH2RpkxYQA2Iw7ReSJuU)

The project is dedicated to our marketing website and community work, which includes [docs](/docs), [blog posts](/blog), videos, [GitHub repos](https://github.com/graphcms), conferences, social media, etc. The community is central to our product and we try to support our developer advocates with graphics and assets as much as we can.

Apart from these 3 main projects, we create new projects for non-regular work. For example, I did a Figma training session for our team when we moved to Figma as our design tool. So we created a new project to use as a playground.

![Handling Design at GraphCMS - Figma Session](https://media.graphcms.com/lYk4Xbm1QIvaKtsTTCY1)

To understand how this process works, let’s take a deeper dive into the Feature project setup.

## ⚡️ Feature

![Handling Design at GraphCMS - File](https://media.graphcms.com/AWEHx9EgQawK4QhVHXVo)

Let's peek inside a feature file. Every feature file has these separate pages: 

- Cover
- 🔍 Research
- 📝 Scratchpad
- ✅ UI
- ▶️ Prototype
- 👌 QA

Here’s what goes inside every page:

### Cover

![Handling Design at GraphCMS - Cover](https://media.graphcms.com/tG9uaj7JSXKpeYVhws72)


We dedicate the first page of the file to the cover. A cover can also be set by using a frame as a custom thumbnail but it doesn't scale well for different screen sizes. So it's better to set it up on a separate page with the same background. That way you can let Figma automatically pick your first page as the cover of the file.

A file cover makes it easier to identify the relevant file in a sea of many files. We also use it to indicate the collaborators, timeline, and status of the feature. The cover template we use is based on [Ramy Majouji](https://twitter.com/majouji)'s freebie.


### 🔍 Research

![Handling Design at GraphCMS - Research](https://media.graphcms.com/H2aCiyYOTaqRHFDzrkSM)

The page dedicated to all the research done around that feature. This includes things like specs, notes, competitor references, design mood boards, etc. Basically, everything that's needed to design the feature.


### 📝 Scratchpad

![Handling Design at GraphCMS - Scratchpad](https://media.graphcms.com/furgLrPeQAO2mfGLdq3g)

This is the messy middle, this is where the fun lies. It's an open canvas to explore ideas, try out different patterns, get feedback, and iterate. This is also the page where the most collaboration happens. And it's often flooded with comments from the team.

Here's an example from one of the recent feature files. Yes, it can get pretty crazy at times.

![Handling Design at GraphCMS - Comments](https://media.graphcms.com/Q8A41QTPQ1KeFghdFpZm)


### ✅ UI

![Handling Design at GraphCMS - UI](https://media.graphcms.com/Ld1yFnpPSPWNYF3irD1o)

This is the most organized page in the file. It's where the final designs/user flows stay. It's also the source of truth for our engineers working on the given feature. They would develop the feature by inspecting the designs from here.


Frames on the ✅ UI page are organized based on user flows. You would notice that we use the default style to title them. That's to benefit from Figma's automatic scaling of frame titles on zoom in & out. We also use this page to leave relevant notes for our engineer friends.

<iframe width="100%" height="480" src="https://www.youtube-nocookie.com/embed/tMKMkTJpm5M" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> 

### ▶️ Prototype

![Handling Design at GraphCMS - Prototype](https://media.graphcms.com/xBFoxPDpTne5mkdHZaSA)

This page is optional. We only make use of this page when we create prototypes for the given feature. Prototypes are usually only needed to communicate a complex design or to present the concept to other teams or customers.


### 👌 QA

![Handling Design at GraphCMS - QA](https://media.graphcms.com/fKEpqpN6QX2UzZlIT39U)

When the feature gets developed, we're asked to review the PR on GitHub by our engineers. We review the feature in our preview environment, take screenshots of where there's a mismatch in design, paste it on this page and leave comments for our engineering team.

We’re aware that our QA process isn't ideal and we're constantly looking to improve it. So if you've got any recommendations or suggestions here, please feel free to reach out.

Also, we've created a template file with all these pages, base frames and pinned it to the top of the ⚡️ Feature project to make the process of starting a new feature work fast and easy.

![Handling Design at GraphCMS - Template](https://media.graphcms.com/FC9va2VTNqEaMQMohfFL)


Keeping our files and projects organized in Figma has been massively beneficial for us and has made the process of collaboration between teams so much more efficient and fun. I hope you found this useful and can take away some principles to apply to your own process.


To kick off this multi-part series, let's look into the high-level overview of our team and project setup.

How We Organize Our Files and Projects in Figma

Michael Lukaszczyk

Co-Founder & CEO

Daniel Winter

Co-Founder & CTO

As we enter the final days of this remarkable year, we wanted to share some highlights from 2020, before we all take a few days to relax, recharge, and gain some holiday weight before starting afresh in January.

## Looking Back

![Legacy GraphCMS UI](https://media.graphcms.com/dlFbOTraQx621Px0gzHB)

We started the year strong with our beloved Legacy GraphCMS - a product that served us well over the years but had started to show its limitations. There were ambitious ideas that couldn’t be realized on that infrastructure, and a host of features like Union Types, Content Stages, Sortable Relations, and Integrations that just had to be done - so we decided to put the Legacy system to rest, and began working on the all-new GraphCMS from the ground up.

After several rounds of feedback and input from you, we finally released the new GraphCMS in April of this year, fresh with our own GraphQL core engine that was showing us 40x - 100x performance gains.

![Legacy GraphCMS Website](https://media.graphcms.com/aDLonCKQJU1e8w6Mv2gF)

To match up to what the product was starting to be capable of, we decided it was also time to refresh who we, as a company, were. Our much-loved website had begun to look like a remnant of that legacy era. The all-new UI needed an equally refreshing website to match up to it, and to reflect the increasing maturity of the product’s capabilities, and so, here we are.

All these months later, some of us still admire that logo as much as the day we first put it live. Much love to [Damian Kidd](https://dribbble.com/damiankidd) for making that happen for us.

## A lot can happen in 8 months

![Product Hunt](https://media.graphcms.com/wTPCWxbQ9yvHNqztGG0Q)

Ever since our [Product Hunt](https://www.producthunt.com/posts/graphcms-3) relaunch in April of this year, we’ve been rolling out updates and features to help you bring your ambitious ideas to life faster.

Our in-app chat and Slack community are two of the most engaged, supportive, critical, and vocal channels of communication we have with you - our users - and you’ve had a lot to say! You’ve helped shape our year’s releases into one that’s empowered you to build better, which is all we’re here for really.

In [May](https://graphcms.com/blog/may-2020-product-update) we rolled our new environments developer workflow, and improved custom content views, to streamline your content management within GraphCMS. We also worked on a few examples with common frameworks to make it easier for you to use GraphCMS with your preferred stack. Big shoutout to [Ambroise](https://github.com/vadorequest) from [UnlyEd](https://unly.org) for contributing examples with NextJS to that repo!

In [June](https://graphcms.com/blog/june-2020-product-update) we introduced versioning, along with updates to the free plan. But more importantly, we were blown away by how [Colby Fayock](https://twitter.com/colbyfayock) used GraphCMS with Gatsby and LeafletJS to spin together with a [travel bucket list map](https://www.freecodecamp.org/news/how-to-create-a-travel-bucket-list-map-with-gatsby-react-leaflet-graphcms) that was also featured on FreeCodeCamp.

![July 2020](https://media.graphcms.com/La2X4AvRQwi4qFkO0x1g)

In [July](https://graphcms.com/blog/july-2020-product-update) we announced that our one-click migration tool was live, so you could easily migrate your Legacy GraphCMS projects to the new app, where we’d just dropped Preview URLs and Field Validations. July was also the month when [Arunoda](https://twitter.com/arunoda) kick-started his NextJS course - [Bulletproof Next](https://getstarted.sh/bulletproof-next) - helping new developers master NextJS.

![August 2020](https://media.graphcms.com/DLEcqwuPQPS9BU7I5col)

[August](https://graphcms.com/blog/august-2020-product-update) was one for the teams. Alongside project cloning, we wanted to make sure that you could bring in your colleagues into your project, and alongside a brand new dashboard to make onboarding easier, we rolled out a simpler way to invite your team and work together on GraphCMS projects. From the community, [Marco Streng](https://github.com/marco-streng) pushed out an exceptional piece to show how you can [trigger a GitHub Actions workflow](https://dev.to/marcostreng/static-site-builds-with-github-actions-and-graphcms-3edi) from GraphCMS, while Stephen from [CodeMochi](https://codemochi.com) launched his [second course using NextJS and GraphCMS](https://courses.codemochi.com/frontend-serverless-with-react-and-graphql) - building a recipe sharing application.

![September 2020](https://media.graphcms.com/NRsJw0ZQQwi94SqrcwmE)

[September](https://graphcms.com/blog/september-2020-product-update) was for the editors. We rolled out custom content stages, batch updates, Rich Text Editor improvements, and a few refreshes to the content views. But the real stars of September were from the community. [Oluwole](https://twitter.com/mrflamez_), [Habeeb](https://twitter.com/SeniorBombata), [Wunmi](https://twitter.com/omo_mimie), and [Oshomah](https://twitter.com/oshomah) dropped an absolute firecracker of a [portfolio for Habeeb](https://bombata.pro/), using GraphCMS, React, GraphQL, and Lottie. On the other side of the Atlantic, [Colby](https://twitter.com/colbyfayock) released his amazing [Jamstack Handbook](https://jamstackhandbook.com/), including a guide on getting started with GraphCMS, Gatsby, and Netlify. Thanks for the love, Colby!

![October 2020](https://media.graphcms.com/h2JgTAQx6qbio7MmxdNw)

[October](https://graphcms.com/blog/october-2020-product-update) was all about the API. We rolled out Audit Logs to keep more visibility within GraphCMS projects, and pushed out drastic improvements to the creation flow of references - particularly nifty for GraphQL Union Types (Polymorphic Relations). We also introduced a new API for programmatic asset management, and gave our in-app notifications a complete redesign to get more information from them. After months of putting it together, we also launched our [Modular DXP Report](https://graphcms.com/resources/dxp-report-2020) that boasted contributions from the most wonderful people at companies like Algolia, AWS, G2, Commerce Layer, and VWO, to name a few. This is also when [Build Your DXP](https://buildyourdxp.com) went live - enabling many of you to put together a modular stack that helps your goals.

![November 2020](https://media.graphcms.com/KPpagPQnT22AyMdsTO0g)

[November](https://graphcms.com/blog/november-2020-product-update) kept the focus on the extensibility of the product, and on making sure we were innovating towards a better developer experience. What got us really excited was pushing out the all-new [GraphCMS API Documentation](https://graphcms.com/docs), written by [Jamie](https://twitter.com/notrab) along with tons of input from all of you, and the massive changes made to our [free plan](https://graphcms.com/pricing) - including localization, granular webhooks, raised user limits, and increased content limits.

This is also when we dropped our first official GraphCMS integration - [Netlify](https://graphcms.com/blog/graphcms-netlify-integration).

![December 2020](https://media.graphcms.com/ArpTWJaDQ9W1b0kH8ruh)

And finally, to wrap up the year, our December releases were very special to us. For a very long time, we wanted to push the boundaries of a Headless CMS further, and worked towards how we could empower developers to do more, when maintaining less. We achieved this by extending the idea of a Headless CMS being frontend agnostic, to being backend agnostic as well. This is something we like to call [Content Federation](https://graphcms.com/blog/introducing-content-federation), allowing you to connect any web service and API to your GraphCMS content model to query and join data across multiple sources with a single GraphQL query. We rolled out our new [GraphCMS Management SDK](https://graphcms.com/blog/management-sdk) to assist you with this - unlocking so many more use cases than we can imagine - which is why we’re counting on you to tell us what possibilities you come up with.

## All of us, around the world

We’ve always been exceptionally proud of seeing what you all have been accomplishing with GraphCMS over the years. From blazing fast Jamstack websites, to mammoth streaming applications delivering films to millions of viewers, you’ve consistently left us in awe of what you’re able to make possible with your stacks once you let your ambitions loose.

Scattered throughout the globe, you come from all corners of the world, and with a GraphCMS community now over 40,000 teams strong, pumped is an understatement for our expectations from the coming years.

We’ve all adjusted to a new style of working this year, and we’re humbled by the determination you’ve shown in not letting your ideas slow down, in fact, as a community, you’ve been more active than ever! We know this because we’ve enjoyed seeing you keeping Fabian on his toes all the time, and after several of you pointed out your surprise at how he seems to be responding to you literally within minutes, we investigated how that could be possible. Turns out he has a dedicated monitor slot for Intercom, and just never closes it. ¯\_(ツ)_/¯

![Fabi’s PC](https://media.graphcms.com/Q5NXunqGRLq6MADbbKvX)

Of course, we’ve tried to match all that activity internally as well, ensuring that we’re always pushing out new features, content, and initiatives to keep up with your expectations of us.

To join us in our mission to make the best Headless CMS out there, we’ve also expanded our team this year. We welcomed Pablo, Abiola, Marcos, Carlos, Larisa, Nava, Darshan, Michael, John, and Juela, into GraphCMS to accelerate our goals of making us constantly push the boundaries over the coming years.

![Welcome to the Team](https://media.graphcms.com/9aDhv3kQRxy7n2Lm0f9Z)

We also launched [Build Your DXP](https://buildyourdxp.com) alongside our highly researched [DXP report](https://graphcms.com/resources/dxp-report-2020) - our take into the world of composable architectures for digital experiences - made possible by the amazing insights from Algolia, AWS, BITGRIP, codecentric, Commerce Layer, Emerge Interactive, G2, Jovo, Optimise-It, Optimove, REVIEWS.io, VWO, Wootric, and Wordify.

We also took some time to catch up with [Kevin Indig from Shopify](https://www.youtube.com/watch?v=6WdKzydMUDo), [Filippo Conforti from Commerce Layer](https://www.youtube.com/watch?v=D9Z36-RiekA), [Kaya Ismail from Wordify](https://www.youtube.com/watch?v=RbcJtAAcsVk), and [Ekaterina Kromina from Honeypot](https://www.youtube.com/watch?v=6jUpE5Dot0U), on our GraphCMS Talks series to learn more about Content Strategy, Headless Commerce, Community Content, and Headless CMS.

And on top of all that, Jamie, Jesse, and Jonathan participated in several virtual events, live streams, and talks, to dive into all things Gatsby, Vercel, Algolia, NextJS, Stripe, React, GraphQL, and more. Check out all they got up to on the [GraphCMS YouTube Channel](https://www.youtube.com/channel/UCBhA9X2mbCyxvjBdlUOuCQQ), as well as on [Jamie’s](https://www.youtube.com/channel/UCcSj41xzQJCT2V0GNwlob_w), [Jonathan’s](https://www.youtube.com/channel/UC9Ylb1Sg5O1cwR24BZXqrGg), and [Jesse’s](https://www.youtube.com/channel/UCgJl4H9OV0G81kdyy9645uA) channels.

![Personas](https://media.graphcms.com/hOkZJhGDRr7NsJWfXcXg)

To call it a packed year would be an understatement, especially given all we have to look forward to. We’ve already taken in a lot of the feedback you’ve had for us to shape up our roadmap, and we’ll be kicking off 2021 with a fresh focus on the editor experience and on improving our API - to finally bridge the gap between [developers](https://graphcms.com/for-engineering) and [content creators](https://graphcms.com/for-content-creators) in a Headless CMS.

![Team Picture](https://media.graphcms.com/7rFdCWNST0uTesbsMHPY)

Until then, here’s the GraphCMS team recharging a bit for the rest of the year (except for Fabi, probably), and looking forward to accomplishing even more with you next year.

Happy Holidays!


2020's been an extraordinary year for us all. Here's a small recap of the defining moments we shared together.

Looking Back: GraphCMS in 2020

Ronak Ganatra

VP of Marketing

Jamie Barton

Head of Developer Relations

We recently launched [Build Your DXP](https://buildyourdxp.com), a community-curated catalog of microservices that come together in powering powerful and modular Digital Experience Platforms (DXP), enabling companies to fulfill their goals of delivering better customer experiences.

As companies are transitioning towards digitizing and modernizing, alongside breaking down monolithic stacks, the need for finding best-of-breed services to accomplish their use cases is gaining importance by the day. To assist teams in exploring and finding these services, and to promote an API-first and microservice led approach, we've decided to launch Build Your DXP with the hopes of helping you decide on the services that are best suited to your goals.

Build Your DXP is [open sourced on our GitHub profile](https://github.com/GraphCMS/buildyourdxp.com), and we [encourage contributions from anyone in the wider community](https://buildyourdxp.com/contribute) to help us in putting together a more comprehensive and objective directory of services by sharing your input! The purpose of putting this out there is to arm you with the context and insights you need to make well-informed decisions when evaluating for and implementing a modern stack, without any pretense.

## What is a Digital Experience Platform (DXP)?

A DXP, or a [Digital Experience Platform](https://www.gartner.com/en/information-technology/glossary/digital-experience-platform-dxp-), is an emerging category of software aiming to tackle the primary goal of perfecting the customer experience, or CX. Traditionally DXPs have been "full-stack" monoliths that provide an architecture for businesses to digitize their business goals, marketing activities, analytics, and content management. Over time, with the rise of API-driven approaches and the need for omnichannel content distribution, there has been an emergence of micro-services based DXPs, which are essentially a loosely-coupled combination of products working in harmony.

### About Build Your DXP

BuildYourDXP is an open-source compilation of tools and services that typically come together to form a DXP - the website is maintained by us at GraphCMS, built using GraphCMS, [Gatsby](https://gatsbyjs.com), and [TailwindUI](https://tailwindui.com/), and deployed on [Vercel](https://vercel.com).

![Build Your DXP.png](https://media.graphcms.com/jBWbqEfSwqyiDouKGgfp)

Our goal is to provide an objective landscape of services that follow certain guidelines:

- All tools and services must integrate with one another, either natively, or via a series of configurations.
- They must be independent of the other - whether for deployment, adding in, removing, or modifying - i.e. not a "monolith".
- They must provide an API.
- While not necessarily "Headless", each tool must be prominent in its category as an independently scalable component.
- No vendor should be a "monolithic" DXP by itself.
- Each vendor should be a cloud-based SaaS solution for easy adoption, without the obstacles of self-hosting, on-premises, or security upgrades.

To ensure that the information is as up-to-date and comprehensive as possible, this project is completely open-source, and edits/additions are welcomed.

### Components and Services Selected

![DXP Components.png](https://media.graphcms.com/SRKBmeMBT2SlECk9UIpV)

The "components", or categories chosen, are those that most prominently appear, or can be included, in most B2B and B2C use cases across industries without niche barriers.

- AB Testing
- AI and Machine Learning
- Analytics
- Authorization & Authentication
- CDP (Customer Data Platform)
- Chatbots
- Cloud Services (Hosting and Deployment)
- Customer Engagement
- eCommerce
- Headless CMS
- Marketing Automation & CRM
- NPS
- Payments
- Personalization Engines
- Reputation Management
- Sales Automation & CRM
- Search & Discovery
- Voice

We have attempted to curate as many micro-services as we can - to compile a comprehensive list of leading vendors for each category, and when selecting microservices to build your own DXP, we encourage you to conduct your own due diligence into how these services apply to your use-cases.

### Contributing to Build Your DXP

To contribute to this project, simply [fill in the form](https://buildyourdxp.com/contribute) and share the name of the service you wish to include, what category it would fall under, and optionally, your email address for us to reach out to you when we update the website.

We recently launched a community-curated catalog to explore the best-of-breed services that power today's Digital Experience Platforms.

Why we decided to create Build Your DXP

This short guide is aimed at new users and will walk through creating a project, schema, content, publishing and querying via GraphQL. You'll need an account to get started, [sign in](https://app.graphcms.com) or [create a new account](https://app.graphcms.com/signup).

## 1. Create a Project

Once logged in, you will see a list of any projects you create or have been invited to.

1. First, select "Create a new project" to create your first project.
2. Next, give your project a name, and pick a region for where you want content to be located.
3. Now pick an applicable plan for your needs. _The free plan will work with steps outlined in this guide._

## 2. Create a Model

From the sidebar, navigate to the **Schema** editor.

Now, **Add** a new Model called `Product`, keeping the default `API ID` and `Plural API ID` intact.

![Create Product Model](https://media.graphcms.com/vLoqFdYlSaaGFRCA0QOw)

We now have a `Product` model within our GraphQL schema. _This is often thought of as a database "table" or "collection" in NoSQL._

## 3. Add Fields

We will now add some fields to our `Product` model for a product `name`, `price` and `image`. To add a field, select one of the field types from the right side of the schema editor.

#### 3.1: Create a Name field

Select **Single line text** from the available types and set the **Display Name** to `Name`, and mark the field as **required**.

#### 3.2 Create a Price field

Next, select **Integer** from the available types and set the **Display Name** to `Price`, and mark the field as **required**.

#### 3.3 Create an Image field

For product images, we can take advantage of the `Asset` model. Creating an Image field using Asset will create a relation between the two models.

<InfoBlock>

Assets are a core feature in GraphCMS and added to every new project by default.

</InfoBlock>

Select **Asset Picker** from the available types and set the **Display Name** to `Image`, and **allow multiple values**.

---

Your `Product` model should now look a little something like the following.

![Product Model](https://media.graphcms.com/ODTom51tSWOk5PH6Idhj)

## 4. Create a Product (Content Entry)

We will now add some content to our `Product` model. To add a product, using the sidebar, navigate to the **content** editor.

Select `Product` from the list of models on the left.

<InfoBlock>

Once content is added, entries will appear in the table view where you can filter, and paginate your content to find what you're looking for to edit.

</InfoBlock>

Click **Create New** from top right to create your first content piece.

Give the Product a **Name** and **Price**.

<InfoBlock>

`Name` and `Price` were to set to **required** in the schema, so the UI here reflects those constraints. `Image` allows multiple images to be uploaded since we allowed **multiple values** in the schema.

</InfoBlock>

Next, upload one or more images by clicking **Add assets** and then **Upload** inside the modal.

**Pick any image(s) from your computer, or social network account to upload**.

Once uploaded, your content entry should look a little something like this.

![Product Content](https://media.graphcms.com/Gt8xFsnTIK7kOFSxDnJl)

## 5. Save and/or Publish

Once content has been written, or updated, it's important to save or publish any changes.

By default, all content that you create will be have the a `stage` field, set to `DRAFT`.

Once you publish content, a copy is then made for the `PUBLISHED` stage. Drafts can be thought of as the master copy of content, where you can then push to the `PUBLISHED` stage.

<InfoBlock>

Content can be queried using the `stage` which represents either `DRAFT` or `PUBLISHED` state.

</InfoBlock>

## 6. Query content

GraphCMS provides a built-in API Playground to query and mutate content across your project.

From the sidebar, select **API Playground**. It's here where we will run the queries below.

Let's begin by querying for all `products`, regardless of their published state.

```graphql
{
  products {
    stage
    name
    price
    image {
      url
      fileName
    }
  }
}
```

If you want to return `DRAFT` products only, then we can pass an argument to the `products` query.

```graphql
{
  products(stage: DRAFT) {
    name
    price
    image {
      url
      fileName
    }
  }
}
```

## 7. Open the API

Navigate to your settings panel and enable access to your API. You can either enable full public access to your API or [protect your API with permanent auth tokens.](https://graphcms.com/docs/authorization)

![Project API Permissions](https://media.graphcms.com/uGxuyC6YRMSSxKfswuMH)

Now that the API is public, let's test it. Copy your project's API endpoint and paste it in your URL bar for your browser.

![Project Endpoint](https://media.graphcms.com/4zhv3mdWQC6jWLJzEEAq)

In the GraphQL playground, run the queries above once more. These are now publicly accessible on the web!

This short guide is aimed at new users and will walk through creating a project, schema, content, publishing and querying via GraphQL.

GraphCMS Quickstart Guide

Fabian Beliza

Product Management

We are pleased the announce the new version of GraphCMS. Our Team has put a lot of time and effort into delivering the future of content management. In this guide we will discover all the new features, find out how we can migrate to the new version and what breaking changes you might stumble upon.

**The Legacy System will be shutting down on February 1st 2021!**

## New Features

### New User Interface

We spent the last few months overhauling the complete GraphCMS experience. The UI comes now in a much lighter representation, helping you and your editors to focus on the important things.

![UI Refresh Content Model](https://media.graphcms.com/unQCadBQTGVvB6ICoZke)

The editing interface also features a new sidebar (right side) to help you keep track of publishing, localizations and versions.

![UI Refresh Content Form](https://media.graphcms.com/yNKVUtabTteaO1vTlEa8)

### Content Staging: Drafting & Publishing

One of the biggest changes to GraphCMS is the introduction of **Content Staging**. It allows your editors to keep working on drafts, without altering the published version.

By default, all content that you create will be in the `DRAFT` stage. Once you decide to publish your entry, a copy will be pushed into the `PUBLISHED` stage of your project. You can also decide which localizations of your entry you want to publish, giving you full control of the workflow.

![Publishing Entry](https://media.graphcms.com/dTVDJrccRwuVveC9Pee2)

The content edit form also offers a comparison view to compare your current draft version with the published version.

### Sortable Relations

Relations also got a significant update. From now on, you can manually determine the order of your related entries via drag and drop in the content management interface.

As can be seen on the short clip, we have replaced the relation table with an easy to use list, that renders the **title fields** of the connected model. You can configure title fields in the field configuration.

Relations can also be sorted by using the mutation API.

### Polymorphic Relations: Support of GraphQL Union Types

Easily building complex content structures like a large set of landing pages will become much easier with the new version of GraphCMS. Relations can now be polymorphic, meaning a model can be connected to multiple other models. Polymorphic relations also allow ordering of the connect entries, as seen above.

### Localization Improvements

Just like before, localization can be enabled on field level. However, one big difference in the new system is, that you can now selectively enable or disable localizations per entry. This allows you to have certain entries only in your default language, while others are partly or fully translated. The new publishing feature also allows you to have full control on what locales are published to a stage.

![Add Localizations](https://media.graphcms.com/tWxDfJPOSYar2iuW8nmE)

Locales are configurable in your project settings.

Accessing localizations via the API has also improved. Read more about this in the **Breaking Changes** section.

### Granular Webhook

The new GraphCMS allows you granularly define the trigger of your webhooks. You can choose on which Content models, stages and actions the webhook should trigger. For example, if you want to rebuild your static website only when content is published or unpublished from a stage, you can do that now!

## How to Migrate

<InfoBlock>

Migrating a project will create a copy in the new system. The old project will remain active until you decide to remove it. If you have an active subscription, reach out to us to discuss moving it to the new project.

</InfoBlock>

Projects migrated to the new system also have a new API endpoint. This means modifications of your website or your app code might be necessary. Read more about the breaking changes to queries and mutations in the section "Breaking Changes" below.

In order to migrate your legacy project, you can head to [app.graphcms.com](https://app.graphcms.com) and login with your existing user account.
If you scroll down, you can see a section called "Legacy Projects". Click on the project you want to migrate and the following dialog will open:

![Migration Dialog](https://media.graphcms.com/OkQy595TBu7kvSgDHq1A)

Select "Configure and clone" to start configuring the parameters for the migration. You can select if you want to clone over content & assets, members, webhooks and content views. If you also want to move your existing subscription to the new project, tick the box to notify us at the bottom.

![Migration Config](https://media.graphcms.com/3WzX3gWwSsuLB1uK1aMR)

Once those settings are configured, just press "Clone Now" and the process will be kicked off. Depending on the size of your project, this might take a while. We will send you an email as soon as the migration is done or failed. 

<InfoBlock>

Only the owner is able to clone the project into the new system.

</InfoBlock>

## Breaking Changes

### Publishing

To find out more, also have a look into our [Content Stage Documentation](https://graphcms.com/docs/content-api/content-stages).

<InfoBlock>

The old `status` field is now called `stage`.

</InfoBlock>

Publishing of entries via the API is now done by using a `publishModel` mutation. The normal publish mutations takes a `where` argument to select the entry to publish by ID or other unique fields. You also need to specify the content stage you want to publish to with the argument `to`.

```graphql
mutation publish {
  publishPage(where: { id: "xxx" }, to: PUBLISHED) {
    id
  }
}
```

The arguments for models with localized fields are `where`, `locales`, `publishBase` and `to`. With `where` you decide which document to publish by ID or any other unique fields. `locales` allows you to publish any additional locales besides the default locale. `publishBase` is a flag that lets you publish the default locale, relations and the base fields (non-localized scalar fields). Finally `to` is the target stage, so `PUBLISHED` currently. In the future you will be able to create additional content stages.

```graphql
mutation publish {
  publishPost(
    where: { id: "xxx" }
    publishBase: true
    locales: [de, es]
    to: PUBLISHED
  ) {
    id
  }
}
```

To find out in which stages your document and its localizations are available, you can use the following query as example:

```graphql
{
  pages {
    documentInStages(includeCurrent: true) {
      id
      stage
      localizations(includeCurrent: true) {
        locale
        stage
        title
      }
    }
  }
}
```

### Localization

In the new version of GraphCMS we have reworked the way localization works on the API level.

More information is also available on the [Localization Documentation](https://graphcms.com/docs/content-api/localization) page.

In order to fetch available localizations, you can use the following query as example. `includeCurrent` allows to specify if the current selected locale should be included in the `localizations` list. If no other locale is specified in the header or query param, the default locale will be returned.

```graphql
{
  pages {
    id
    title
    slug
    locale
    localizations(includeCurrent: true) {
      locale
      title
    }
  }
}
```

The returned data will look like this, where the default locale is `en`:

```graphql
{
  "data": {
    "pages": [
      {
        "id": "ck7g2vs1k00110188fmc81h26",
        "title": "Homepage",
        "slug": "homepage",
        "locale": "en",
        "localizations": [
          {
            "locale": "en",
            "title": "Homepage"
          },
          {
            "locale": "de",
            "title": "Startseite"
          }
        ]
      }
    ]
  }
}
```

Creating localized Entries via the API can be done as follows. The top level fields in the `data` object always belong to the default locale or are non-localized fields. Adding additional locales can be done by passing the `localizations` object, which allows to `create` or `update` locales.

```graphql
mutation xx {
  createPage(
    data: {
      title: "English"
      slug: "testing"
      localizations: { create: [{ data: { title: "German" }, locale: de }] }
    }
  ) {
    id
  }
}
```

#### Passing a locale header

The `gcms-locales` header is also still present, which allows you to specify the returned locale of the query you are sending.

An example could look like this: `'gcms-locales': 'rb, de, en'`. Here the order specifies the fallback order. If theres no localization for locale `rb`, `de` will be used. If there's no localization for `de`, `en` will be used.

Locales should always be lowercase.

The `gcms-locale-no-default` header is no longer supported.

### API Filters

The new version of GraphCMS replaces the `pre-applied filters` for Public APIs and Permanent Auth Tokens with a content staging system with selective configuration of default stages.

![API Filter](https://media.graphcms.com/gfLzhzO3TBaul7skv1IV)

### Date Fields

The normal date fields are now actual date fields in the format of `2020-03-26`, opposed to the legacy system where it still included a time.

The format of the DateTime fields also changed slightly from `2018-12-14T14:32:46.082Z` to `2018-12-11T20:20:00+00:00` in the new system.

### Result Set Size

The new system has a default result set size of 100 entries. This means that any query will return a maximum of 100 entries. You can extend this result set up to 1000 entries by using the `first` parameter:

```graphql
{
  products(first: 1000) {
    name
  }
}
```

If you want to fetch more than these 1000 entries, you should make use of pagination. In general, we highly recommend to use GraphQL pagination whenever possible.

### Rich Text Raw Value

The new system introduces a new Rich Text AST, which is now based on SlateJS v0.5. This means that mutating rich text fields now requires using the new AST. You can find out more about it in our [documentation](https://graphcms.com/docs/schema/field-types#rich-text).

### Assets are localized by default

Our new system introduces a major change to the way we handle localization, as mentioned before on this page. Thus we also changed the way how localization works with Assets. Previously you were able to mark asset fields as localized, in the new system, the Asset entry itself is localized already. This means on an asset entry you can upload a file for each localization that you have in your project.

This also applies to localized relation fields in the old system. As the entries now handle the localization on the document itself, this isn't needed anymore in the new system.

### Uploading Assets via API

We also introduced a new way to upload Assets via API, which you can find [here](/docs/content-api/assets#uploading-assets).

### DESC Filtering

If you are using a _desc filter, e.g. on integer fields, `null` values will now appear at the top, due to the default setting on the database engine. In the future we will add an option to configure this on a query-basis.

### Multiple Value Field "set"

In Legacy a multiple value field, for example of type string, required to pass a `set` field that took the array of values. In the new system, this isn't needed anymore. You can just pass the array to the field itself and it will act as a `set`, overwriting ever value in the array of the entry with the array you are passing into it.

### Update, Upsert and Nested Mutations

The connect part for nested mutations changed compared to the legacy system. Instead of just passing a list of IDs, you will now need to pass an object with a where filter on for example the ID. This change has been made to allow adding sortable relations, which can be set using the "position" field on that same object. This will apply to mutations of type "update". 

`connect: [{where: {id: "123"}}, {where: {id: "234"}, position: {end: true}}]`

Additionally, the upsert mutations no includes a "upsert" object inside of the mutation like this:

```graphql
mutation {
  upsertPost(
    upsert: {
      create: {},
      update: {}
    }
    where: {},
  ) {}
}
```

Lastly, nested mutations for `update`, do not include an `updateMany` and `deleteMany` portion anymore. As a workaround, you can make use of the normal `updateManyConnection` and `deleteManyConnection` mutations with filtering applied.

The Emergence of Composable DXPs

GraphCMS Blog: Miscellaneous