Forem: Hygraph

Hygraph FM: Building an artist page with components and Next.js

Lo Etheridge — Fri, 15 Sep 2023 15:44:07 +0000

Building Hygraph FM

In the first part of this series, we created an artist content model and components as well as connected LastFM as a remote source to get our music platform project, Hygraph FM. Now that these elements are in place, it’s time to put our content model into action!

In this article, we will build a frontend using Next.js 13 and federated content from Hygraph. To do this, we’ll create the artist summary pages to render the artist bio, genre tags, and similar artists. Additionally, we will create a home page that showcases featured artists, a landing page that lists all artists on Hygraph FM, and render our promotional block components.

Missed the first part of the series? Clone the schema and content to follow along with this article.

Series:

Part 1: *Hygraph FM: Building the artist content model*

Project setup

To start, we need to initialize a new Next.js 13 project. Open up your terminal and navigate to where you want your project, then run the following command:

npx create-next-app hygraphfm

The interactive setup will ask you questions to configure your project. Initialize with the following answers:

Typescript: No
ESLint: Yes
Tailwind CSS: Yes
src/ directory: No
App Router: Yes
Import alias: No

Once the options are chosen, the CLI will install all the necessary pieces to run your Next.js site.

Once the installation completes, open the new Next project in a code editor of your choice. We need to adjust the default Tailwind styling that Next.js gives us from the installation.

Update the global CSS rules in app/globals.css to add the following extra styling but leave the file with the following Tailwind imports:

@tailwind base;
@tailwind components;
@tailwind utilities;

Additional Styling:

/* global.css */

@tailwind base;
@tailwind components;
@tailwind utilities;

:root {
  --foreground-rgb: 29, 33, 39;
  --background-start-rgb: 214, 219, 220;
  --background-end-rgb: 255, 255, 255;
}

@media (prefers-color-scheme: dark) {
  :root {
    --foreground-rgb: 255, 255, 255;
    --background-start-rgb: 29, 33, 39;
    --background-end-rgb: 29, 33, 39;
  }
}

body {
  color: rgb(var(--foreground-rgb));
  background: linear-gradient(
      to bottom,
      transparent,
      rgb(var(--background-end-rgb))
    )
    rgb(var(--background-start-rgb));
}

/* Add the following styling */

.background-radial-gradient {
    background-color: hsl(218, 41%, 15%);
    background-image: radial-gradient(650px circle at 0% 0%,
            hsl(218, 41%, 35%) 15%,
            hsl(218, 41%, 30%) 35%,
            hsl(218, 41%, 20%) 75%,
            hsl(218, 41%, 19%) 80%,
            transparent 100%),
          radial-gradient(1250px circle at 100% 100%,
            hsl(218, 41%, 45%) 15%,
            hsl(218, 41%, 30%) 35%,
            hsl(218, 41%, 20%) 75%,
            hsl(218, 41%, 19%) 80%,
            transparent 100%);
      }
.all-links > a {
  text-decoration: underline;
}

.fm-mode {
  mix-blend-mode: color-dodge
}

After adding a few global styles, we need to connect Hygraph to our Next project so that we can use the data from our artist content model.

Connecting Hygraph to Next

To make Hygraph accessible to our Next.js project, we need to allow read permissions on the Content API. Head over to your project’s settings and click on API Access. To start, let’s set the public content API to its default. This will give us access to all the content in our models, including the remote data from LastFM to read into our Next project. From this same screen, copy the Content API endpoint URL.

Create a new file in the root of your project named .env.local and add the variable HYGRAPH_ENDPOINT.

This will be where we paste the endpoint URL we copied from Hygraph:

//.env.local

HYGRAPH_ENDPOINT=YOUR-URL-HERE

Now we can start our Next site and build our frontend. In the terminal, type the following command to run the project locally in a browser of your choice:

# Terminal command to start Next project
npm run dev

Creating the homepage and featured artists

First, let’s build our header, navbar, and footer. In your app directory, create a new folder called components . In the components folders, create three files: Header.js, Footer.js, Navbar.js and add the following code respectively:

Header

// Header component: app/components/Header.js

export default function Header() {
    return (
        <header className="py-6 mt-0 background-radial-gradient">
            <div className="px-6 py-12 text-center md:px-12 lg:text-left">
                <div className="container mx-auto">
                    <div className="grid items-center gap-12 lg:grid-cols-2">
                    <div className="mt-12 lg:mt-0">
                        <h1 className="mb-12 text-3xl font-bold tracking-tight text-[hsl(218,81%,95%)] md:text-6xl xl:text-7xl">
            Hygraph<span className="text-[hsl(218,81%,75%)]">FM</span>
                        </h1>
                            <p className="text-lg text-[hsl(218,81%,95%)]">Hygraph FM is a community of artists, producers, listeners who are passionate about music and the creative process!
                        </p>
                    </div>
                    </div>
                </div>
            </div>
          </header>
      )
}

Navbar

// Navbar component: app/components/Navbar.js

'use client';
import Head from 'next/head';
import Link from 'next/link';
import { useState } from 'react';

export default function Navbar() {
  const [navbar, setNavbar] = useState(false);
      return (
      <nav aria-label="Hygraph FM Menu" role="navigation" className="w-full bg-gray-800 shadow">
        <div className="justify-between px-4 mx-auto lg:max-w-7xl md:items-center md:flex md:px-8">
          <div>
            <div className="flex items-center justify-between py-3 md:py-5 md:block">
              <Link href="/">
                <h2 className="text-3xl font-bold text-[hsl(218,81%,75%)]">HyFM</h2>
              </Link>
              <div className="md:hidden">
                <button
                  aria-label="Toggle Hamburger menu"
                  aria-expanded="false"
                  aria-controls="main-menu"
                  aria-haspopup="false"
                  className="p-2 text-gray-700 rounded-md outline-none focus:border-gray-400 focus:border"
                  onClick={() => setNavbar(!navbar)}
                >
                  {navbar ? (
                    <svg
                      xmlns="http://www.w3.org/2000/svg"
                      className="w-6 h-6 text-white"
                      viewBox="0 0 20 20"
                      fill="currentColor"
                    >
                      <path
                        fillRule="evenodd"
                        d="M4.293 4.293a1 1 0 011.414 0L10 8.586l4.293-4.293a1 1 0 111.414 1.414L11.414 10l4.293 4.293a1 1 0 01-1.414 1.414L10 11.414l-4.293 4.293a1 1 0 01-1.414-1.414L8.586 10 4.293 5.707a1 1 0 010-1.414z"
                        clipRule="evenodd"
                      />
                    </svg>
                  ) : (
                    <svg
                      xmlns="http://www.w3.org/2000/svg"
                      className="w-6 h-6 text-white"
                      fill="none"
                      viewBox="0 0 24 24"
                      stroke="currentColor"
                      strokeWidth={2}
                    >
                      <path
                        strokeLinecap="round"
                        strokeLinejoin="round"
                        d="M4 6h16M4 12h16M4 18h16"
                      />
                    </svg>
                  )}
                </button>
              </div>
            </div>
          </div>
          <div>
            <div
              className={`flex-1 justify-self-center pb-3 mt-8 md:block md:pb-0 md:mt-0 ${
                navbar ? 'block' : 'hidden'
              }`}
            >
              <ul 
              role="menubar" 
              aria-label="HygraphFM Menu Bar" 
              className="items-center justify-center space-y-8 md:flex md:space-x-6 md:space-y-0">
                <li className="text-white">
                  <Link role="menuitem" href="/">
                    Home
                  </Link>
                </li>
                <li className="text-white">
                  <Link role="menuitem" href="/artists">
                    Artists
                  </Link>
                </li>
                <li className="text-white">
                  <Link role="menuitem" href="/login">
                    Login
                  </Link>
                </li>
                <li className="text-white">
                  <Link role="menuitem" href="/contact">
                    Contact US          
                  </Link>
                </li>
              </ul>
            </div>
          </div>
        </div>
      </nav>
  );
}

Note: Since we are using state, the Navbar is no longer a server component like the Header and Footer. It is now part of the client bundle. As a result, we need to add the ‘use client’; directive at the top of the file to denote this change.

Footer

// Footer component: app/components/Footer.js

import Link from 'next/link';

export default function Footer() {
    return (
        <footer className="bg-gray-800">
            <div className="container flex flex-col items-center justify-between px-6 py-12 mx-auto md:flex-row">
                <a href="#" className="text-3xl font-bold text-white hover:text-gray-300">HyFM</a>
                <p className="mt-4 text-sm text-white md:mt-0">© 2023 HyFM —
                <Link href="/" className="ml-1 text-gray-400 hover:text-gray-300" rel="noopener noreferrer" target="_blank">@hyfm </Link>
                </p>
                <div className="flex mt-4 mb-2 -mx-2 md:mt-0 md:mb-0">
                    <Link href="#" className="mx-2 text-white hover:text-gray-300" aria-label="Linkden">
                        <svg className="w-4 h-4 fill-current" viewBox="0 0 512 512">
                            <path d="M437.019,0H74.981C33.629,0,0,33.629,0,74981v362.038C0,478.371,33.629,512,74.981,512h362.038
                                C478.371,512,512,478.371,512,437.019V74.981C512,33.629,478.371,0,437.019,0z M154.854,416H92.308V200.923h62.545V416z
                                M123.581,173.846c-20.654,0-37.423-16.769-37.423-37.423c0-20.654,16.769-37.423,37.423-37.423
                                c20.654,0,37.423,16.769,37.423,37.423C161.004,157.077,144.235,173.846,123.581,173.846z M416,416h-62.545V299.077
                                c0-24.654-0.469-56.308-34.308-56.308c-34.308,0-39.654,26.769-39.654,54.462V416h-62.545V200.923h59.115v28.923h0.831
                                c8.231-15.577,28.308-32.062,58.308-32.062c62.769,0,74.154,41.346,74.154,95.115V416z"/>
                        </svg>
                    </Link>
                    <Link href="#" className="mx-2 text-white hover:text-gray-300" aria-label="Facebook">
                        <svg className="w-4 h-4 fill-current" viewBox="0 0 512 512">
                            <path d="M437,0H75C33.6,0,0,33.6,0,75v362c0,41.4,33.6,75,75,75h362c41.4,0,75-33.6,75-75V75C512,33.6,478.4,0,437,0z M480,437
                                c0,24.9-20.1,45-45,45H75c-24.9,0-45-20.1-45-45V75c0-24.9,20.1-45,45-45h362c24.9,0,45,20.1,45,45V437z"/>
                            <path d="M341.3,164.7h-51.2c-14.1,0-25.6,11.5-25.6,25.6v51.2h-51.2v51.2h51.2v153.6h51.2V292.3h51.2l25.6-51.2h-76.8v-25.6
                                C366.9,176.2,355.4,164.7,341.3,164.7z"/>
                        </svg>
                    </Link>
                    <Link href="#" className="mx-2 text-white hover:text-gray-300" aria-label="Twitter">
                        <svg className="w-4 h-4 fill-current" viewBox="0 0 512 512">
                            <path d="M437,0H75C33.6,0,0,33.6,0,75v362c0,41.4,33.6,75,75,75h362c41.4,0,75-33.6,75-75V75C512,33.6,478.4,0,437,0z M384,188.8
                                c0,0.3,0,0.6,0,0.9c0,114.7-87.4,246.9-246.9,246.9c-49.1,0-94.9-14.3-133.3-39.1c7.1,0.8,14.3,1.2,21.6,1.2
                                c42,0,80.5-14.3,111.4-38.5c-39.3-0.8-72.3-26.6-83.7-62.3c5.5,1.2,11.1,1.8,16.9,1.8c8.2,0,16.3-1.2,23.9-3.4
                                c-41.4-8.2-72.3-44.7-72.3-88.5v-1.2c12.1,6.7,26.1,10.7,41.2,11.3c-24.5-16.3-40.5-44.1-40.5-75.4c0-16.3,4.1-31.4,11.3-44.7
                                c41.2,50.3,103.9,83.7,174.1,87.4c-1.8-8.2-2.9-16.6-2.9-25.1c0-60.3,48.9-109.2,109.2-109.2c31.4,0,59.2,13.4,78.8,34.7
                                c24.5-4.1,47.5-13.4,68.6-26.1c-8.2,25.1-25.1,46.2-47.5,59.2c21.6-2.9,42-8.2,61.1-16.6C448.8,153.6,418.7,174.7,384,188.8z"/>
                        </svg>
                    </Link>
                </div>
            </div>
        </footer>
    )
}

Now that we have these components in place, we are ready to create our homepage with featured artists.

Querying recent artists for featured artist content

On our homepage, we want to provide a curated selection of artists for our users. To achieve this, we can create a section showcasing featured or recently added artists on our platform.

To implement this feature, we can send a query to Hygraph using the last operator, which allows us to retrieve the latest additions to our platform. By requesting the last six artists added, we can display them in a dedicated, appealing content section on our homepage.

# GraphQL query to get the 6 most recent artists from Hygraph

query Artists {
        artists(last: 6) {
          slug
          artist
          id
          artistImage {
            altText
            url
            height
            width
          }
        }
      }

In the app directory, go to the file called page.js , delete everything and paste in the following code:

//Homepage with featured artists: app/page.js

import Image from 'next/image';
import Link from "next/link";

//Get all Artists

async function getArtists() {
  const response = await fetch(process.env.HYGRAPH_ENDPOINT, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      query: `
      query Artists {
        artists(last: 6) {
          slug
          artist
          id
          artistImage {
            altText
            url
            height
            width
          }
        }
      }`,
    }),
  });
  const json = await response.json();
  return json.data.artists;
}

export default async function Home() {
  const artists = await getArtists();
  //console.log(artists);
  return (
    <main className="flex flex-col justify-between">
      <section className="mb-32 text-center">
      <h2 className="my-12 text-5xl font-bold">
      Featured <span className="text-[hsl(218,81%,75%)] px-2 py-2">Artists</span>
      </h2>
          <div className="grid px-5 lg:gap-xl-12 gap-x-6 md:grid-cols-2 lg:grid-cols-4">
        {artists.map((artist) => {
          return (
            <div key={artist.id} className="px-2 pb-5 my-12 rounded-lg lg:mb-0 shadow-[0_2px_15px_-3px_rgba(0,0,0,0.07),0_10px_20px_-2px_rgba(0,0,0,0.04)] background-radial-gradient">
              <Image
                className="mx-auto my-6 rounded-lg shadow-lg dark:shadow-black/20 w-[350px] h-[175px]"
                src={artist.artistImage.url}
                width={artist.artistImage.width}
                height={artist.artistImage.height}
                alt={artist.artistImage.altText}
              />
              <Link 
                className="text-xl font-bold text-white underline" 
                href={`/artist/${artist.slug}`}>
                  {artist.artist}
              </Link>
            </div>
          );  
          })}
      </div>
    </section>
  </main>
  )
}

The above code makes a request to Hygraph gives us the name, slug, and image information for the last 6 artists from our artist content. This data is then rendered in a function that creates the Homepage.

Featured artist content will not only enhance the user experience by providing them with a selection of artists they may be interested in, but it will also help promote new artists and encourage users to explore the platform.

Great job! We now have a functional homepage for the Hygraph FM site, complete with featured artists that link to their individual bio pages. However, these links currently return a 404 error because the pages have not been created yet. Let's create them now!

Creating artist summary pages

To create individual pages for each artist on our platform, we need to establish a dynamic route to generate a unique page for every artist based on their slug. This allows us to provide content for each artist on our platform.

We will add a new directory called artist/[slug] in the app directory. Next, add a page.jsx file in your new artist/[slug] directory, which will serve as the template for each individual artist page. We will use this template to dynamically generate unique content for each artist based on their slug.

By creating a dynamic route for each artist, we can provide a more personalized experience for users on our platform. This will help to increase engagement and improve overall user satisfaction.


app/
┣ artist/
┃ ┗ [slug]/
┃   ┗ page.jsx

The structure of your project should match the file tree above. The [slug] new directory allows us to use our page.jsx as a file template to make a page for every artist. In the artist/[slug]/page.jsx file, add the following code:

//Artist individual page: app/artist/[slug]/page.jsx

import Image from "next/image";

async function getArtist(slug) {
    const response = await fetch(process.env.HYGRAPH_ENDPOINT, {
          method: "POST",
          headers: {
            "Content-Type": "application/json",
          },
          body: JSON.stringify({
                        // GraphQL query to Hygraph to retrieve artist content by slug
            query: `
            query Artist($slug: String!) {
              artist(where: {slug: $slug}) {
                lastFm: hygraphLastFmRemoteSourceField {
                    __typename
                    artist {
                      bio {
                        summary
                      }
                      tags{
                        tag{
                            name
                        }
                      }
                      similar {
                        artist {
                          name
                        }
                      }
                    }
                  }
                artist
                  id
                  slug
                  artistImage {
                    altText
                    height
                    url
                    width
                  }
                  promotionalBlock {
                    ... on Callout {
                      __typename
                      id
                      button {
                        text
                        url
                        id
                      }
                      title
                    }
                    ... on CallToAction {
                      __typename
                      id
                      button {
                        text
                        url
                      }
                      heading
                      image {
                        altText
                        height
                        width
                        url
                      }
                      body {
                        html
                      }
                    }
                  }
                }
              }`,
          variables: {
            slug: slug,
          },
        }),
      }
    );
    const data = await response.json();
    //console.log(data.data.artist);
    return data.data.artist
  }

  export default async function Artist({ params }) {
    const artistData = await getArtist(params.slug);
    return (
        <main className="flex flex-col justify-between w-full mx-auto bg-gray-600">
             <Image
                className="w-1/2 mx-auto mt-12 shadow-lg dark:shadow-black/20"
                src={artistData.artistImage.url}
                width={artistData.artistImage.width}
                height={artistData.artistImage.height}
                alt={artistData.artistImage.altText}
                />
        <section className="p-12">
          <div className="container mx-auto text-center xl:px-32">
            <div className="grid items-center lg:grid-cols-2">
              <div className="mb-12 lg:mb-0">
                <div className="relative z-[1] block bg-[hsla(0,0%,100%,0.55)] px-6 py-16 shadow-[0_2px_15px_-3px_rgba(0,0,0,0.07),0_10px_20px_-2px_rgba(0,0,0,0.04)] backdrop-blur-[30px] dark:bg-[hsla(0,0%,2%,0.55)] dark:shadow-black/20 md:px-12 lg:mr-16">
                    <h2 className="mb-3 text-4xl font-bold text-white">{artistData.artist}</h2>
                    <p className="text-left text-white all-links" dangerouslySetInnerHTML={{ __html: artistData.lastFm.artist.bio.summary }}>
                    </p>
                    <h3 className="my-4 text-xl font-bold text-center">Similar Artists</h3>
                        {artistData.lastFm.artist.similar.artist.map((similar) => {
                        return (
                            <div className="inline-grid grid-cols-1 gap-2 mb-2">
                            <span className="px-2 py-2 text-md ml-2 font-bold text-white rounded-sm bg-[hsl(215,34%,40%)]">{similar.name}</span>
                            </div>
                        );
                        })}
                    <h4 className="my-4 text-xl font-bold text-center">Tags</h4>
                        {artistData.lastFm.artist.tags.tag.map((tag) => {
                        return (
                          <div className="inline-grid grid-cols-1 gap-2 mb-2">
                            <span className="px-2 py-2 ml-2 text-sm font-bold text-black rounded-sm bg-[hsla(0,0%,100%,0.55)]">{tag.name}</span>
                          </div>
                        );
                        })}
                </div>
              </div>
          </div>
        </div>
      </section>
    </main>
    );
  }

Let’s breakdown this code down a bit. At the top of the file, we have an async function to fetch an artist by slug. The getArtist function fetches the artist data from Hygraph using the provided slug. Our content and remote data from LastFM is federated into a single API call that allows us to generate metadata for each artist dynamically. The Artist function is the template for each individual artist page and uses the getArtist function to retrieve and render the artist data. The page displays the artist's name, image, bio summary, similar artists, and tags.

Landing page for all Hygraph FM artists

To create a landing page that shows all artists on the platform, we need to create a new directory route in our app directory called artists . Create a new file called page.jsx inside the artists directory. Notice a pattern? In Next.js 13, page.jsx acts as file templates and the directory denotes what the route should be called when using the app router. In our case, this will contain the code to display all artists on the platform in a grid format.

/* File tree with artist 
landing page template */
app/
┣ artist/
┃ ┗ [slug]/
┃   ┗ page.jsx
┣ artists/
┃ ┗ page.jsx

Add the following code in the artists/page.jsx file:

// Landing page for all artists: app/artists/page.jsx

import Image from 'next/image';
import Link from "next/link";

// Get all Artists
async function getAllArtists() {
  const response = await fetch(process.env.HYGRAPH_ENDPOINT, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      query: `
      query Artists {
        artists {
          slug
          artist
          id
          artistImage {
            altText
            url
            height
            width
          }
        }
      }`,
    }),
  });
  const json = await response.json();
  return json.data.artists;
}

export default async function Artists() {
  const artists = await getAllArtists();

  return (
    <main className="flex flex-col justify-between">
      <section className="mb-32 text-center">
      <h2 className="my-12 text-5xl font-bold">
      All<span className="text-[hsl(218,81%,75%)] px-2 py-2">Artists</span>
      </h2>
      <div className="grid px-5 lg:gap-xl-12 gap-x-6 md:grid-cols-2 lg:grid-cols-4">
        {artists.map((artist) => {
          return (
            <div key={artist.id} className="px-2 pb-5 my-12 rounded-lg lg:mb-0 shadow-[0_2px_15px_-3px_rgba(0,0,0,0.07),0_10px_20px_-2px_rgba(0,0,0,0.04)] background-radial-gradient">
              <Image
                className="mx-auto my-6 rounded-lg shadow-lg dark:shadow-black/20 w-[350px] h-[175px]"
                src={artist.artistImage.url}
                width={artist.artistImage.width}
                height={artist.artistImage.height}
                alt={artist.artistImage.altText}
              />
              <Link
                className="text-xl font-bold text-white underline"
                href={`/artist/${artist.slug}`}>
                  {artist.artist}
              </Link>
            </div>
          );
          })}
      </div>
    </section>
  </main>
  )
}

In the above code, we create an async function called getAllArtists(). This function contains a GraphQL query that fetches all of the artists from Hygraph. The response will be returned as a JSON object, which we can loop through and display in our grid.

Once we have fetched all of the artists, we can then render them in our grid using the map() function. This function allows us to loop through each artist and display their information in a card-like format.

Our HygraphFM project now has a homepage and landing page for artists, and we created individual artist pages that display a bio, image, tags, and similar artists using a dynamic route in the app directory. We are almost done with our Next build! The last thing we need is to create server components to render our promotional content to help fulfill our organization’s business goals. We will start with creating the Callout server component.

Building server components in Next

In part 1 of this series, we built Button, Callout, and CTA components in Hygraph. These components will help content editors, and marketers create content for promotional and engagement campaigns. We added these components as a collection or modular component to our Artist content model, enabling us to create frontend code to display these content areas.

Making a Callout component

To implement a Callout component, we need to create a file named Callout.js inside the components directory. This component will render a promotional message with a button to invite new users to join Hygraph FM.

// Callout component: app/components/Callout.js

import Link from "next/link";

export default function Callout({button, title}) {
    return (
        <div className="block p-16 mb-8 background-radial-gradient">
            <h4 className="text-3xl font-bold leading-tight text-neutral-800 dark:text-neutral-50">{title}
            </h4>
            {button ? <Link className="inline-block py-3 mt-4 mr-2 text-sm font-medium leading-snug text-gray-700 uppercase bg-gray-200 rounded shadow-md px-7 hover:bg-gray-800 hover:shadow-lg hover:text-white" href={button.url} role="button">
{button.text}</Link> : ''}
        </div>
    )
}

The Callout component takes two props: button and title. The title prop is the main text of the message, while the button prop is an object with two properties: text and url.

The Callout is ready to use in our application to promote our content and increase user engagement.

Call to Action (CTA) component

To create the CTA component, we need to create a new file in the components directory called CallToAction.js.

// CTA component: app/components/CallToAction.js

import Link from "next/link";
import Image from "next/image";

export default function CallToAction({body, heading, button, image}) {
    return (
        <section className="mb-32 bg-gray-800">
            <div className="px-6 py-12 text-center md:px-12">
                <div className="container mx-auto">
                <h2 className="mb-12 text-3xl font-bold tracking-tight md:text-4xl text-[hsl(218,81%,95%)]">{heading}</h2>
                    <div className="grid items-center gap-12 sm:gap-3 lg:grid-cols-2">
                        {image ? <div className="mb-6 lg:mb-0">
                            <Image
                            className="w-full rounded-lg shadow-lg"
                            src={image.url}
                            alt={image.altText}
                            width={image.width}
                            height={image.height}
                            />
                        </div> : ''}
                        <div className="mt-6 lg:mt-0">
                           <div className="mb-12 text-white text-md" dangerouslySetInnerHTML={{ __html: body.html }} />
                           {button ? <Link className="inline-block py-3 mr-2 font-medium leading-snug text-gray-700 uppercase bg-gray-200 rounded shadow-md text-md px-7 hover:bg-gray-800 hover:shadow-lg hover:text-white" href={button.url} role="button">{button.text}</Link> : ''}
                        </div>
                    </div>
                </div>
            </div>
  </section>
    )

}

Let’s break down the code a bit. The CTA component takes several props, including body, heading, button, and image. These are the same field types we used when we created the CTA component in Hygraph. The body prop will contain the body text of the CTA, while the heading prop will contain the main heading. The button prop will contain an object with two properties: text and url, which will be used to render a button with a link. The image prop will contain an object with properties such as url, altText, width, and height to render an image.

We can now import these components into a page template and render them on the homepage, individual artist pages, or wherever needed! For example, in the app/artist/[slug]/page.jsx file, we can modify the code to include the updated query fetching promotional blocks content.

//Artist individual page: app/artist/[slug]/page.jsx

import Image from "next/image";
import Callout from "@/app/components/Callout";
import CallToAction from "@/app/components/CallToAction";

async function getArtist(slug) {
    const response = await fetch(process.env.HYGRAPH_ENDPOINT, {
          method: "POST",
          headers: {
            "Content-Type": "application/json",
          },
          body: JSON.stringify({
            query: `
            query Artist($slug: String!) {
              artist(where: {slug: $slug}) {
                lastFm: hygraphLastFmRemoteSourceField {
                    __typename
                    artist {
                      bio {
                        summary
                      }
                      tags{
                        tag{
                            name
                        }
                      }
                      similar {
                        artist {
                          name
                        }
                      }
                    }
                  }
                artist
                  id
                  slug
                  artistImage {
                    altText
                    height
                    url
                    width
                  }
                  promotionalBlock {
                    ... on Callout {
                      __typename
                      id
                      button {
                        text
                        url
                        id
                      }
                      title
                    }
                    ... on CallToAction {
                      __typename
                      id
                      button {
                        text
                        url
                      }
                      heading
                      image {
                        altText
                        height
                        width
                        url
                      }
                      body {
                        html
                      }
                    }
                  }
                }
              }`,
          variables: {
            slug: slug,
          },
        }),
      }
    );
    const data = await response.json();
    //console.log(data.data.artist);
    return data.data.artist
  }

  export default async function Artist({ params }) {
    const artistData = await getArtist(params.slug);
    return (
        <main className="flex flex-col justify-between w-full mx-auto bg-gray-600">
             <Image
                className="w-1/2 mx-auto mt-12 shadow-lg dark:shadow-black/20"
                src={artistData.artistImage.url}
                width={artistData.artistImage.width}
                height={artistData.artistImage.height}
                alt={artistData.artistImage.altText}
                />
        <section className="p-12">
          <div className="container mx-auto text-center xl:px-32">
            <div className="grid items-center lg:grid-cols-2">
              <div className="mb-12 lg:mb-0">
                <div className="relative z-[1] block bg-[hsla(0,0%,100%,0.55)] px-6 py-16 shadow-[0_2px_15px_-3px_rgba(0,0,0,0.07),0_10px_20px_-2px_rgba(0,0,0,0.04)] backdrop-blur-[30px] dark:bg-[hsla(0,0%,2%,0.55)] dark:shadow-black/20 md:px-12 lg:mr-16">
                    <h2 className="mb-3 text-4xl font-bold text-white">{artistData.artist}</h2>
                    <p className="text-left text-white all-links" dangerouslySetInnerHTML={{ __html: artistData.lastFm.artist.bio.summary }}>
                    </p>
                    <h3 className="my-4 text-xl font-bold text-center">Similar Artists</h3>
                        {artistData.lastFm.artist.similar.artist.map((similar) => {
                        return (
                            <div className="inline-grid grid-cols-1 gap-2 mb-2">
                            <span className="px-2 py-2 text-md ml-2 font-bold text-white rounded-sm bg-[hsl(215,34%,40%)]">{similar.name}</span>
                            </div>
                        );
                        })}
                    <h4 className="my-4 text-xl font-bold text-center">Tags</h4>
                        {artistData.lastFm.artist.tags.tag.map((tag) => {
                        return (
                          <div className="inline-grid grid-cols-1 gap-2 mb-2">
                            <span className="px-2 py-2 ml-2 text-sm font-bold text-black rounded-sm bg-[hsla(0,0%,100%,0.55)]">{tag.name}</span>
                          </div>
                        );
                        })}
                </div>
              </div>
            <div>
                {artistData.promotionalBlock.map((block) => {
                  if (block.__typename === 'Callout') {
                    return <Callout key={block.id} title={block.title} button={block.button}/>
                  }
                  if (block.__typename === 'CallToAction') {
                    return <CallToAction key={block.id} heading={block.heading} body={block.body} button={block.button} image={block.image} 
                    />
                  }
                })}
            </div>
          </div>
        </div>
      </section>
    </main>
  );
}

Once we have retrieved our promotional blocks, we can use an if statement to check the type of each block and render either the Callout or CallToAction component accordingly.

Putting it all together

Now that everything is in its right place, we can render all of our content, components, and remote source data on the artist page:

Our reusable promotional components allow us to incorporate business goals and create a scalable codebase that can be easily modified when new features are needed. Connecting a remote source allowed us to use artist metadata that will automatically update if there are any changes in the LastFM API. Moreover, by using remote source data, we avoid duplicating content that is maintained in another system. This helps us to reduce development time, increase flexibility, and maintain consistency across the content as well as our application.

Next steps…

For part 3 of this series, we will take our Hygraph FM project a step further and explore pagination to maintain user experience as our platform grows. In the meantime, try adding new callouts, CTAs, or new artists and see how the pages change.

Hygraph FM: Building the artist content model

Lo Etheridge — Fri, 15 Sep 2023 15:39:05 +0000

We all have our preferred music streaming platform that provides the soundtrack to our day. No matter the platform you choose, they all have content for each artist such as a photo, bio, and suggestions for similar artists.

Let’s learn how to build an artist content model using the LastFM Rest API as a remote source to retrieve metadata and a modular component to structure our artist content.

Using modular components and remote sources, we can create dynamic and engaging artist content that's easy to maintain and update. With Hygraph's content federation features, we can pull in data from LastFM and add it to our content model in a way that makes sense and considers the overall content workflow of our business.

Requirements:

Hygraph account and a new project
Web browser of your choice
LastFM account (FREE)
Basic understanding of content modeling

Adding a remote source to your Hygraph project

To obtain a LastFM API key, login into your LastFM Account and navigate to the create API account form.

Obtaining a LastFM API key

Because we are logged into our account, the contact email will be pre-filled. Next, we will add an application name, feel free to choose any name you want and click to Submit the form. Once the form is submitted, you will get an API Key and Secret, save this information as we will use it to connect LastFM to Hygraph later on.

For now, let’s test our API to make sure that we are able to successfully retrieve artist data.

Getting a JSON response from LastFM REST API

The LastFM API documentation gives us the Root URL and methods available to make a request. The root or base URL is https://ws.audioscrobbler.com/2.0/ (Keep the base URL close by, we will need it later!) and we will use the artist.getinfo method to retrieve artist metadata in JSON format. If we build out our request URL, we get something like:https://ws.audioscrobbler.com/2.0/?method=artist.getinfo&artist=ADD_ARTIST_NAME&api_key=YOUR_API_KEY&format=json.

Replace ADD_ARTIST_NAME with an artist and YOUR_API_KEY with the API key you generated earlier.

Example URL: https://ws.audioscrobbler.com/2.0/?method=artist.getinfo&artist=prince&api_key=a1ddbd6d333dcc1af79a5123674adb0c&format=json

For example, if we search for the artist, Prince, with a valid API key in our web browser, we should get all information available about Prince.

Install a JSON validator extension for your web browser. This tutorial uses Google Chrome as a browser and the JSONVue extension. With our extension installed, we get lovely JSON that is organized and easier to read.

Back to our regularly scheduled programming…

Great work—We have a working API Key and are able to retrieve artist data in JSON format! From our JSON response, we are able to get a bio, stats, tags, and similar artists for Prince. Our next step is to get this data into the right shape to work with Hygraph’s GraphQL API.

Shaping LastFM JSON to work as a native GraphQL API SDL

A Schema Definition Language or SDL is a way to define the shape of data that can be queried in a GraphQL API. It describes the schema or types of data available, their relationships, and how the data can be queried. We need to tell Hygraph the shape of the data to expect and make available. To do that, we'll create custom types using an SDL to define the schema that will be available to us via the Hygraph API. To jumpstart the process, we can use a JSON to GraphQL tool that will take our LastFM JSON response and generate GraphQL type definitions for us.

# SDL for LastFM REST API

type Link {
  text: String
  rel: String
  href: String
}

type Links {
  link: Link
}

type Bio {
  published: String
  summary: String
  content: String
  links: Links
}

type Tag {
  name: String
  url: String
}

type Tags {
  tag: [Tag]
}

type Image {
  size: String
}

type Similar {
  artist: [Artist]
}

type Stats {
  listeners: String
  playcount: String
}

type Artist {
  name: String
  mbid: String
  url: String
  streamable: String
  ontour: String
  bio: Bio
  tags: Tags
  similar: Similar
  stats: Stats
  image: [Image]
}

type AutogeneratedMainType {
  artist: Artist
}

Using the SDL generator should output the custom type definitions above. Copy and paste your SDL into a code editor or IDE of your choice and let’s make a few small changes to these types. Sometimes when connecting to older REST APIs where naming conventions are not as strict, you can get special characters in type names. In the case of the Image type from LastFM, there is a #text value that is used for the URLs for images. This cannot be queried using GraphQL because #text will be stripped out as a comment. Remove text: String from Type Image. Last, instead of using AutogeneratedMainType we will use ArtistMeta as our Main Type name.

type ArtistMeta {
  artist: Artist
}

Connecting LastFM to Hygraph as a remote source

We have our SDL, now it's time to connect LastFM to Hygraph as a remote source. Login to Hygraph or create an account if you do not already have one. Once you are logged in, scroll down to “Add a new project”. We have the option to create a blank project or to use a starter template. For this project, we will start with a blank project, so click on the “Add project” square to get started.

Add HygraphFM or a name of your choice as the “Project name” and select the “Region” from the dropdown menu that is geographically close to you to host your content. Once complete, click the Add Project button and Hygraph will create a blank project for you.

When Hygraph finishes the setup process, we are taken to our project dashboard. On the left sidebar menu, select “Schema”, then click “Add” next to Remote Sources.

Display Name: LastFM API
Prefix: LastFmApi
Description: LastFM Rest API for artist metadata
Type: REST
Base URL: https://ws.audioscrobbler.com/2.0/

When you choose a remote source Type, new fields for the Base URL and Custom type definitions are revealed. Add the base URL from LastFM that we saved earlier.

Adding our Custom Type Definitions

Next, copy and paste the custom type definitions from our SDL into the Custom Type definition field. The top bar of the field conveniently gives us a summary of the types we pasted in.

When working with a large number of type definitions, it is helpful to check this summary against our original SDL file to make sure we got all of our definitions.

Click the “Add” button at the top right corner and Hygraph will add LastFM as a remote source to our project. Now that we have connected LastFM as a remote source to our project, we can start building our artist content model and a modular component to create a structure for artist content.

Building the artist content model

Instead of thinking about a specific presentation such as an app or website, it is important to think about your organization and business goals as a whole when building a content model.

A content model is a definition of your data stored in Hygraph, but never forget that it also represents the process your editors will use to create and enter content. Think of a content model as a way to provide universal clarity on a process, task, or data point for the entire business while also ensuring you get the right data types in the API. In our case, we want to create a profile that provides information and statistics for every artist on our music platform. However, what other business needs should be included in this model? Getting input from stakeholders such as content creators, marketers, designers, product managers or account executives from the start of the build process ensures that you are developing a tool that works for everyone. When we as developers work collaboratively to create content models, it decreases the time we spend putting out fires, frees up our capacity and creativity to develop new tools and features, and empowers our organization to make content changes as needed.

After talking with marketing, product, and sales we learn that we need to incorporate content sections for marketing campaigns, a banner that promotes new album releases, and a CTA to invite friends (aka new users) to the platform. With this new information in mind, we are now ready to build the artist content model in Hygraph. From the “Schema” menu item in our Hygraph project, select “Add” from the Models section.

From here, we give our model a Display name, Artist, and the API ID and Plural API ID autocomplete for us, and click the “Add Model” button. Once setup is finished, the Artist model will display and we get a list of fields that we can use to populate our model.

Single line text: Title field

The first field we need is a string field for the Artist Name, so we will use the Single line text field. For API ID, let’s use artist and check “Use as title field” option.

Slug field

Next, we will add a slug field to our artist model and we want it to generate the slug from our title in the options. In the Slug template field, add {artist} . This lets Hygraph know which field to use to generate our slug.

Asset: Image field

To go along with the data we are pulling in from LastFM, we want to include an image of the artist. Add the Asset Picker field and name it, Artist Image.

You may be wondering why we’re not pulling in images directly from our remote source. It can be really difficult to know when to automate or have manual control over fields, so it is important that we develop cross-functionally to understand the full context and purpose for content. In this case, our marketing team and artist management want the ability to curate images for artists. Sometimes, it makes more sense for your overall business goals or brands to have more control vs the ability to automate everything.

Rest: LastFM remote source field

Earlier, we connected LastFM as a remote source. Now we can add a Rest field to our artist model. Scroll down to the list of field types, and select “REST” and we will give this field a name, Hygraph's LastFM Remote Source Field and the API ID will auto-populate to hygraphLastFmRemoteSourceField.

Next, we choose LastFM API or the name you chose in the “Remote source” dropdown menu and GET for our “Method” and ArtistMeta for our “Return type”. This lets Hygraph know that we want to retrieve or GET information from our LastFM and we have selected the ArtistMeta type because we want to be able to access all the metadata that is available for every artist. Last, we need to append the rest of the request URL to the path. Starting with the method, copy the example URL we made earlier that contains your API key into the “Path” field. Your field should contain: ?method=artist.getinfo&artist={{doc.artist}}&api_key=a1ddbd6d333dcc1af79a5123674adb0c&format=json. Adding artist={{doc.artist}} instead of using Prince as the artist search parameter tells Hygraph that we want to make a request based on the Artist Name used in the title field of a content document.

We now have an artist model that contains title, slug, image, and LastFM remote source field. While our artist model looks great, we need to incorporate the content that marketing and sales requested.

Creating a modular component for the artist model

The marketing and sales teams have asked for an invite your friends/new users call to action and promotional space content sections within the artist model. The best way to do this is by creating components that we will be able to add to our model as a collection of components using the modular component field. We need to create Button, Call to Action or CTA, and Callout components to help our organization accomplish its business goals. Using components vs hardcoding promotional spaces allows marketing and sales to test various types of language without needing the development team to make changes. Also, modular components help us scale our model and code, giving us the ability to add additional components later when inevitable feature requests come in and put them into a system the content editors will already know and use.

Button

From the schema menu add a new component called Button and add a string field called Text and a slug field called URL. In the "Validations" tab of the slug field, check "Make a specific pattern" and choose URL from the dropdown menu.

Callout

Next, add a new component, Callout, with these fields:

Field	Name	Options
String	Title	Title
Basic	Button	Select Button component

Call to Action (CTA)

Last, add a new component, Call To Action with these fields:

Field	Name	Options
String	Heading	Localized
Rich text	Body	Localized
Asset	Image	Default
Basic	Button	Select Button component

The "Basic" component field type does not allow multiple component instances and we only want one button for each Callout or Call to Action. Thinking about the overall content strategy and model allows us to make field type choices that are helpful to editors. So, our finished component will contain a Heading, Body, Image, and a single Button.

Our components are all done, now let's add them to the model as a modular component. Return to your artist model, and select the “Modular” field.

Give your collection of components a name, let’s use Promotional Block , select “Allow multiple values” from the “Field Options”, and choose the components we created, Button, CTA, and Callout from the dropdown menu.

Our artist model is now complete with Artist Name, Slug, Image, Hygraph’s LastFM Remote Source, and Promotional Block fields and we are ready to enter content!

Create Artist Content

It’s time to add content, navigate back to the main menu on the left side of your project. Select “content” and click on the button, “Add entry”, located on the top right.

A document entry form will appear. All the fields that we added to our Artist model are located on the form and are ready for content. Take some time to make 4 or more content entries of music artists. (Note: Choose music artists that actually exist, so we can use LastFM to get metadata). The artist used in this tutorial are:

Radiohead
Wu-Tang Clan
A Tribe Called Quest
De La Soul

Feel free to play around and add your own or use the artists above.

Querying artist content in the API playground

The API playground built into your Hygraph project is a great place to test queries, mutations, and API calls. Before we wrap things up, let’s experiment in the playground to see the information we get from LastFM API calls based on the content we added.

As a quick overview of the content, we have the artist Wu-Tang Clan with a name, slug, an image of the group, and a Callout that prompts our users to invite friends to Hygraph FM. With this in mind, let’s head over to the playground and test a query. From the entry form, click on “Preview in Playground” in the Hygraph LastFM Remote Source Field. This will take us directly to the API playground and autocomplete our query variable id with the entry form ID of the Wu-Tang Clan content. Example: {"id":"cli23id9o08rq0blh643i40v7"} . Now let’s test a query to get metadata along with the content we entered manually. Enter the following query:

# Test query in Hygraph API playground

query WuContent($id: ID!) {
  values: artist(where: {id: $id}, stage: PUBLISHED) {
    hygraphLastFmRemoteSourceField {
      __typename
    }
    artist
    artistImage {
      artistImageArtist {
        slug
        id
        promotionalBlock {
          ... on Callout {
            id
            title
            button {
              text
              url
              id
            }
          }
        }
        hygraphLastFmRemoteSourceField {
          artist {
            bio {
              summary
            }
            tags {
              tag {
                name
              }
            }
            similar {
              artist {
                name
              }
            }
          }
        }
      }
    }
  }
}

In the above query, we are asking Hygraph to give us the artist name, slug, id, callout title with the button, and from LastFM, we want the bio summary, tags, and similar artist names.

All went well and our WuContent query returned data from LastFM! We now have a short bio, genre tags, and similar artists that we can use along with our own content to populate a front end of our choice.

Next Steps

To recap, we built a content model for artists on our music platform with a modular component and added Last FM as a remote source to retrieve metadata. In the next article in the series, we will connect a frontend to our Hygraph FM project using Next.js 13 to present our artist content and deploy it to Vercel.

Convert a Hygraph Next.js project to Next.js app directory

Bryan Robinson — Mon, 11 Sep 2023 04:00:00 +0000

In late 2022, the Next.js team launched their next stable version: Next.js 13. While this update came with a lot of improved functionality, one new feature is set to redefine the way you build with Next: the app directory beta.

The app beta is not used default. It needs to be enabled and can then be incrementally adopted. In this article, we're going to take a look at the new app structure and convert an existing Hygraph project to this new structure. We'll take this step by step and see how incremental adoption really works.

Required Knowledge

A basic understanding of Next.js
Basic knowledge of GraphQL
Basic knowledge of Hygraph

Why the app structure?

The new app directory structure isn’t just a reorganization of your project (though it is, and that reorganization feels powerful). This new methodology utilizes React Server Components to bring many new features and mental models. With Server components, a developer can do their business logic in a React component that doesn’t need to be sent to the client. This allows for a lot less JavaScript to be sent to the browser. If you have frontend needs, you can then use client components that get sent individually to the browser. This should reduce your bundle size down to a more manageable state. Just the code you need for interactivity.

The overall data fetching model has shifted, as well. Next has extended the native fetch() method from Node and the browser APIs and has added additional caching and deduplication functionality. This means you can create requests for data in various files, but the request will only fire to your API once. Fetching your blog posts to create a list on your homepage and to create the blog page list? Now that’s 1 API request, despite writing the code in multiple places. This gives a lot of developer convenience while creating better build and serve times.

There are even more new and improved features, but to use them, we need to be able to upgrade our project to use this new structure. It’s not as simple as moving your page files into the app directory, so let’s dig in and get things updated.

Setting up a Next.js 13 project to work with the app directory

To start, we need a Next.js project. While this process is possible with any Next project using data fetching, let’s start from our simple Next example from the hygraph-examples GitHub repository. Run the following commands:

npx degit hygraph/hygraph-examples/with-nextjs with-nextjs
cd with-nextjs

Before we install, we’ll need to update some dependencies in the package.json file. Let’s upgrade Next to ^13.0.0 and remove the react and react-doc dependencies.

Your package.json should now look like this:

{
  "name": "hygraph-with-nextjs",
  "private": true,
  "license": "MIT",
  "scripts": {
    "dev": "next",
    "build": "next build",
    "start": "next start"
  },
  "dependencies": {
    "graphql-request": "^1.8.2",
    "next": "^13.0.0"
  }
}

Now we can start the development server by running npm run dev. Immediately on loading the local version, we’re presented with the first update. Since this was previously not running Next 13, the Link component is structured wrong. In Next 13, we no longer need to have an anchor tag inside the Link component. This is a great update, but we need to change these references. The only location the Link component is used is the homepage in /src/pages/index.js. Open that file, and remove the <a></a> tags to get the site to run

// Old
    <Link key={slug} href={`/products/${slug}`}>
      <a>{name}</a>
    </Link>

// New
    <Link key={slug} href={`/products/${slug}`}>
       {name}
    </Link>

Now that the site runs, let’s update from the Pages directory to the new app directory.

Converting from /pages to /app

Before we can convert to the app directory, we need to let Next know that we’ll be using this experimental feature. To do that, we need a configuration file. In the root of our project, let’s create a next.config.js file. Inside that file, add the following basic configuration.

/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    appDir: true,
  },
};

module.exports = nextConfig;

From there, we can create our app directory. Inside the src directory, add an app directory. We’ll be moving each of our routes to this directory. The nice thing is that each of our older routes will continue to work as we make these changes, since both directories can work at the same time.

Creating the root layout component

One of the first big changes to the overall structure is the need of a “root layout.” This will be the scaffolding of Markup for all pages. This can start very simply, but have any global information that each route will need. The RootLayout function accepts a children object. That children object will contain the Server Components that we’ll add via each page we create.

export default function RootLayout({children}) {
    return (
      <html lang="en">
        <body>
            { children }
        </body>
        </html>
    )
}

With this layout, we can now add our first page.

Adding the homepage

Instead of the index.js convention of the /pages directory, each page in the app directory will be named page.js. In the root of the app directory, create a new page.js file. This will be our homepage.

Once you create this page, Next will thrown an error in the console. There is now a conflicting route: /src/pages/index.js is the same route as /src/app/page.jsx. For now, rename /src/pages/index.js to oldIndex.js. We’ll delete this file later, but this file is the blueprint for our new file.

Once we rename the file, we get a new error. The page.jsx file is not exporting a React component. In fact, it’s exporting anything, since it’s blank. Let’s fix that and export a simple React component with an h1 of Products.

export default async function Page () {
    return (
        <>
            <h1>Products</h1>
        </>
    )
}

Now the homepage should have the H1 instead of the product list from the old homepage. Let’s get the list of products back.

In the old index file, we export a function called getStaticProps to get and pass the data to our page component. In the new structure, we don’t need to export anything or name things in any specific ways. Instead, we can create a regular async function to fetch our data.

Before our Server Component in the new page.jsx file, create a new async function named getProducts. This run a fetch request to the Hygraph endpoint for the project and return the products array. We can then run that function in our Server Component to loop through the data and display a link to each page.

import Link from 'next/link';
const getProducts = async () => {
    const response = await fetch('https://api-eu-central-1.hygraph.com/v2/ck8sn5tnf01gc01z89dbc7s0o/master', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'Accept': 'application/json',
        },
        body: JSON.stringify({
            query: `{
                products {
                  slug
                  name
                  id
                }
              }`
        })

    })

    const {data} = await response.json()

    return data.products
}

export default async function Page () {
    const products = await getProducts()

    return (
        <>
            <h1>Products</h1>
            <ul>
                {products.map(product => (
                    <li key={product.id}>
                        <Link href={`/products/${product.slug}`}>{product.name}</Link>
                    </li>
                ))}
            </ul>
        </>
    )
}

A few things have changed between our old version and new.

Since we’re not using getStaticProps, we no longer need to structure our return in a specific way. Instead, we just return back the array of products
Using fetch instead of GraphQLRequest. By using fetch, we allow Next to cache the information and if we execute an identical fetch later, it won’t make a separate call, but instead use this data

Once you save this in, we have a functioning homepage. These links even take us to the pages associated with our old dynamic routes — since /app and /pages can work incrementally. That could be a fine stopping point, but let’s convert our dynamic route over, as well.

Converting the dynamic products route

Just like the homepage, we’ll start by setting up our structure. Instead of the dynamic route brackets happening on the file, hey happen on the directory. So the /pages/products[slug].js will change to be /app/products/[slug]/page.jsx. This allows for more flexibility and the ability to add custom, co-located features such as error pages, loading pages, and custom layouts.

Create the new file and add a simple component like we did for the homepage.

export default async function Page() {

    return (
        <>
            <h1>This is a product</h1>
        </>
    )
}

This time, the application won’t immediately error, since the static pages aren’t being rebuilt, but if you restart Next, it will throw the same error as before about conflicting files. Delete or rename the file and we’ll move forward.

The overall structure of this file is significantly different. Just like the homepage, we no longer need the getStaticProps function, but we also don’t need the getStaticPaths either. These are all files that render on the server, so we can move all that information into a single async function that can happen at request time.

The new Server Component gives us a params object that we can use to get the slug for the current route. We can pass that into a new getProduct() function and use that as a variable in our query to Hygraph. This will fetch the data for that specific product. We can then use that in the Markup generated by our component to display the title, description, and price.

async function getProduct(params) {
    const response = await fetch('https://api-eu-central-1.hygraph.com/v2/ck8sn5tnf01gc01z89dbc7s0o/master', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'Accept': 'application/json',
        },
        body: JSON.stringify({
            query: `{
                product(where: {slug: "${params.slug}"}) {
                    name
                    description
                    price
                }
            }`,
            variables: {
                slug: params.slug
            }
        })
    })
    const {data} = await response.json()
    return data.product
}


export default async function Page({params}) {
    const product = await getProduct(params)

    return (
        <>
            <h1>{product.name}</h1>
            <p>{product.description}</p>
            <p>{product.price}</p>
        </>
    )
}

We now have all the pages working together. Let’s take this one step further and add a custom 404 page for any products that aren’t found.

Setting up a custom 404 page

Because of the new app structure, we can colocate all of our relative files. In this case, if we want a custom 404 page, we can add a not-found.jsx template in the /products/[slug] directory.

The file will export a Server (or client) component, and for now, we’ll have a very simple message. In this case, since we’re looking for a product, let’s be specific and say “Product not found” instead of a simple “Page not found.”

export default function NotFound() {

    return (
        <>
            <h1>404</h1>
            <p>Product not found</p>
        </>
    )
}

Now, navigate to a route that doesn’t match any slug in Hygraph: try http://localhost:3000/products/sdlfkjl/

Instead of getting a 404 page, we receive an unhandled error. That’s because we need to tell Next when we know it’s not found. In this case, if our query to Hygraph returns no results, we need to throw a 404.

After calling the getProduct() function, we can check if product is defined and if not, run the notFound() function from next/navigation. This will do a few things for us. It will redirect the browser to the NotFound component and automatically add a "noindex" meta tag to these routes. This is good SEO practice and will keep your site’s 404 pages from being indexed by search engines.

export default async function Page({params}) {
    const product = await getProduct(params)

    if (!product) notFound()

    return (
        <>
            <h1>{product.name}</h1>
            <p>{product.description}</p>
            <p>{product.price}</p>
        </>
    )
}

Now, we have a fully-functioning 404 page!

From here, you can delete the /pages directory and move to working on your app. You’ll still use the pages directory for your API routes, as well as any static routes you want to use, but most things can be used to this new, more-powerful version of Next.

Next steps

With that, we have fully converted our simple Hygraph Next.js example from /pages to /app. At this point, I’d suggest taking look at all the different file types you can create in the colocated directories.

Add a head.jsx file to specify meta data such as title, description, and more for each product page
Add a loading.jsx file for loading page for longer queries.
Add an error.jsx file to handle other error types.

Boost your editorial experience with distributed content management

Bryan Robinson — Thu, 07 Sep 2023 18:09:56 +0000

Tools are only good if users want to use them. If your writers and editors don’t want to use a tool, your content velocity will halt, and your business will suffer.

While it’s easy to dictate a monolithic approach to building your CMS strategy, managing a diverse team with diverse needs in their content generation processes is not always easy. Rarely will one data entry process be the correct one for all those individuals.

It's important to note that while allowing your writers and editors to choose their tools can increase content velocity, it's also important to maintain some standardization of data structures and APIs. Without that standardization, your developer velocity will suffer.

What is distributed content management?

Distributed content management is a pattern where your content is spread amongst the systems that work with that content type the best. Your marketing copy lives in a headless CMS; your product information in your PIM; your inventory in your WMS; your customers in your CRM. Each system handles its own data type better than a monolithic approach could.

Each data type also has its own specific group of editors. These editors are most comfortable in the systems they’re trained to deal with. Forcing an eCommerce expert into a headless CMS or a marketing expert into a PIM just for the sake of having a singular tool doesn’t make sense and will often stifle the teams needed to continue refining and producing content.

The distributed CMS pattern means each editor type can use the system that works best for their data. The data is then all brought together via a federation pattern — here at Hygraph, we’re believers in Content Federation, but any data combination pattern will work depending on your needs.

Why should you care about content velocity?

Among many teams, content reigns supreme. Strong content published regularly is crucial for long-tail leads, thought leadership, and brand growth.

Regularly creating fresh, new content can help keep your audience engaged and growing. While a single strong piece of content can provide high value, each new content piece is a chance to find a bigger, more engaged audience.

Creating a steady stream of new content pieces also allows for a stronger sense of experimentation. In the realm of content, what works one week may not work the next. Trying new perspectives, content types, and tones is important. Experimentation increases the chance of hitting the right tone and perspective to generate high engagement. Not every piece will succeed, which is why it’s so important to be able to create and experiment at a high velocity.

The importance of content standardization

Content velocity might increase, but there are potential pitfalls to a distributed CMS approach that centers on the idea of standardization.

Unified Content Strategy

When you lose a centralized tool, it’s easy to let strategic concerns slip in favor of “getting the work done.” Any content plan needs a solid strategy as its base. While that can be covered up by a strong centralized tool, holes in internal workflows and strategies become more apparent when decentralized.

When crafting a decentralized solution, it’s important to start with a set of standards for how all aspects will be crafted. This goes from things like tags on blog posts and articles to how products are referenced. A strong plan for this content will align everyone in your organization around how these elements should be written, edited, and used regardless of the system they use. A strong plan will also help create a stronger sense of technological standardization.

Technological standardization

While allowing your writers and editors to choose their tools is important, it's equally important to maintain some standardization in your data structures and APIs. This will ensure that your developer velocity doesn't suffer and that your content can be easily integrated into your CMS.

Given three content teams with three separate CMSs, chances are good that your development team will struggle with creating consistent, efficient, and performant applications and sites. Each CMS brings its own data structures, its own API endpoints, and its own content strategy. Those can’t be standardized in their individual applications; a central system must standardize them. Without a standardization mechanism, site and application development will be more prone to bugs, developer frustrations, and blockers.

How a distributed system can help with standards

Each system may be separate, but each can help enforce the standards of the others.

For example, Dr. Oetker, a global food and beverage wholesaler, has multiple systems that need to converge to make their various localized websites, customer data needs, product information, and recipe database.

While all of these systems could theoretically exist within one massive, monolithic structure, each system is better at maintaining the individual standards of its own content than could happen in a singular system.

Dr. Oetker’s product information lives within their PIM. The PIM provides product data for the recipe database and editorial CMS. Customer data is housed in Force.com. Page data and content structure are built in Hygraph, where editors also work. All this is bundled and built with Next.js for 40 localized websites.

A recipe editor won’t be editing the product information. Since that lives in the PIM, it’s completely safe and standardized. Same for building editorial content or pages. All the product information is usable and standardized without having to worry about the individual teams knowing exactly the right information.

We leave room for error or interpretation if we depend on an overall strategy and the humans implementing them in separate systems. However, if the information is pulled directly from the PIM or WMS systems for use in the others, then the standards set by the PIM or WMS team are automatically enforced for all other teams.

Reduced training time and costs

When you dictate the tools that your writers and editors use, you must provide training and support for those tools. This can be time-consuming and expensive, especially if you have a large team. Instead, if you work with your teams and allow them to collaborate and help craft the editing experience, including the tools, you can gain buy-in and drastically reduce training time and costs. When drafting a content architecture and strategy, involving your editors as early as possible can help save on inconsistencies later.

Since your team is already familiar with those tools, they won't require as much training, and you won't need to spend as much on support. This can free up more time and resources for other critical tasks, such as content strategy and distribution.

Setting up a distributed CMS

While a multi-CMS approach may feel like it adds a lot of overhead or orchestration, it’s possible to set this up in a real-world approach with relatively little effort.

In the past, this would have required custom orchestration layers. Whether those were hosted middleware functions, content hub approaches, or an incredibly bloated frontend, it often felt insurmountable. We can easily overcome these deficiencies with recent improvements in the federation world. While tools like Apollo made the development of orchestration layers easier, concepts like Content Federation allow for ease of use for developers and non-technical users to create orchestration layers.

With Content Federation, we can craft a system where multiple data sources come together in a low-code or no-code system and allow for data to be remixed in various ways.

An eCommerce experience

Let's look at an eCommerce store as an example of real-world distributed content management. To create an eCommerce experience, we need product information, blog posts, page content, user reviews, and more. No single CMS provides the ideal solution for all these types of data.

Product information is often best housed in your product information management (PIM) solution — Shopify, BigCommerce, Magento, etc. These PIMs are great for eCommerce data but are notoriously bad for marketing content and are often not fully featured enough for complex inventory management, where a warehouse management solution (WMS) would be a better tool.

When crafting marketing pages, you’ll want a CMS with a solid foundation of both data and content and the ability to combine those in some form of page-building system. We may be biased, but Hygraph is a great solution here.

Finally, your content team may already have a blog in a system like WordPress. Say what you will about WordPress, but it’s still a solid blogging experience. Its page-building experience is weak, as is its PIM experience.

Each of these platforms offers specific perks and deficiencies. Combining all of them together can create a great experience for all editors involved. Let’s make sure it’s also a great experience for developers by combining all of the necessary data into one API.

Using Hygraph’s Remote Sources functionality, we can pull all the data from our PIM for product details, inventory levels from our WMS, and all the blog posts from WordPress and combine them with marketing data and campaigns stored in Hygraph to create a full API of all the data needed to build experiences across multiple channels.

On top of that, any data can be augmented and constructed in new ways. Products can be added to campaign pages. Specific reviews and blog posts can be built into the homepage (and changed by editors). All of this is unlocked when you use a CMS as your middleware.

Recommended Reading
Case study: Biocentury uses Content Federation to bring live data points

Conclusion

Content velocity, content experimentation, standardized data, and flexible site building are cornerstones to crafting a strong brand image and a strong business. If any one of those pillars is weak, the entire system can crumble. You can gain standardized data by forcing your team into a monolithic approach, but content velocity and experimentation will suffer.

By allowing your team to work in the space they’re most comfortable or where the data is best served, you open up a higher level of velocity and experimentation. With the advent of Content Federation, you don’t suffer from bad data or problematic site-building. One standardized API from customized, efficient, flexible sources.

Data binding in Svelte

Scott Spence — Fri, 21 May 2021 15:28:48 +0000

Over the last few weeks, I have been getting familiar with Svelte and SvelteKit in particular. Coming from a React background there are many similarities using Svelte and some that are not.

One thing that came up when using Svelte was passing values from a child to parent component and how that worked. I'm not going to go into detail on Svelte in particular, more some patterns to use.

As with many things in programming, there are several ways to do any one thing, in this post I'll go over some of the approaches I have used and when to use them.

I've created examples of these in the Svelte REPL so you can have a play around with them to familiarise yourself with them. I'd also recommend checking out the Svelte documentation; it's an awesome source of information.

First up, it might be important to talk about props (short for properties) and how they are passed between components.

Passing props down to a child

So here's a super simple App.svelte (parent) that is importing the child component and passing a value, (in this case) propValue down to a <Child /> component:

<!-- App.svelte -->
<script>
  import Child from './Child.svelte'
</script>

<Child propValue="Pass this to the child!" />

Much the same way as you would want to define a variable in React if the variable is scoped to the component then it's defined there.

Svelte is a superset of HTML with the .svelte extension so whereas in React a prop would be brought in as a parameter in the case of Svelte it's defined in script tags and exported. This means that the variable can be wrapped in some curly boys {} in the markup (HTML) so it can be interpreted and read out by JavaScript.

<!-- Child.svelte -->
<script>
  export let propValue
</script>

<p>I'm taking this from the parent: {propValue}</p>

But what's this export? I struggled with this initially, ultimately it's a way to make propValue available to the parent. If you think that's weird, just wait until I detail reactive declarations! More on that soon.

Passing props back to a parent

As a general rule data flow goes from the parent to the child but what if you want to pass a value back from the child to the parent?

Using `bind:value`

In Svelte using the bind:value directive (command) to, a'hem bind the value of the text input to a variable value, this is the shortest example:

<!-- Input.svelte -->
<script>
  let value = ''
</script>

<input bind:value />

<p>{value}!</p>

Although value isn't a great variable name so it can be changed further:

<!-- Input.svelte -->
<script>
  let descriptiveVariableName = ''
</script>

<input bind:value="{descriptiveVariableName}" />

<p>{descriptiveVariableName}</p>

There's a drawback with doing it this way which I'll come onto in a bit. For now, I have the data bound to that input, and changing the text will update the p tag with what is added to the text input.

Ok, now I'm treating that input as its own component so, say I want to access the input value from a parent? "How to pass the bound value back up to the parent?" I'm going to go back to the previous example with the less descriptive variable name now and remove the p tag as I want to display the value in the parent, I'm also going to rename it from Input.svelte to Child.svelte:

<!-- Child.svelte -->
<script>
  export let value = ''
</script>

<input bind:value />

I can now access the bound value of Child.svelte by defining a variable in the parent (App.svelte) component, inputValue in this case and pass that to the child:

<!-- App.svelte -->
<script>
  import Child from './Child.svelte'
  let inputValue = ''
</script>

<Child bind:value="{inputValue}" />

<p>Input value is: {inputValue}</p>

I'm adding inputValue to a p tag on the parent now to get that value. Changing the input in the parent now updates the inputValue wrapped in the p tag in the parent.

So I'm updating the Child component on the parent and getting that value back in the inputValue variable.

Now, I'm going to go back to the input example with the descriptive variable and try the same:

<!-- Child.svelte -->
<script>
  export let descriptiveVariableName = ''
</script>

<input bind:value="{descriptiveVariableName}" />

Now changing the value in the parent doesn't seem to trigger any changes, but if I add a <p> tag to the child and make some changes I can see that the changes are going from the parent to the child but aren't coming back to the parent:

<!-- Child.svelte -->
<script>
  export let descriptiveVariableName = ''
</script>

<input bind:value="{descriptiveVariableName}" />

<p>Child received props: {descriptiveVariableName}</p>

In summary, you can pass down named props to components but if you want to pass the props back up to the parent then you'll need to use bind:value alone. Something to keep in mind when taking this approach.

Using a callback

This approach will be familiar if you are used to doing this in React with adding a callback function. Here an onChange is defined in the Child for the parent to use:

<!-- Child.svelte -->
<script>
  export let onChange
  let value = ''
  $: onChange(value)
</script>

<input type="text" bind:value />

Wait! What's that $ doing there? That's a reactive declaration which I touched on earlier but didn't give any explanation. This is how Svelte can keep track of a component's state change, so whenever value is changed it updates onChange.

In the parent I can use the onChange from the child to update the parent:

<!-- App.svelte -->
<script>
  import Child from './Child.svelte'
  let inputBoxValue = ''
</script>

<Child onChange={newValue => inputBoxValue = newValue} />

<p>Input box value is: {inputBoxValue}</p>

This doesn't have to be bound to the value of an input though; another way to achieve this could be to do some validation on the input on:blur so that when the user comes out of the input some validation can happen.

<!-- Child.svelte -->
<script>
  export let value = ''
  export let onBlur
</script>

<input bind:value on:blur="{onBlur}" />

So as mentioned previously, with onBlur (or whatever you want to call this function) this can trigger a function in the parent. I've added a parentValidation function to be triggered in this example:

<!-- App.svelte -->
<script>
  import Child from './Child.svelte'
  let inputBoxValue = ''
  const parentValidation = () => {
    // validation here
    alert(inputBoxValue)
  }
</script>

<Child bind:value="{inputBoxValue}" onBlur="{parentValidation}" />

<p>Input box value is: {inputBoxValue}</p>

Event forwarding / dispatching an action

Last up is the event forwarding in Svelte because Svelte doesn't use a virtual DOM like Vue and React component events don't bubble.

In this instance, I'm using the createEventDispatcher from Svelte to create a dispatch function for use in the child component and giving it the label child-blur and passing the input value back with the dispatcher.

<!-- Child.svelte -->
<script>
  import { createEventDispatcher } from 'svelte'
  const dispatch = createEventDispatcher()
  export let value = ''
</script>

<input bind:value on:blur={dispatch("child-blur", value)} />

In the parent much like with doing it with a callback but now in place of the onBlur callback I'm using the on:child-blur event to trigger the parentValidation:

<!-- App.svelte -->
<script>
  import Child from './Child.svelte'
  let inputBoxValue = ''
  const parentValidation = ({ detail }) => {
    // validation here
    alert(detail)
  }
</script>

<Child bind:value="{inputBoxValue}" on:child-blur="{parentValidation}" />

<p>Input box value is: {inputBoxValue}</p>

I'd say as a project grows then this method will be the goto with a little boilerplate and a lot of flexibility.

Conclusion

As I said at the beginning, there are a few ways to do this, and depending on your use case there may be a need to use any of these approaches.

I hope you found it useful and that I helped identify some of the bumps you may come across when doing this for yourself.

Resources

I've added all the example code here to the [Svelte.dev] [REPL] so you can play around with them if you're so inclined:

Hasura Fit: Setting up Hasura

Jesse Martin — Thu, 13 Aug 2020 17:16:08 +0000

In this step of our multi-part tutorial, we are going to configure Hasura as our application’s back-end. Hasura is an open-source, GraphQL flavored “back-end-as-a-service” which plays very well with GraphCMS given they both share the GraphQL underpinnings. The back-end-as-a-service simply means that we’ll get a thin UI sitting on top of our database and be offered some user-friendly features, such as taking advantage of Postgres’ hook system but with the convenience of a UI and some additional USPs from the BaaS provider.

Why Hasura?

Apart from the above-mentioned reason that Hasura has native support for GraphQL, Hasura also released a new feature called ‘remote joins’ which allows us to essentially federate our schemas without having to annotate the schemas. If you’re unfamiliar with the federation concept, it basically means that each “section” or “group of concerns” of our application would be split into multiple schemas. These schemas could be developed in isolation of each other since they are often maintained by different teams with a different set of concerns and stakeholders.

Typically, you’d need to provide some kind “decoration”, in GraphQL this is done with directives, to tell one schema when to look at another schema for the answers. In traditional database design, this would be identifying a foreign key when one table needs to look at another table.

In Hasura, we have the convenience of simply providing our API URL, and through the power of GraphQL’s introspection (the ability to understand everything an API makes available to us), the Hasura tooling lets us use a very convenient drop-down to identify which field needs to be connected to our schema. This will be covered a little more later.

Lastly, the reason we chose Hasura is that it has built-in support for authentication and user permissions, which will be important to this application since we have multiple users creating their own, private content.

Environment Variables in Heroku

To begin, we are going to use the newly released Hasura cloud to quickly set-up a new instance of Hasura. You could just as easily use their deployable solution on Heroku (our database will be hosted there, anyways) or any other server stack supported by them, but we’ll focus on the cloud version to keep things simple.

Create an account with Hasura Cloud.

Create the database on Heroku

You’ll need to authenticate (or create an account with Heroku first) after which the Hasura Cloud interface will do automated provisioning for you.

Once you create the project, the app will go through a number of installation steps (all automated) and then prompt you to launch the console (main application) of Hasura. When you launch the console, it will open in a new tab, return to the Hasura Cloud UI to add our environment variables.

Note various values available to you here.

We will need to create a few variables for this project:

GRAPHCMS_FULL_ACCESS_TOKEN
This is our access token from GraphCMS which we defined in our GraphCMS API. Note, you’ll need to use the format Bearer <TOKEN_VALUE> since we use the full string as Hasura’s env values don’t allow us to use string interpolation.

HASURA_GRAPHQL_ADMIN_SECRET
For protecting our console (if we aren’t using Hasura Cloud) and also for protecting synchronizing function from Auth0.

HASURA_GRAPHQL_JWT_SECRET
Our application will use tokens from Auth0 to authorize our requests to Hasura. We need to configure Hasura to recognize Auth0’s JWT format. To do this, provide the following value as the environment variable:

{
  "type": "RS256",
  "jwk_url": "https://<YOUR_AUTH0_DOMAIN>/.well-known/jwks.json",
  "claims_format": "json"
}

Replacing <YOUR_AUTH0_DOMAIN> with your actual Auth0 application domain.
HASURA_GRAPHQL_UNAUTHORIZED_ROLE
Define this as “public” - which means that users who attempt to access our API without authentication will be assigned the “public” role, which we can assign specific privileges for in our database.

Creating the Content Model

The majority of our product or editorial content was modeled in GraphCMS. We’ll simply use two models (or tables) in Hasura. Our user table, which is populated from Auth0 plus an additional array relationship called sessions to a table also called sessions.

An array relation simply means that we are defining a one-to-many or many-to-many relation. If we were creating a many-to-one or a one-to-one this would be an object relation.

Users Table

Sessions Table

Adding Remote Schema

You’ll note in the session table above, we defined a workout “slug” - this will serve as our foreign key for GraphCMS when we define a remote schema relationship. Defining and federating a remote schema couldn’t be easier in Hasura. To enable our Remote schema, go to the “remote schema” tab at the top of the window, and add in the values, your settings should be similar to the attached graphic.

Note that for the Authorization header, we are using a value from our environment, our GRAPHCMS_FULL_ACCESS_TOKEN.

Define the Relationship

Return to the relationship tab of the sessions table. At the bottom of the tab window, there’s a section called “Remote Relationships.”

Name the field “workout” and choose the Remote Schema of GraphCMS (or whatever you labeled the remote schema in the previous step).

The trick here is that we are passing the value to the slug input argument of our where input type. The slug value is coming from the slug column of our session.

That’s it.

Creating a Web-hook

We use a webhook in the project to perform a sort of “pre-calculated aggregation” of the popularity of our workouts. This allows us to sort by popularity without needing to touch our user database if we were to distribute our GraphCMS API to another location that was un-aware of our Hasura project. In Hasura, these are called “Events”.

We define the trigger to occur when the table sessions receive a new insert and then we send a payload to the Web-hook URL defined.

The gotchas

There are some limitations to the remote schema joins for now. One of which is that you cannot use secure roles in the fields of a remote join. That is, you can’t extend the access controls from Hasura to the fields of GraphCMS. Hasura is working to enable this as is GraphCMS.

There are also some notable gotchas:

No exposed ID Type

Their ID scalar is not exposed by Hasura so we wouldn’t be able to use the direct ID of the workout entry from GraphCMS since meshing them would cause a type incompatibility error (even though both read as a text string.) That means we needed to create a slug entry in our GraphCMS model to support matching a foreign key from Hasura.

Required Fields

Because the input argument type where is required by GraphCMS for filtering by workout, we have to pass this value in as an empty argument when querying content, even though it is dynamically inserted at run-time. It’s less elegant than it could be, but a small price to pay for the amazing flexibility of adding a meshed-in third-party API.

Next Steps

That's it! You've made it to the end. Now you have all the pieces you need to create elegant, composed, distributed, and iterative APIs and services. Tweet out your success or check out GraphCMS for even more great resources.

Hasura Fit: Setting up Vercel

Jesse Martin — Thu, 13 Aug 2020 17:15:57 +0000

Why Vercel?

Vercel is an incredibly straight-forward hosting environment for our code. It provides a number of runtimes so that the most popular code can simply be uploaded to a Vercel project and it will run. Since our project is Javascript based, it will run just fine.

We’ll be using two separate Vercel projects for our tutorial primarily for educational purposes and as a separation of concerns.

First, we’ll be deploying our NextJs framework code to Vercel to run our primary web application.

Second, we’ll be running a very simple server function that acts as webhook for our Hasura project to update our content in GraphCMS later-on.

To begin, create an account with Vercel.

Environment Variables in Vercel

Assuming you have forked and cloned both the Hasura-Fit and the Hasura-Fit-Hooks repos locally, you’ll now need to add them to your own version control account (ie. Github). If you only cloned and didn’t fork, you can see how to change the URL here.

Once you have your code, pushed to version control, you can import those projects into Vercel from your account console.

After you have imported your project, you will have the ability to define your variables under the Settings / Environment Variables page. It’s possible your project might error on the first build since the environment variables are not yet defined. Don’t worry about that yet.

VERCEL_URL in this case is a system default variable that will be dynamically populated by the Vercel environment with a special URL that is either referring to a branch from your repo or the master branch.

The remainder of the variables can be copied from the NextJs variables, with production urls being used where needed.

Next: Set up Hasura

Hasura Fit: Setting up Serverless Functions

Jesse Martin — Thu, 13 Aug 2020 17:15:44 +0000

Why Vercel Serverless Functions?

There are many serverless providers out there. Many of them are incredibly easy to set-up. Because we are hosting our NextJs web app on Vercel (the same company that made the framework) - it makes sense to stay in the same ecosystem.

It’s also incredibly easy to set up. If you inspect the code involved, it really is a matter of defining the function you want to handle a serverless request, use the CLI to publish and you have a “micro-service” ready to go.

Environment Variables

The Vercel CLI for local testing does not support the .env.[environemnt] pattern defined in our Nextjs guide, so we’ll simply use a .env file, being sure to avoid checking this file into version control. Begin by copying the template with cp ./.env.template ./.env.

We’ll add:

GRAPHCMS_MUTATION_TOKEN
GRAPHCMS_API

Both of which we can find in the GraphCMS API Settings.

Server Functions

Our code for the webhook handler is rather succinct.

Essentially, we perform three actions:

We inspect incoming requests to ensure that we have a successful payload that includes the slug of a workout performed by a user from Hasura.
We fetch the popularity field of that workout from our GraphCMS API directly.
We mutate the GraphCMS workout model by incrementing the popularity field by one.

Again, all the code is provided in the repository.

const axios = require("axios");

module.exports = async (req, res) => {
  const ax = axios.create({
    baseURL: process.env.GRAPHCMS_API,
    timeout: 1000,
    headers: { Authorization: `Bearer ${process.env.GRAPHCMS_MUTATION_TOKEN}` },
  });

  let message;

  const { body } = req;

  if (body) {
    const {
      trigger,
      event: {
        data: {
          new: { slug },
        },
      },
    } = body;

    let {
      data: {
        data: {
          workout: { popularity },
        },
      },
    } = await ax.post("/master", {
      query: `query GetWorkout($slug: String) {
            workout(where: {
              slug: $slug
            }) {
                title
                id
                slug
                popularity
            }
          }`,
      variables: { slug },
    });

    let mutationResponse = await ax.post("/master", {
      query: `mutation IncWorkout($slug: String!, $popularity: Int) {
            updateWorkout(where: {slug: $slug}, data: {popularity: $popularity}) {
              id
              popularity
            }
            publishWorkout(where: {slug: $slug}, to: PUBLISHED) {
              id
            }
          }
          `,
      variables: { slug, popularity: popularity + 0 + 1 },
    });

    console.log(popularity);

    let {
      data: {
        data: {
          updateWorkout: { id },
        },
      },
    } = mutationResponse;

    message = `ID ${id} popularity is now ${popularity + 0 + 1}`;
  }

  res.status(200).send({ message });
};

Next: Set up Vercel

Hasura Fit: Setting up NextJs

Jesse Martin — Thu, 13 Aug 2020 17:15:35 +0000

Why NextJS?

NextJs is a powerful framework that lets us combine the best of server-side execution and static site generation. Out of the box we get server-rendered content, static resource compilation and API routes ensuring a protected execution environment.

Why that’s important for us is that we are able to handle our user authentication and Auth0 code in server-side routes where our Auth0 Client secret is protected from our app’s users, while still getting access to really fast pages loading content that doesn’t need to check the server first.

All of the code has been written already in this example repo, but we’ll look at the different parts of the framework to get a better understanding of how it works.

To begin with, you’ll need to provide your own application variables. We’ll be assuming that our code is deployed to Vercel as that is what this tutorial recommends, but the choice is up to you.

Environment Variables

First, start by creating a copy of the .env.local.template file and rename it to .env.local

cp ./env.local.template .env.local

Returning to the Auth0 console and navigate to your application, you’ll need:

AUTH0_CLIENT_SECRET
AUTH0_CLIENT_ID
AUTH0_DOMAIN

Additionally, you’ll need to define a random secret for the SESSION_COOKIE_SECRET as well as the SESSION_COOKIE_LIFETIME

Lastly, you’ll need to define HASURA_ADMIN_SECRET which will be used to protect your login if you choose not to use Hasura Cloud.

We define all of these values in a file called “.env.local” because we will define all of the values again in our Vercel admin panel for our project. NextJs supports naming files .env.[environment] as a pattern for mapping specific environment variables to those Node environments. It looks for these files out of the box. The .local prefix is a reminder for us to not push this file into source control (ie. Github).

Creating the Required Pages in Next

All of the needed pages for the demo exist already in the project repository, but for an explanation, we’ll describe them here.

lib/config

Our config file declares various export values for use throughout our application. Because we are using sever side and client side authentication, we need to define different variables for different contexts. Because we are hosting in Vercel, we need to handle some work-around behaviour to handle our preview URLs (branch deploys) vs our aliased production URL.

if (typeof window === "undefined") {
  /**
   * Settings exposed to the server.
   */

  const url = (production, branch, local) => {
    switch (process.env.NODE_ENV) {
      case "production":
        return production;
        break;
      case "preview":
        return branch;
        break;
      case "development":
        return local;
        break;
      default:
        return local;
        break;
    }
  };

  const base = url(
    "YOUR_LIVE_VERCEL_APP_ALIAS",
    `https://${process.env.VERCEL_URL}`,
    "http://localhost:3000"
  );

  module.exports = {
    AUTH0_CLIENT_ID: process.env.AUTH0_CLIENT_ID,
    AUTH0_CLIENT_SECRET: process.env.AUTH0_CLIENT_SECRET,
    AUTH0_SCOPE: "openid profile",
    AUTH0_DOMAIN: process.env.AUTH0_DOMAIN,
    REDIRECT_URI: base + "/api/callback",
    POST_LOGOUT_REDIRECT_URI: base,
    SESSION_COOKIE_SECRET: process.env.SESSION_COOKIE_SECRET,
    SESSION_COOKIE_LIFETIME: process.env.SESSION_COOKIE_LIFETIME,
  };
} else {
  /**
   * Settings exposed to the client.
   */
  module.exports = {
    AUTH0_CLIENT_ID: process.env.AUTH0_CLIENT_ID,
    AUTH0_SCOPE: "openid profile",
    AUTH0_DOMAIN: process.env.AUTH0_DOMAIN,
    REDIRECT_URI: `${window.location.origin}/api/callback`,
    POST_LOGOUT_REDIRECT_URI: window.location.origin,
  };
}

The URL helper function simply allows us to define which base-url will be used in the various Node environments such as preview, development and local.

Note how we don’t expose our AUTH0_CLIENT_SECRET in our client context, but only in the server? This is part of what makes a framework like NextJS so powerful is the ability to mix contexts like this.

lib/auth0

The auth0 file in our lib creates a new configuration object for the Auth0 SDK. It creates all the required configurations and methods we’ll need to work directly with Auth0, and then exports it for use in other files.

import { initAuth0 } from "@auth0/nextjs-auth0";
import config from "./config";
const auth0Instance = initAuth0({
  clientId: config.AUTH0_CLIENT_ID,
  clientSecret: config.AUTH0_CLIENT_SECRET,
  scope: config.AUTH0_SCOPE,
  domain: config.AUTH0_DOMAIN,
  redirectUri: config.REDIRECT_URI,
  audience: "YOUR_HEROKU_APP_URL",
  postLogoutRedirectUri: config.POST_LOGOUT_REDIRECT_URI,
  session: {
    cookieSecret: config.SESSION_COOKIE_SECRET,
    cookieLifetime: config.SESSION_COOKIE_LIFETIME,
    storeIdToken: true,
    storeRefreshToken: true,
    storeAccessToken: true,
  },
});

export default auth0Instance;

lib/user

This is highly specific React code and will be covered in the NextJs tutorial. The basic gist of this code is that it implements a React hook to check our /api/me route if the user is still logged-in, if they are, it returns our user data, if not, it redirects a user to a login path and additionally includes some helper state to determine if the browser is still checking for our logged-in status.

pages/api/login

Our login function takes a request to the route /api/login from our website, which then in turn uses our Auth0 lib to send all the client ID and secret information we need to Auth0 along with a secondary parameter called “redirectTo” which is the url that should be called from Auth0’s servers after we succeed or fail to log-in to the app.

import auth0 from "../../lib/auth0";

export default async function login(req, res) {
  try {
    await auth0.handleLogin(req, res, {
      redirectTo: req.headers.referer + "api/callback",
    });
  } catch (error) {
    console.error(error);
    res.status(error.status || 500).end(error.message);
  }
}

pages/api/callback

Our callback URL handles a request coming FROM Auth0, more specifically, this is a callback that is invoked when a user tries to signup. See the diagram below.

Our application tries to login, which sends us to Auth0, Auth0 uses a form from their server (in our case) which then sends us back to our callback url that we defined in our login request above. If we had a successful login, that request has tokens corresponding the scopes we requested and whether or not we want to use refresher tokens. Because there can be any number of tokens depending on our settings, the Auth0 library is able to simply take the request coming back from the Auth0 servers, identify which parts are important for our authentication, and save them where they need to go in our browser.

That code looks like this:

import auth0 from "../../lib/auth0";

export default async function callback(req, res) {
  try {
    await auth0.handleCallback(req, res, { redirectTo: "/" });
  } catch (error) {
    console.error(error);
    res.status(error.status || 500).end(error.message);
  }
}

pages/api/me

This route is perhaps the most opaque in terms of understanding the inner workings of the code, but the concept is straight forward. The SDK checks to see if the user still has a valid token to access data from Auth0, if not, it uses the refresh token to generate a new one.

import auth0 from "../../lib/auth0";

export default async function me(req, res) {
  try {
    await auth0.handleProfile(req, res);
  } catch (error) {
    console.error(error);
    res.status(error.status || 500).end(error.message);
  }
}

pages/api/logout

In a near mirror of our callback code, the Auth0 SDK takes a the request to logout and simply removes all the cookies for logging in and ensures no protected content is accessible anymore.

import auth0 from "../../lib/auth0";

export default async function logout(req, res) {
  try {
    await auth0.handleLogout(req, res);
  } catch (error) {
    console.error(error);
    res.status(error.status || 500).end(error.message);
  }
}

We won’t bother outlining the remaining files in NextJs here as they pertain to the presentational layer and edge of out of the scope of this tutorial.

Generally speaking, the actual rendered pages will include a function that follows a similar pattern as the following code snippet.

export async function getServerSideProps({ req, res }) {
  // Here you can check authentication status directly before rendering the page,
  // however the page would be a serverless function, which is more expensive and
  // slower than a static page with client side authentication
  const session = await auth0.getSession(req);

  if (!session || !session.user) {
    res.writeHead(302, {
      Location: "/api/login",
    });
    res.end();
    return;
  }

  const resp = await fetch("https://hasura-fit.herokuapp.com/v1/graphql", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${session.accessToken}`,
    },
    body: JSON.stringify({
      query: `{
            sessions {
              created_at
              workout(stage: PUBLISHED, where: {}) {
                title
              }
            }
          }
          `,
    }),
  });

  const { data } = await resp.json();
  return { props: { sessions: data.sessions, user: session.user } };
}

The specific function here getServerSideProps allows us to guarantee a server-side execution which means privileged access. That’s why we are able to use our authorization header here in the same file as our rendered page because we know this part of the code only runs on the server. This is one of the hidden powers of NextJs.

In the above code, our server will look for a valid session rookie, if it doesn’t find one, it will return us to the login page, otherwise, it will execute a request with our auth token that originally came from Auth0 and is intended for use at Hasura. It will read all the data about my user’s workout session activity, and then, through the remotely joined schema, Hasura will also look up the workout data itself (the title) directly from GraphCMS but resolve it to us in one unified server.

One last “complex” query that deserves a special mention is the following code:

fragment Rep on RepMovement {
  title
  repetition
}

fragment Amrap on AmrapMovement {
  title
}

fragment Duration on DurationMovement {
  title
  duration
}

fragment Circuit on Circuit {
  repetitions
  movements {
    ... on RepMovement {
      ...Rep
    }
    ... on AmrapMovement {
      ...Amrap
    }
    ... on DurationMovement {
      ...Duration
    }
  }
}

query Premium($authed: Boolean!) {
  workouts(orderBy: popularity_DESC) {
    title
    description
    popularity
    slug
    image {
      url
    }
    warmup @include(if: $authed) {
      ... on RepMovement {
        ...Rep
      }
      ... on AmrapMovement {
        ...Amrap
      }
      ... on DurationMovement {
        ...Duration
      }
    }
    program @include(if: $authed) {
      ... on RepMovement {
        ...Rep
      }
      ... on AmrapMovement {
        ...Amrap
      }
      ... on DurationMovement {
        ...Duration
      }
      ... on Circuit {
        ...Circuit
      }
    }
    coolDown @include(if: $authed) {
      ... on RepMovement {
        ...Rep
      }
      ... on AmrapMovement {
        ...Amrap
      }
      ... on DurationMovement {
        ...Duration
      }
    }
  }
}

This code requests the content for our homepage. In this complex query we define re-usable pieces of query (fragments) to be used in multiple locations of our query body. We also pass in a variable called “authed” which has come from a check to see if the user has a valid session. If it does, it includes the workout data, if it doesn’t, it get’s skipped according to the rule defined in the @include directive’s if argument. This way a user can see the title and basic information about a workout program, but not the full “product” data in this case.

Next: Set up the Serverless Functions

Hasura Fit: Setting up the Auth Flow

Jesse Martin — Thu, 13 Aug 2020 17:15:29 +0000

Special thanks to Sam Bellen for helping me troubleshoot some tricky parts of the Auth0 ecosystem.

In this part of our tutorial, we’ll be adding the authentication layer to our web app which lets us leverage the power of Auth0 and their social sign-on ecosystem of tooling to let us, onboard users, quickly and easily.

A core tenant of modern web application architecture is “do not write your own authentication” - basically, it’s a problem that’s easy enough to get wrong and also easy enough to make you think you got it right. Find either an open-source platform where hundreds of developers contribute to the robustness of the code-base or a SaaS company for essentially the same reasons but when you need an SLA or a few convenience features behind it.

Prior Art:

https://hasura.io/docs/1.0/graphql/manual/guides/integrations/auth0-jwt.html
https://github.com/auth0/nextjs-auth0

Why Auth0?

Auth0 has been one of the mainstay players in the authentication space for a while, they support nearly every type of “single sign-on” - which just means re-using an account from something like your workplace or Facebook - and they have excellent developer tooling to help us integrate with our stack. They handle password resets/forgets, generating custom scope in our Auth tokens (we’ll cover this in a few moments) and more.

If you need an enterprise-grade Auth library (or a generous free tier with reasonable pricing for your side projects) - Auth0 is a great solution.

Creating an Account

The first thing you need to do is create an account with Auth0, after that, you need to create an Application. From the applications tab of your project, you can click on “Create Application”.

Note: It’s critical you choose “Regular Web Application” as we’ll be working with server-side authorization and the library we are using expects “Authorization Code

Understanding the different types of authentication flows

Choosing SPA would result in a PKCE flow, which returns a shape of data our library isn’t expecting and is also not needed since we are authorizing server side. PKCE simply adds an additional layer of indirection before the exchange of tokens occurs.

Account Settings

The “variables” will differ for production context, but all things held constant, your localhost will stay the same.

We only need to handle the settings for Allowed Callback URLs (where we return to after authentication) and the allowed Logout URLs (where we return to after logging out.)

Web origins is only for contexts where the Sign-On form is EMBEDDED in the application and by default, all our allowed URLs are included in CORS.

Allowed CallbackURL.
Localhost: http://localhost:3000/api/callback.
Vercel: https://gcms-hasura-fit-\*.vercel.app/api/callback.

Using an asterisk (*) in the URL is known as a wildcard and this allows you to match all urls that match the first-half before the asterisk and the last half after the asterisk and anything in the middle. This is done so that if you want to use continuous deployment (where you get a deploy every time you push code to a code repository like Github) you’ll get previews in both your master branch and any other branches where you might test out new features.

Allowed Logout URLs.
Localhost: http://localhost:3000.
Vercel: https://gcms-hasura-fit-\*.vercel.app.

Understanding our Auth Config

In our NextJS project we have abstracted the authentication service as a library under our /lib directory where we can call our auth service from multiple places in our application. To communicate with Auth0 - we will use their SDK (software development kit) to send requests to Auth0 in the correct shape.

The init method looks like this:

const auth0Instance = initAuth0({
  clientId: config.AUTH0_CLIENT_ID,
  clientSecret: config.AUTH0_CLIENT_SECRET,
  scope: config.AUTH0_SCOPE,
  domain: config.AUTH0_DOMAIN,
  redirectUri: config.REDIRECT_URI,
  audience: "https://hasura-fit.herokuapp.com",
  postLogoutRedirectUri: config.POST_LOGOUT_REDIRECT_URI,
  session: {
    cookieSecret: config.SESSION_COOKIE_SECRET,
    cookieLifetime: config.SESSION_COOKIE_LIFETIME,
    storeIdToken: true,
    storeRefreshToken: true,
    storeAccessToken: true,
  },
});

Client Secrets and IDs

Auth0 is a hosted application (SaaS) which has many different projects in their database. To tell Auth0 which one is yours, you need to use the ID and the Secret they gave you in your signup process to properly identify which project in their servers is yours.

Scopes

In our application, when we call our login service, we need to tell our Authorization service (Auth0) what kind of permissions the holder of the returned token should have. In our case - we are asking for the profile and opened information about the user. Different services around the web might have other scopes such as “reading e-mails” or “updating calendar” - it’s common for services to restrict the permissions available to the token key they give you based on these scopes you are asking for.

Audience

Because we will be using the access token provided to access a DIFFERENT service (our hosted Heroku app) we need to tell Auth0 that the token we are asking for will be used at a different site.

Redirects

See the information above about the redirect URLs.

Session

The session configuration allows us to define which tokens should be saved in the browser, if at all, when it should expire and a secret key to encrypt the data.

Custom Rules

Auth0 allows specific rules (or functions) to be executed when certain things happen in Auth0. We need to create a special function for when we send a token to our web app and we need to create a special rule for creating a copy of our Auth0 user in our Hasura database.

Modify Token: hasura-jwt-claim

To modify the token we send to our client which will in turn be used to access Hasura, we’ll use the following rule

    function (user, context, callback) {
      const namespace = "https://hasura.io/jwt/claims";
      context.idToken[namespace] =
        {
          'x-hasura-default-role': 'user',
          // do some custom logic to decide allowed roles
          'x-hasura-allowed-roles': ['user'],
          'x-hasura-user-id': user.user_id
        };
      callback(null, user, context);
    }

Synchronize Users: insert-user

To synchronize our users, we’ll need an additional rule which creates a mutation in Hasura every time a new user signs up.

    function (user, context, callback) {
      const userId = user.user_id;
      const hasuraAdminSecret = "xxxx";
      const url = "YOUR_HASURA_ENDPOINT";
      const upsertUserQuery = `
        mutation($userId: String!){
          insert_users(objects: [{ id: $userId }], on_conflict: { constraint: users_pkey, update_columns: [] }) {
            affected_rows
          }
        }`
      const graphqlReq = { "query": upsertUserQuery, "variables": { "userId": userId } }

      request.post({
          headers: {'content-type' : 'application/json', 'x-hasura-admin-secret': hasuraAdminSecret},
          url:   url,
          body:  JSON.stringify(graphqlReq)
      }, function(error, response, body){
           console.log(body);
           callback(null, user, context);
      });
    }

Next Steps

To continue this tutorial, our next step will be to configure NextJs to be up and running which will be needed to configure Auth0 to work with Hasura.

Next: Set up NextJs

Hasura Fit: Setting up GraphCMS

Jesse Martin — Thu, 13 Aug 2020 17:15:13 +0000

In this portion of the multi-part tutorial, we’ll be creating our data model that acts primarily as our product information manager. Since the product being offered is a complex content structure at the end of the day, GraphCMS is the perfect tool for this job.

Why GraphCMS?

The most important reason why we chose GraphCMS is because the author works there. Ok, full disclosures out of the way, GraphCMS is one of the fastest methods out there to create a hosted GraphQL API. By simply clicking together models and types you can create complex relationships, including the often verbose “many-to-many” relationships within seconds.

GraphCMS also lets us have a content editing backend where our theoretical marketing team would be able to update the product info (our product being workout programs) and be able to update our application’s content without needing the traditional heightened access controls like accessing a user database would entail.

This is our separation of concerns between Hasura and GraphCMS - Hasura handles our user data and GraphCMS handles our product data.

The last reason we are using GraphCMS, and one of the core USPs of GraphCMS, is that it supports GraphQL mutations as well! This means that we can write data back into our content model. This is helpful because from our application data hooks, whenever a user completes a workout, we are able to simply update an integer of “popularity” on one of our workout programs so that we have a pre-compiled analytics for sorting these workouts later without the need to worry about secure and costly aggregation of our entire user database when our front-end team simply wants to sort which workouts are the most popular.

Environment Variables in GraphCMS

GraphCMS doesn’t have environment variables per se but it does have permanent auth tokens which we’ll use to authorize access to our API. Particularly because of our mutation API, it’s important to separate who has access to mutate our content vs who has access to just read our content. We can also separate access to draft vs published content in the situation where you have a preview environment.

Creating the Content Model

We’ll be doing most of our fancy content modeling in GraphCMS. Our content model will be taking advantage of a number of content modeling concepts such as composition, extending base types and creating union relationships of one or more types.

I’d like to invent a term with you called “SCUR” - this idea is not new but let’s give it a name. SCUR stands for “smallest composable unit, reasonable”. What this means is that we should try to break our content model into the smallest entry we possible can within reason balancing the concerns of time, resource and maintainability.

My model has the following primitives: A base workout type, say, a pushup. We extend on that with composition to create different types of this workout, pushup exercises that are a function of time (5-second count), pushups that are a function of repetition (25 pushups) and pushups that are a function of endurance (AMRAP - as many reps as possible, usually within a minute). Later if I want to identify the average caloric value of an exercise or some kind of additional data to my base exercise type, I can do that without the need to update a bunch of locations.

Additionally, our base workout is also one of two types, either a body weight exercise which can be done with just your own body’s weight or an exercise dependent on equipment such as boxing or jump-roping.

Another type we have is a set, or a grouping of exercises together that require some kind of order. Since these could be a mixture of time exercises, repetition exercises or AMRAP exercises, and even sub-sets, we need to use a union type relation that lets us define the possibility of any of these valid inputs.

These sets, mixed with warmups (also a union type to our exercise matrix) and cool-downs (also a union type) along with some content description, images and more create the full exercise protocol or programming and a complete product in our system.

And now our content model from GraphCMS is complete!

Next: Set up Auth0

Hasura Fit: Complete Guide / Start Here

Jesse Martin — Thu, 13 Aug 2020 17:15:06 +0000

This is a multi-part tutorial on creating a fitness app with modern web-technologies. It utilises user accounts (Auth0), User data (Hasura), Editorial content (GraphCMS), serverless functions (Vercel) and the popular React framework NextJs (also hosted on Vercel).

The rough flow of our application is as follows.

A user comes to our application which shows content required no authentication. They decide to join the program and signup.

When signing up, they are redirected to Auth0 where a new user account is created, which in turn creates a new user account in Hasura for later reference, and then sends an authentication token back to our user in the web app with special permissions to be re-used with our Hasura API and a few modified parameters to help us confirm who our user is there.

The web application updates with this new information and then shows authenticated content, such as our workout programs, which comes from Hasura at the query level, but is resolved from GraphCMS through a federated API mesh which we configured in Hasura.

Once our user performs one of the workouts, this action will save a new session in our Hasura database and at the same time, trigger a web hook which increments the popularity of that workout in our GraphCMS content API.

Here’s a rough flow chart for the following steps.

If you find errors, typos, or updates to the functionality, pull requests are always welcome!

Next: Set up GraphCMS

Forem: Hygraph

Hygraph FM: Building an artist page with components and Next.js

Building Hygraph FM

Project setup

Connecting Hygraph to Next

Creating the homepage and featured artists

Header

Navbar

Footer

Querying recent artists for featured artist content

Creating artist summary pages

Landing page for all Hygraph FM artists

Building server components in Next

Making a Callout component

Call to Action (CTA) component

Putting it all together

Next steps…

Hygraph FM: Building the artist content model

Adding a remote source to your Hygraph project

Obtaining a LastFM API key

Getting a JSON response from LastFM REST API

Shaping LastFM JSON to work as a native GraphQL API SDL

Connecting LastFM to Hygraph as a remote source

Adding our Custom Type Definitions

Building the artist content model

Single line text: Title field

Slug field

Asset: Image field

Rest: LastFM remote source field

Creating a modular component for the artist model

Button

Callout

Call to Action (CTA)

Create Artist Content

Querying artist content in the API playground

Next Steps

Convert a Hygraph Next.js project to Next.js app directory

Required Knowledge

Why the app structure?

Setting up a Next.js 13 project to work with the app directory

Converting from /pages to /app

Creating the root layout component

Adding the homepage

Converting the dynamic products route

Setting up a custom 404 page

Next steps

Boost your editorial experience with distributed content management

What is distributed content management?

Why should you care about content velocity?

The importance of content standardization

Unified Content Strategy

Technological standardization

How a distributed system can help with standards

Reduced training time and costs

Setting up a distributed CMS

An eCommerce experience

Conclusion

Data binding in Svelte

Passing props down to a child

Passing props back to a parent

Using bind:value

Using a callback

Event forwarding / dispatching an action

Conclusion

Resources

Hasura Fit: Setting up Hasura

Why Hasura?

Environment Variables in Heroku

Creating the Content Model

Users Table

Sessions Table

Adding Remote Schema

Define the Relationship

Creating a Web-hook

The gotchas

No exposed ID Type

Required Fields

Next Steps

Hasura Fit: Setting up Vercel

Why Vercel?

Using `bind:value`