DEV Community: Eka

First impressions on Next.js Automatic Font Optimization

Eka — Sat, 01 May 2021 08:49:17 +0000

Cover photo: Lobster by Meritt Thomas

Automatic Webfont Optimization is a new feature that shipped with Next.js 10.2. I tried it fresh off the grill, and here is what I think.

Misnomer (for now)

Despite the name, currently it only works for Google Fonts loaded from fonts.googleapis.com. It does not work with other sources, including eg. mirrored Google fonts in regions that block Google domains.

As per their blog post, they will add integration with other font providers in the future.

How to use it?

Add a link tag that loads the Google fonts CSS to Next.js’ built-in Head component.

import Head from 'next/head';

export default function MyPage() {
  return (
    <div>
      <Head>
        <link
          href="https://fonts.googleapis.com/css2?family=Lobster"
          rel="stylesheet"
        />
      </Head>
      <p>Hello world!</p>
    </div>
  )
}

Head is a special component that enables us to append the HTML <head> element from our page components or from the custom Document component.

More info: next/head | next/document

How does it work?

Our code above is compiled into this on build:

<head>
  <!-- ... other head/meta tags -->
  <link rel="stylesheet" data-href="https://fonts.googleapis.com/css2?family=Lobster">
  <!-- ... -->
  <style data-href="https://fonts.googleapis.com/css2?family=Lobster">
    @font-face{font-family:'Lobster';font-style:normal;font-weight:400;src:url(https://fonts.gstatic.com/s/lobster/v23/neILzCirqoswsqX9zoKmM4MwWJU.woff2) format('woff2');unicode-range:U+0000-00FF,U+0131,U+0152-0153,U+02BB-02BC,U+02C6,U+02DA,U+02DC,U+2000-206F,U+2074,U+20AC,U+2122,U+2191,U+2193,U+2212,U+2215,U+FEFF,U+FFFD}
  </style>
</head>

Without optimization:

the link tag loads the Google fonts CSS, https://fonts.googleapis.com/css2?family=Lobster
the CSS @font-face loads the actual font source, https://fonts.gstatic.com/s/lobster/v23/neILzCirqoswsqX9zoKmM4MwWJU.woff2

With optimization, we skip step (1). Notice that the href attribute is changed into data-href. Instead, the style declarations are inlined and injected to the <head>. The browser requests the font file(s) in step (2) directly.

Why use it?

If you use Lighthouse, you may have come across the recommendation to eliminate render-blocking resources.

When we use the original <link> tag, the browser pauses to request the URL in the href attribute, eg. https://fonts.googleapis.com/css2?family=Lobster. When it succeeds or fails, it continues rendering the rest of the page.

The font files declared in the @font-face CSS itself, eg. https://fonts.gstatic.com/s/lobster/v23/neILzCirqoswsqX9zoKmM4MwWJU.woff2, are loaded asynchronously. They don't block the rendering process.

By using inlined style, we eliminate this render-blocking instance, thus improving page performance.

Best paired with...

Add these for optimal results.

`preconnect` to the font host origin

<link rel="preconnect" href="https://fonts.gstatic.com" crossOrigin="anonymous" />

We tell the browser that we intend to connect to fonts.gstatic.com and retrieve our font file (https://fonts.gstatic.com/s/lobster/v23/neILzCirqoswsqX9zoKmM4MwWJU.woff2) from there.

Add display=swap to prevent FOUT

<link
  href="https://fonts.googleapis.com/css2?family=Lobster&display=swap"
  rel="stylesheet"
/>

I mentioned above that font files load asynchronously. It does not block rendering (yay), but it could mean a "flash of invisible text" (oh no) when the text content is rendered before the font file finishes loading. Adding display=swap renders the text with the available fallback font, then swaps it with the intended web font once it finishes loading.

Caveats

🔮 Future readers: This post is written three days after the public launch. Things described here may have changed when you read this.

Be aware of these possible issues if using this in production.

Issue 1: Does not fire on client-side navigation change

When using client-side navigation, such as when using Next.js Link component, the style tag is not injected into the <head> in the destination route. This causes issue if we use different fonts in each page route component.

For example, we have Page A that uses the Permanent Marker handwriting typeface and Page B that uses the legendary Lobster typeface. Accessing either page directly works fine. Click on those pages and you'll see the respective typefaces.

But try navigating to Page A from Page B by clicking the "go back" link. Page A is rendered with the default typeface instead of Permanent Marker. If you open DevTools, you'll see that Page A's font stylesheet is not injected into the head, so the font file is not loaded.

Solution: Load all fonts in the custom Document Head instead of in page routes.

Examples

❌ DON’T: Load different fonts in page components
- code: https://github.com/ekafyi/example-nextjs-webfont-optimization/blob/main/pages/index.tsx#L16-L19
- preview: https://example-nextjs-webfont-optimization.vercel.app/hello-lobster
👍🏽 DO: Load fonts in custom _document
- code: https://github.com/ekafyi/example-nextjs-webfont-optimization/blob/with-custom-document/pages/_document.tsx#L26-L29
- preview: https://example-nextjs-webfont-optimization-e0t88ypsc-ekafyi.vercel.app/hello-lobster

Issue 2: Stops working arbitrarily

The first time I used this feature, it did work and rendered this code.

<link rel="stylesheet" data-href="https://fonts.googleapis.com/css2?family=Lobster">
<!-- ... -->
<style data-href="https://fonts.googleapis.com/css2?family=Lobster">
  @font-face{font-family:'Lobster'; ... }
</style>

However, in subsequent builds it renders this instead.

<link rel="stylesheet" data-href="https://fonts.googleapis.com/css2?family=Lobster">
<!-- ... -->
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Lobster">

Instead of inlining the style, now it only duplicates the render-blocking stylesheet link tag. In addition to checking the head tag from the DevTools, running a Lighthouse test gives me an "Eliminate render-blocking resources" warning, which confirms that font optimization has indeed stopped working.

I managed to reproduce this in a fresh repo from one of the official examples, but was not able to pinpoint the cause. The commits/builds that triggered and fixed the issue were completely unrelated, eg. adding a new page and removing a favicon. Reverting the offending changes did not affect the font optimization issue.

commit 4656896 — font optimization works
- preview: https://example-nextjs-webfont-optimization-2yi6vsuvr-ekafyi.vercel.app/
commit d8d9735 — font optimization does not work
- preview: https://example-nextjs-webfont-optimization-1fe1cxpz6-ekafyi.vercel.app/
commit 589b900 — font optimization still does not work
- preview: https://example-nextjs-webfont-optimization-50yetu6pr-ekafyi.vercel.app/
commit 946b980 - font optimization works again
- preview: https://example-nextjs-webfont-optimization-n2kn8qwwb-ekafyi.vercel.app/

Solution: I did not find a solution and this was a deal breaker to me, so I opted out of automatic font optimization by adding this option in next.config.js and roll my own font optimization.

module.exports = { 
  // ...
  optimizeFonts: false 
}

Conclusion

I like the premise of this feature—improve performance by optimizing Google fonts out of the box—but to me it is still too unstable to adopt for now.

Also worth noting that it's fairly simple to implement web font optimization ourself using these techniques.

What’s (ahem) next?

Discussions on future plans:

[RFC] Automatic Font Fallback for layoutshiftless font-display: swap https://github.com/vercel/next.js/discussions/24438
Add preconnect to Automatic Webfont Optimization https://github.com/vercel/next.js/discussions/24645

Serverless GraphQL Server: Deploying to Netlify Functions, 3 ways

Eka — Fri, 09 Apr 2021 17:20:39 +0000

As a detour from my attempt at learning GraphQL resolvers and data sources, I'm going to try... deploying a server without data sources. 😬

There are multiple options for hosting our server.

Apollo Server official documentation has sections on deploying to Heroku, Lambda, Netlify, and Azure Functions. Firebase Cloud Functions is in the same category. All of them (at the time of writing) have free tiers.
For demos or starter templates, web IDEs with Node server like CodeSandbox and Glitch can get you started quickly with near-zero configuration. These are not ideal for production use if you are on a free account, since the server goes to sleep after x minutes of inactivity.
Finally, you can always self-host your server if you have the resources and knowledge.

This post focuses on the first option, which is a good choice for those who have no/little experience deploying servers but want a robust, scalable solution.

I'm going to discuss 3 ways to deploy our server on Netlify Functions. They are essentially similar and achieve the same objective, but with slight variations suited for different needs.

If you've never used or (?)heard of Netlify Functions at all, here is a post I wrote last year about serverless and Netlify Functions in general.

Getting started with Netlify Functions — Zero-config setup and our first functions

Eka ・ Jul 25 '20

#serverless #jamstack #beginners

Table of Contents

Basic code and dependencies
Option 1: No build
Option 2: With build
Option 3: With TypeScript
Connecting Git repo to Netlify

TL;DR? Check out the sample repo at the end of this post.

Basic code and dependencies

Let's start with our basic project setup.

package.json

Like any JS app, we need a package.json file for our project information, commands, and dependencies. We'll get to the commands later—now let's look at the dependencies.

{
  "name": "my-server",
  "private": true,
  "scripts": {},
  "dependencies": {
    "apollo-server-lambda": "^2.22.1",
    "graphql": "^15.5.0"
  },
  "devDependencies": {
    "encoding": "^0.1.13",
    "netlify-cli": "^3.13.7"
  }
}

Dependencies:
- apollo-server-lambda
  - We use apollo-server-lambda instead of apollo-server above. apollo-server-lambda is Apollo Server's AWS Lambda integration, and Netlify Functions uses AWS Lambda under the hood.
- graphql (...but of course)
Dev dependencies:
- encoding
- netlify-cli

Our server app does not directly use the dev dependencies, but rather they enable Netlify to build the code. At the time of writing, without these, we'll get a build error bash: yarn: command not found.

graphql.js

Here is our server code. It has to be named graphql.js. To keep things simple, we use the example from Apollo documentation.

const { ApolloServer, gql } = require('apollo-server-lambda');

const typeDefs = gql`
  type Query {
    hello: String
  }
`;

const server = new ApolloServer({
  typeDefs,
  mocks: true,
  playground: true // enable GraphQL Playground IDE on prod env
});

exports.handler = server.createHandler(); // Don't forget to add this!

netlify.toml

Next, we need a Netlify build configuration file called netlify.toml. Leave the values blank for now.

[build]
  command = ""
  functions = ""
  publish = ""

We can optionally add more options and/or configure additional environments, but these are the least we should have.

These options are also available from the Netlify web UI settings. In case of conflicting values between the configuration file and the Netlify UI settings, the config file wins.

Option 1: No build

This is the most simple setup we could possibly have.

. /
├── functions/
│   └── graphql.js
├── static/
│   └── index.js # can be empty but has to exist
├── netlify.toml
└── package.json

netlify.toml:

[build]
  command = "yarn"
  functions = "functions"
  publish = "static"

Our package.json file is identical to the basic example above.

Notes:

The only command that we run on build is yarn, ie. install the dependencies.
functions = "functions" means our function code exists in a directory called functions. You can use any name, eg. functions = "my-functions", just make sure the function code exists there.
publish = "static" means our static build files are in a directory called static. We only use the serverless functions here and we are not serving any web page, but this directory is required. Add an empty index.js file there. Again, you can replace this with any directory name.
We simply serve our code; it is not compiled. So we have to use CommonJS syntax like regular Node.js apps.

Pros:

Simple and straightforward. Ideal for simple servers.
Faster build time. The free plan gives us 300 build minutes per month, so faster buid time means saving money.

Cons:

~~Limited capability, eg. can't use ES6 imports or anything that requires compiling/transpiling.~~

EDIT: Netlify recently announced an upcoming new bundler that—among other features—supports using ES modules syntax. If you just want to use import, optional chaining, etc, you most likely won't need netlify-lambda build. It is opt-in now and will be launched as public default next May. Unfortunately I don't have time to play with it now... let me know if you have tried it! 😁

Option 2: With build

First, rename the directory containing our server file (graphql.js) from functions to src.

. /
├── src/ # rename from functions to src
│   └── graphql.js
├── static/
│   └── index.js
├── netlify.toml
└── package.json

Then change the command in netlify.toml:

[build]
- command = "yarn"
+ command = "yarn build"
  functions = "functions"
  publish = "static"

We don't change the functions directory here, the build/destination directory is still functions, while our server source code now lives in src.

We are using netlify-lambda for the build step. Install it and add these commands to package.json.

npm install --save-dev netlify-lambda
# or
yarn add -D netlify-lambda

{
  "scripts": {
+   "start": "netlify-lambda serve src",
+   "build": "netlify-lambda build src"
  },
  "devDependencies": {
    "encoding": "^0.1.13",
    "netlify-cli": "^3.13.7",
+   "netlify-lambda": "^2.0.3"
  },
  // ... no change to rest of file
}

Notes:

We add two commands, serve (optional; you may use Netlify Dev instead) and build. In both commands, we tell netlify-lambda to build from the src directory—where our function code is.
netlify-lambda knows where the source files are, but how does it know where to build the code a.k.a. the destination folder? It reads our netlify.toml file! 🎩

Finally, modify our server code to use ES6 import instead of the Node/CommonJS require.

// src/graphql.js
- const { ApolloServer, gql } = require('apollo-server-lambda');
+ import { ApolloServer, gql } from "apollo-server-lambda";

Pros:

We can have more complex Lambda functions with transpiled modern features, imports, etc.

Cons:

As a general rule, more dependencies = longer build and higher possibility of errors or incompatibilities. Only use the build step if necessary.

Option 3: With TypeScript

We can use TypeScript with Netlify functions to take advantage of its type-checking and Intellisense features.

First, install the dependencies.

npm install --save-dev @babel/preset-typescript typescript @types/node @types/aws-lambda

Then create a Babel config file and a TypeScript config file in our root directory.

.babelrc

{
    "presets": [
        "@babel/preset-typescript",
        [
            "@babel/preset-env",
            {
                "targets": {
                    "node": true
                }
            }
        ]
    ],
    "plugins": [
        "@babel/plugin-proposal-class-properties",
        "@babel/plugin-transform-object-assign",
        "@babel/plugin-proposal-object-rest-spread"
    ]
}

tsconfig.json

{
    "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
        "moduleResolution": "node",
        "outDir": "./functions",
        "strict": false,
    },
    "exclude": [
        "node_modules",
        "functions"
    ]
}

Your tsconfig file does not have to look like this. Just make sure the outDir value matches the functions value in our netlify.toml.

Rename our server file from graphql.js to graphql.ts.

This part is optional: I add a resolver function with a custom function using TS syntax. Our hello query now takes an optional argument name, which the server will SHOUT!!!! back to us.

import { ApolloServer, gql } from "apollo-server-lambda";

+ const shout = (msg: string) => {
+   return `${msg.toUpperCase()}!!!!`
+ }

const typeDefs = gql`
  type Query {
+   hello(name: String): String
  }
`;

const resolvers = {
  Query: {
+   hello: (_parent, args) => shout(`Hello ${args.name || 'serverless server'}`),
  },
};

// ... no change to the rest of code

Pros:

Same as Option 2, plus TypeScript

Cons:

Same as Option 2

Connecting Git repo to Netlify

Sign up for a free Netlify account if you haven't got one. Push your code to a Git repository (Github, Gitlab, or Bitbucket).

Go to Netlify Dashboard on https://app.netlify.com and choose "New site from Git". Continuous Deployment is enabled by default, so Netlify deploys your site every time you push to your repo.

Once deployed, you can check the build process in the Deploys section on https://app.netlify.com/sites/YOUR-SITE-NAME/deploys. If your build fails (😿), the logs are available there.

When the build completes successfully, your serverless server function will appear in the Functions section under the name graphql.

Click to view its details and endpoint URL. If we enabled playground config in our server code above, we can interact with our server directly by accessing GraphQL IDE from the endpoint URL.

You can do various customizations (turn off automatic deploys, customize repo branch and base directory, and more) from Site settings > Build & deploy on https://app.netlify.com/sites/YOUR-SITE-NAME/settings/deploys.

Conclusion

Serverless cloud functions services like Netlify Functions enable us to get an API server live and running with no charge (to begin with), with little infrastructure and devOps knowledge.

You can find all the code above in this repo. Fork it and build something fun!

ekafyi / hello-graphql-server

Serverless GraphQL Server on Netlify Functions, 3 Ways

Sample repo for my DEV.to post

Does what it says on the tin...

no-build — graphql server function without build step
with-build — graphql server function with netlify-lambda build
with-ts — graphql server function with netlify-lambda build + TypeScript

Quick Start

If deploying from this repo, make sure you set the base directory to the directory you want to use (eg. no-build). See: https://docs.netlify.com/configure-builds/get-started/#definitions

Else

Or you can clone this repo and start a Git repo manually/locally from the directory you want to use.

git clone https://github.com/ekafyi/hello-graphql-server.git

cd hello-graphql-server/no-build

npm install

git init

View on GitHub

Thank you for reading, and stay tuned for more beginner GraphQL learning attempts. 🤞🏽

References

Power up your (API) mocking game with casual

Eka — Sat, 27 Mar 2021 07:12:01 +0000

Cover image: Calvin & Hobbes © Bill Watterson

Previously in this series, I made a GraphQL API server that returns mock data for a (nonexistent) app that displays my favourite music releases.

Having mock data facilitates our API server's integration with other parts of design and development work, such as UI development, prototyping, and testing, even while the server's resolvers are still under development.

An example query and mock data from the previous post:

However, this mock data could do with some improvements, for example:

The track_number field—indicating a song/track’s order in an album—could return a negative integer (impossible) or a very large one (how many albums do you know contains 91 tracks??).
All albums, tracks, and artists have the same mock names, "Album/Track Title" and Artist Name. We want to develop and test the UI with varying data, including artists with a very long name or songs with a very long title.

We are going to use a library called casual for our custom mock data.

boo1ean / casual

Fake data generator for javascript

Fake data generator

LOOKING FOR CONTRIBUTORS

#109

Installation

npm install casual

Usage

var casual = require('casual');

// Generate random sentence
// You don't need function call operator here
// because most of generators use properties mechanism
var sentence = casual.sentence;

// Generate random city name
var city = casual.city;

// Define custom generator
casual.define('point', function() {
    return {
        x: Math.random(),
        y: Math.random()
    };
});

// Generate random point
var point = casual.point;

// And so on..

Casual uses javascript properties for common generators so you don't need to use function call operator

Embedded generators

// Address
casual.country              // 'United Kingdom'
casual.city                 // 'New Ortiz chester'
casual.zip(digits = {

…

View on GitHub

Installation
Basic usage
More basic usage examples
Custom generators with casual.define
Custom providers with casual.register_provider
Localization

1. Installation

npm install casual # or yarn add casual

Import/require casual in your server app main script (eg. index.js or app.js).

const casual = require("casual")

2. Basic usage

Casual comes with dozens of built-in generators (in the form of properties and functions) that return dummy data for various common purposes such as user data, addresses, numbers, dates, copy text, etc.

In an Apollo GraphQL server, we pass a casual generator to our custom mocks object so it returns the value generated by casual.

My mocks object now looks like this:

const mocks = {
  Artist: () => {
    return { name: () => "Artist Name" };
  },
  // ...etc
}

Let's replace the dummy text "Artist Name" with casual.name.

const mocks = {
  Artist: () => {
-   return { name: () => "Artist Name" };
+   return { name: () => casual.name };
  },
  // ...etc
}

The server now returns mock artist names such as...

"Ms. Timothy Lesch"
"Mrs. Napoleon Hayes"
"Dr. Alisha Cole"
"Mr. Celia Lockman"

Unusual artist names for sure 😁, but at least they are not all "Artist Name anymore.

3. More basic examples

Now let’s try other simple built-in generators.

const mocks = {
  Artist: () => {
    return { name: () => casual.name };
  },
  Album: () => {
    return {
      // ... other fields
+     release_date: () => casual.date()
    };
  },
  Track: () => {
    return {
      // ... other fields
+     track_number: () => casual.integer(1, 12)
    };
  },
+ ExternalUrlObject: () => {
+   return { spotify: () => casual.url };
+ },
}

casual.date() is a function that returns a date string, eg. "2021-03-25". It takes an optional argument, a momentjs-compatible formatter. If no argument is passed, it uses the default format 'YYYY-MM-DD'.
casual.integer(1,12) is a function that returns an integer between 1 and 12, thus solving our track number predicament. (Yes, we could roll our own random integer generator without a library, but this is helpful in terms of speed.)
casual.url is a property that returns an URL, eg. 'http://www.Germaine.net/'. For some reason, the domain name is always capitalized, so I add .toLowerCase() in my full code.

Combining generators

We can also combine generator functions. For instance:

casual.words(5) returns five random words
casual.integer(1,6) returns a random integer between 1 and 6

We can use casual.words(casual.integer(1, 6)) to return a phrase that consists of one to six words. This gives us a (slightly) better control of the text length compared to generators like title, text, and description.

4. Custom generators with casual.define

We can define custom generators with casual.define(name, fn). The first argument is the generator name and the second is a function returning the value.

Let's make a custom artist_name generator.

casual.define('artist_name', () => {
  // TODO return something
});

I want the mock artist name to return either a person’s name (representing solo artists) or a group/band name. I’ve got a list of fictional band names from Band Name Generator for the latter, and for the person names I'm simply using the casual.full_name generator.

I define the band names in a hardcoded array:

const bandNames = [
  "Crystal Greener",
  "The Threshold Renewable",
  "Unevenly Optimist",
  // ... etc
];

Next I’m going to: (1) pick one name out of the bandNames array, and (2) randomize returning either a person name or a band name. The casual.random_element() helper, which returns an item from the array passed as argument, is perfect for those.

casual.define("artist_name", () => {
  // pass array containing a person full_name and a band name to return at random
  return casual.random_element([
    casual.full_name,
    casual.random_element(bandNames) // get a random band name
  ]);
});

Then we use it in our mock resolver function.

Artist: () => {
+  return { name: () => casual.artist_name };
},

When we run our query, now we get a list of more realistic artist names. 🎉

"Price Tillman"
"The Out Garter"
"Colby Bergnaum"
"The Threshold Renewable"
"Raphael Kohler"
"The Fountains Altars"

We can go beyond an individual field (eg. name) and define an object type in the same way, for example define a casual.artist generator that returns an object with name and bio properties. Make sure the object shape matches the type definition, though.

casual.define("artist", () => {
  return {
    name: () => casual.artist_name,
    bio: () => casual.description
  }
})

5. Custom providers with casual.register_provider

Under the hood, casual generators are simply functions in a provider object. Casual includes the following built-in providers:

address
color
date
internet
payment
person
misc
number
text

The full_name generator, for example, is defined in the person provider (source code).

casual.define is sufficient for one-off individual generators, but if we have an object type with multiple fields/properties to mock up, we can register our own custom providers.

For example, a music track would not only have a name/title but also track number, tempo in BPM (beats per minute), and duration in millisecond. Let's try registering a custom music_provider. First we create an object and pass it to casual.register_provider().

const music_provider = {
  // TODO add functions or properties here
};

casual.register_provider(music_provider);

Then we add the generator functions as the object properties. For example, we're adding track_number and tempo to our music provider.

const music_provider = {
  // Track number in an album, between 1 to 12
  track_number: () => casual.integer(1, 12),

  // Song tempo in BPM, between 60 to 180
  tempo: () => casual.integer(60, 180)
};

casual.register_provider(music_provider);

Since these are regular functions, we can define our generator to accept arguments. For example, we can make an artist_name generator that accepts a type argument of "PERSON" or "GROUP". If no argument is provided, we return any of those at random.

const bandNames = [ ... ]; // same data as Step 4

const music_provider = {
  // ... other generators

  // Return an artist name. Name can be a solo artist's name ("PERSON") or a band name ("GROUP").
  artist_name: (type) => {
    if (type === "PERSON") return casual.full_name;
    else if (type === "GROUP") return casual.random_element(bandNames);
    return casual.random_element([
      casual.full_name,
      casual.random_element(bandNames)
    ])
  },
};

The best way to see what we can do when defining providers is to look at the source code, eg. the address provider.

To use the generators from our custom provider, we call them the same way as built-in or custom defined ones.

const mocks = {
  Artist: () => {
    return { name: () => casual.artist_name };
  },
  Track: () => {
    return {
      track_number: () => casual.track_number,
      tempo: () => casual.tempo,
    };
  },
}

...

6. Localization

Casual comes with localization built-in. Simply add the locale name when calling the default import. For example, to get the Indonesian locale:

- const casual = require('casual');
+ const casual = require('casual').id_ID;

Locale providers are simply copies of the default providers in directories with the locale names (en_US, fr_FR, id_ID, etc) — see source. These locale providers are submitted by contributors.

<digression>
Off topic but interesting (to me): While looking at the locale providers, I learned that Russian female last names are the male last names + an a in the end. I went on to Google the tennis athlete Anna Kournikova and sure enough, her father's name is Kournikov.
</digression>

When a localized provider is not available, it falls back to the default (English). For instance, the Indonesian locale only has the address provider, so everything else uses the default.

We barely scratched the surface with casual. Check out their docs to see all available functionalities.

Enough mocking for now—in the next post I'm going to start learning about GraphQL server resolvers. Thank you for reading!

Typing and mocking a GraphQL API server with Apollo

Eka — Fri, 26 Mar 2021 03:52:01 +0000

Previously in this series, I made a GraphQL server that returns nothing. Now I'm going to design the schema (type defintions) and set up mocking functionality. Since I have yet to build the resolvers (which retrieve data from a database or other sources), the server will now return mock data based on the schema.

Overview

I'm building the API for a hypothetical app that displays my favourite music releases. The API server shall return a list of music releases; each list item shall have a title, an artwork image, artist name(s), and URL to play on Spotify.

I borrowed the basic models and descriptions from Spotify Web API official documentation via an app that converts Spotify API’s objects into GraphQL schema I’d built earlier, liberally simplified and modified for this purpose.

TL;DR? View (and fork) the live CodeSandbox app ↓

Part 1: Typing

A schema describes our GraphQL API’s data models, relations, and operations. It is comprised of type definitions written in a syntax called the Schema Definition Language (also called the "GraphQL schema").

So... what exactly are these types that we define? GraphQL recognizes a number of type categories.

Entry-point types: Query and Mutation
Object types
(Default/built-in) Scalar types
Custom scalar types
Enum types
Input types
Abstract types: unions and interfaces

We are only using some of those now, but I'm including references at the end of the post if you’d like to learn more.

Quick copypasta of types we're going to use:

# Query type
type Query { ... }

# Object types
type Artist { ... }
type Album { ... }
type Track { ... }
type Image { ... }

# Enum type
enum AlbumType { ... }

# Interface type and object type that implements it
interface Release { ... }
type Album implements Release { ... }

# Union type (we're discussing but _not_ using this)
union Release = Album | Track

Object types

An object type represents a kind of object (...who would’ve thought? 😬) containing a collection of fields (properties) that can be fetched from some data source(s). A GraphQL schema is usually largely comprised of these types.

For our schema, let’s define the object types Artist, Album, Track, and Image (truncated for brevity).

type Artist {
  id: ID!
  name: String!
  images: [Image!]
}

type Album {
  id: ID!
  name: String!
  artists: [Artist!]!
  images: [Image!]
  release_date: String
}

type Track {
  id: ID!
  name: String!
  artists: [Artist!]!
  album: Album!
  track_number: Int
  preview_url: String
}

type Image {
  url: String!
  height: Int
  width: Int
}

An object type must contain at least one field. The object type Artist contains fields called id, name, and images (and so on).
The field type can be...
- a scalar type (ID, String, Int—details below),
- or another object type (eg. in the Track object type, the album field contains an Album object).
The exclamation mark ! indicates a required field; lack of which indicates nullable.
The square brackets [] indicates a list/array of the type inside the brackets.
- eg. [String] = a list of strings, [Artist] = a list of Artist objects.
artists: [Artist!]! means the artists field is required and cannot be null (right-side/outer exclamation mark). It cannot return an empty array, either; it must contain at least one Artist object (inner exclamation mark).

Note that the SDL is agnostic with regards to data sources; we don’t have to define object types and fields in relation to any database table/column structure.

Query type

This is the only required part of a schema. Technically, it’s possible to have a server without a single object type. But we will get an error if the Query type does not exist.

Query and Mutation are GraphQL’s special top-level, entry point types. Clients, ie. front-end apps, can only retrieve (read) data through Query and store/update/delete (write) data through Mutation.

Unlike a REST API, a GraphQL API has no multiple endpoints. Clients don't send a GET request to /albums for a list of albums and another to /artists/:id for the artist data; they simply send a single query with a list of fields they need, which are the fields in our Query type.

type Query {
+  albums: [Album!]
+  tracks: [Track!]
}

With our schema above, clients can query for albums, which will include the relevant artists and images data (if they include those fields in the request). Likewise for tracks. But they cannot get a list of artists or images, since our type definition does not include such fields.

Like object types and Mutation, Query fields can accept arguments.

type Query {
  albums: [Album!]
  tracks: [Track!]
+ album(id: ID!): Album
+ track(id: ID!): Track
}

The last two fields enable clients to query a single album or a single track by passing an id as argument.

Note: We are not discussing Mutation here, but it's essentially Query's counterpart for POST/PUT/DELETE operations.

Scalar types

Some fields above have types like Int and String—these are the default/built-in scalar types, which are GraphQL schema’s primitive types equivalent. There are five scalar types: ID, String, Int, Float, Boolean.

We can also define our own custom scalar types. Apollo Server provides the GraphQLScalarType constructor class to facilitate defining our custom scalar logic, which we then pass to a custom resolver. I'm going to discuss this part in a separate post.

Enum types

Like other typed languages, GraphQL SDL has an enumerated type, a.k.a. enum. An enum field type can only have one of the predefined string values.

The Spotify API’s AlbumObject has an album_type field, originally typed String, whose value is one of "album", "single", or "compilation". Let’s define it as an enum type in our schema.

type Album {
  id: ID!
  name: String!
  artists: [Artist!]!
  images: [Image!]
  release_date: String
+ album_type: AlbumType
}

+ enum AlbumType {
+   ALBUM
+   SINGLE
+   COMPILATION
+ }

In addition to type safety (when querying and displaying on the frontend, when passing as query argument, as well as when making mutations), using enum types also gives us the benefit of intellisense/autocompletion in supported IDEs.

Note that the enum values have to be in UPPERCASE as per GraphQL specs. If the values in the data source (eg. database) are in lowercase, we can map them in a custom resolver function. Not only for mapping cases of course, we can use it eg. to map colour shorthands into corresponding hex values, as shown in the Apollo Server documentation.

Union and interface types

The last types we're going to discuss are the abstract types. Essentially, they represent a type that could be any of multiple object types. Quick definitions by GraphQL Ruby:

Interface: "a list of fields which may be implemented by object types"
Union: "a set of object types which may appear in the same spot"

(🤔 ...huh?)

We're going to see how either one could be used in our schema to describe "a music release, which could either be an album or a track".

Option A — with union

One possible approach is by defining a union type called Release, which could either be an Album or a Track object type. Then we add a field called releases to the query, which returns a list of Release objects.

+ union Release = Album | Track

type Query {
  albums: [Album!]
  tracks: [Track!]
+ releases: [Release!]
}

Notes:

The Album and Track definitions stay the same.
A union can only consist of two or more object types, not scalar or any other types.

Unexpectedly (to me), this type is not intended for mixed scalar and object types, eg. a field that could be an integer or a particular object type. We need custom scalars for that instead. Related discussions:

Option B — with interface

Alternatively, we can define an interface type called Release, which is then implemented by the Album and Track object types. It contains the fields id, name, and artists, which both Album and Track have. Like in option A, we add a field called releases to the query, which returns a list of Release objects.

+ interface Release {
+   id: ID!
+   name: String!
+   artists: [Artist!]!
+ }


- type Album {
+ type Album implements Release {
  id: ID!
  name: String!
  artists: [Artist!]!
  images: [Image!]
  release_date: String
}

- type Track {
+ type Track implements Release {
  id: ID!
  name: String!
  artists: [Artist!]!
  album: Album!
  track_number: Int
  preview_url: String
}

type Query {
  albums: [Album!]
  tracks: [Track!]
+ releases: [Release!]
}

Another unexpected-to-me finding: We still have to include the common interface fields in the object type fields (in this case id, name, artists). Yes, we write id: ID! three times and they have to be identical.

So... are they interchangeable?

I ended up in a rabbit hole researching these two types’ difference in usage, but it is an interesting topic! I will probably revisit this in a separate post.

TL;DR + IMO: They are conceptually different, but share similar characteristics as abstract types, which enable them to solve the same problems (such as our Release type) albeit in different ways.

On a more practical level, when querying, we use inline fragments differently with union and interface types.

A union type does not know what fields each object type does/does not have. So we have to specify all fields inside the inline fragments, including the identical ones (eg. name and artists).

query GetUnionReleases {
  latest_releases {
    ... on Album {
      # name and artists fields here...
      name
      artists
      images
    }
    ... on Track {
      # ...name and artists fields again here
      name
      artists
      album
    }
  }
}

Meanwhile, with an interface type we can specify the common fields (the interface’s fields) outside the fragments. The Release interface always contains name and artists fields, so we can query them outside the inline fragments.

query GetInterfaceReleases {
  latest_releases {
    # interface’s fields
    name
    artists
    # object type specific fields in the fragments
    ... on Album {
      images
    }
    ... on Track {
      album
    }
  }
}

These queries will be made from the clients that consume our API, but you can try it from the server app’s GraphQL Playground IDE. For this app, I decided to use the interface type to define Release (option B).

Half-time

Let’s see our code so far.

// index.js
const { ApolloServer, gql } = require("apollo-server");

const typeDefs = gql`
  type Query {
    albums: [Album!]
    tracks: [Track!]
    releases: [Release!]
  }
  # ... the rest of the schema
`;

const server = new ApolloServer({ typeDefs });

server.listen().then(({ url }) => {
  console.log(`🚀 Server ready at ${url}`);
});

The server is up and running, and the GraphQL Playground IDE shows the documentation and autocomplete feature based on our type definitions.

We can also use Apollo Studio to access—among other things—a more powerful and dev-friendly query builder.

Above we can see the Release interface detail, including the types that implement it. When I select the images field under Album, it automatically builds the inline fragment in the query. Smooth! 😎

But when we run the query, the server returns null because we have not set up the resolvers, which will return each field value. Fortunately, Apollo Server has an extensive mocking feature based on our type definitions.

Part 2: Mocking

Mocks out of the box

Add a mocks: true option when creating a server instance to enable the default mock resolvers.

const server = new ApolloServer({
  typeDefs,
  mocks: true,
});

When we send the query... the returned data is no longer null.

Let's query some more data...

query Query {
  releases {
    id
    name
    artists {
      name
    }
    ... on Album {
      album_type
      name
      release_date
    }
    ... on Track {
      name
      track_number
      explicit
    }
  }
}

...and here is the returned mock data.

{
  "data": {
    "releases": [
      {
        "id": "f4570e2d-9221-4a8e-ae5d-6cf0bcb3c10e",
        "name": "Hello World",
        "artists": [
          {
            "name": "Hello World"
          },
          {
            "name": "Hello World"
          }
        ],
        "track_number": -65,
        "explicit": false
      },
      {
        "id": "be550404-7bad-46c7-a314-cb88ceec1710",
        "name": "Hello World",
        "artists": [
          {
            "name": "Hello World"
          },
          {
            "name": "Hello World"
          }
        ],
        "album_type": "COMPILATION",
        "release_date": "Hello World"
      }
    ]
  }
}

ID is mocked as random string uuid. Nice!
String is mocked as Hello world.
Int is randomly generated.
Boolean and enum types are correctly typed!
Array types always return 1-2 items (depending on the number of fields).
We don't have custom scalar type here. If we did, we would have to pass a custom resolver for the mock to work.

This is pretty cool, considering it takes literally five seconds to implement. But let's make the mock data resemble our expected data better.

Custom mock resolvers

Pass an object to the mocks option to enable custom mock resolvers. As the name suggests, they are identically shaped to the actual resolvers, both of which correspond to the schema. Each property is a function that returns the corresponding mock value.

For example, this replaces "Hello world" with "My custom mock string" for the String scalar type value.

- const mocks = true;
+ const mocks = {
+   String: () => "My custom mock string"
+ };

const server = new ApolloServer({
   typeDefs,
+  mocks,
});

But the album, track, and artist names are all String. Does not make much sense if they all return "My custom mock string", does it?

Luckily, we can mock our object types the same way. Remove the String function and add Album, Track, and Artist functions.

const mocks = {
-   String: () => "My custom mock string"
+   Album: () => {
+     return { name: () => "Album Title" };
+   },
+   Track: () => {
+     return { name: () => "Track Title" };
+   },
+   Artist: () => {
+     return { name: () => "Artist Name" };
+   }
};

Let's send another query and see the returned mock data.

query Query {
  releases {
    __typename
    name
    artists {
      name
    }
    ... on Album {
      album_type
    }
    ... on Track {
      track_number
    }
  }
}

{
  "data": {
    "releases": [
      {
        "__typename": "Track",
        "name": "Track Title",
        "artists": [
          {
            "name": "Artist Name"
          },
          {
            "name": "Artist Name"
          }
        ],
        "track_number": 33
      },
      {
        "__typename": "Album",
        "name": "Album Title",
        "artists": [
          {
            "name": "Artist Name"
          },
          {
            "name": "Artist Name"
          }
        ],
        "album_type": "ALBUM"
      }
    ]
  }
}

Note that although we only pass the name function, the mock logic uses the default mock logic for the remaining fields (eg. track_number in Track, album_type in Album). Nice!

MockList

Lists—such as releases and artists—return two items by default. What if we need different number of items mocked? Apollo Server provides the MockList constructor to customize the number of items in a list.

const { 
   ApolloServer,
+  MockList 
} = require("apollo-server");

const mocks = {
  Album: () => {
-   return { name: () => "Album Title" };
+   return { name: () => "Album Title", artists: () => new MockList(1) };
  },

  Track: () => {
-   return { name: () => "Track Title" };
+   return { name: () => "Track Title", artists: () => new MockList(1) };
  },

+ Query: () => {
+   return { releases: () => new MockList([0, 15]) };
+ }
}

Although an album or track can have more than one artists (eg. featuring/collaboration), most albums and tracks just have one artist. Let's add an artists mock resolver to Album and Track which returns a MockList object. The integer argument 1 means always return one item.
Meanwhile in Query, we add releases that return between 0 to 15 items, using the array argument [0, 15]. This is particularly useful for testing and UI development/prototyping—what an empty state looks like, what the pagination looks like, what an "awkward" number of item (eg. just 1) looks like.

Now when we run our query, the returned mock data looks like this.

It's still not ideal (track_number: -60 anyone? 😬), but we've got some mock data to test and start developing the UI/frontend app with.

Putting it together

In this post, we define our API’s types and their relations (Query, object types, enums, interface) in the GraphQL schema language and pass it as template literal to Apollo Server’s gql parser. Then we use the built-in mocks option so our server returns mock data based on our type definitions. We use custom mock resolvers to customize our mock data behaviour.

Stay tuned for the next post in this series, where I'm going to improve my mocks with casual fake data generator!

References

Serving nothing through GraphQL

Eka — Sat, 20 Mar 2021 16:45:23 +0000

The absolute minimal GraphQL server (with a hint of existential crisis)

I was taking Apollo’s beginner-level Odyssey interactive tutorials, having been trying and failing to learn GraphQL on and off over the last year. Midway through, I started wondering what the most simple GraphQL server setup looks like, so I made a server that returns nothing.

This is obviously not meant to be a pragmatic example. If you want to see basic Apollo Server examples with sensible defaults instead, go to:

Apollo Server CodeSandbox template — fork it to get a live GraphQL server in 5 seconds
https://github.com/apollographql/odyssey-lift-off-part1/tree/complete — the Apollo Odyssey course companion app
Official documentation “Getting Started” tutorial

What do we need?

Any Node.js app. I build mine locally on my machine from scratch, but you can use IDEs like Glitch or Codesandbox or use an existing project.
If building locally, node and npm should be installed.
How I made my app:
- Create the app directory and go there
- Run npm init, go with all default values
- (Optional) Install nodemon to monitor our app and auto-reload when the code changes: npm i --save-dev nodemon
- Open package.json, add "start": "nodemon index.js localhost 4000" to the scripts
Create our main script file, eg. index.js. This is where we're going to write our server code. It can be called anything, eg. app.js. Make sure it matches the command in package.json.
- If using a template or adding to an existing app, open your package.json and see what the main script is called.

We are ready to set up the GraphQL server!

Steps

Install dependencies and import functions
Create our type definitions schema
Create a new ApolloServer object
Start the server

1. Install dependencies and import functions

We need two packages as dependencies: graphql and apollo-server.

# Run in your app root directory
npm install apollo-server graphql

Then import ApolloServer and gql from apollo-server in our script file, eg. index.js. We're going to use them in the next steps.

const { ApolloServer, gql } = require("apollo-server");

2. Create our type definitions schema

Next we create our type definitions, which describe the shape of the data our server will resolve and return. We write our definition as a string literal in a syntax called the GraphQL Schema Definition Language, then pass it to the template literal tag gql we imported in Step 1.

const typeDefs = gql`
  # TODO add type definitions here
`;

There are multiple different of types, but here we simply define the Query type, where clients can query for nothings. This field shall return an array of string (it doesn't matter as I'm not planning to return anything—but it has to be defined), and it is nullable.

const typeDefs = gql`
  type Query {
    nothings: [String]
  }
`;

Learn more:

3. Create our server object

Now we instantiate the ApolloServer constructor class—ie. we create a new ApolloServer object—that takes an option object.

const server = new ApolloServer({
  // TODO add options here
});

For this test app, we are passing one option from Step 2, typeDefs. You can see the complete list of options in the link below.

const server = new ApolloServer({
  typeDefs, // shorthand for `typeDefs: typeDefs`
});

Learn more:

https://www.apollographql.com/docs/apollo-server/api/apollo-server/#options

4. Start the server

Finally, we add the command to start our server.

server.listen().then(({ url }) => {
  console.log(`🚀 Server ready at ${url}`);
});

Run npm run start to start our first GraphQL server. You will see something like this on your CLI console.

[nodemon] starting `node index.js localhost 4000`
🚀 Server ready at http://localhost:4000/

While our server is running, we can access the GraphQL Playground on the server URL itself, in this case localhost:4000. It provides a quick, convenient graphical interface to interact with our server.

Write an opening { and press spacebar to open list of available fields. Here we only have one field, nothings.

Once we have our query for nothings, press the "Run" icon, and our server returns the data (or lack thereof, in this case).

That's it, we've got a server that serves nothing! 😁 Below is the full server code.

Learn more:

Random remarks

Where are the resolvers?

It's interesting that while we have to provide type definitions (the server won't run if we pass an empty option object or don't pass any argument), technically we don’t even need to pass resolvers in order to have a running GraphQL server 😮. (We do need to write resolvers to make a server that returns data, of course.)

Explanation: resolvers is required, but Apollo Server provides default resolvers if none is explicitly provided. When running at the top level as in our code here, it cannot look for anything from the parent and returns null—but that explains why we don't get an error despite not passing any resolver. See the logic: https://www.apollographql.com/docs/apollo-server/data/resolvers/#default-resolvers

Phew, it’s regular JavaScript

As someone who primarily works with frontend development and never built an API server before, to be honest I didn't know what it entailed—what languages and tools are necessary? This sample server demonstrates that it only requires intermediate-level vanilla JavaScript plus SDL for the type definitions. (I presume data retrieving and storing, deploying, CI/CD (etc) require knowledge of other languages and tools, but not for setting up the server itself.)

What's next?

I sure as heck don’t want to get stuck with a server that returns nothing 😆. Going to explore these next:

Mocks
Resolvers and data sources
Deploying
?? ...and more

See you in the next posts!

Converting Spotify Web API Objects to GraphQL Schema Object Type Definitions

Eka — Sun, 14 Mar 2021 09:34:34 +0000

I made a web application that scrapes and displays the Spotify Web API objects in two formats: GraphQL Schema Definition Language (SDL) and JSON.

Example: SimplifiedTrackObject

Spotify official documentation https://developer.spotify.com/documentation/web-api/reference/#object-simplifiedtrackobject
GraphQL schema format https://wsywh.sse.codesandbox.io/SimplifiedTrackObject/schema
JSON format https://wsywh.sse.codesandbox.io/SimplifiedTrackObject/json

The stack: 🥞

Node.js app with the Express framework
Nunjucks templating engine for the index view
Cheerio for parsing data from HTML
Hosted on CodeSandbox

Why did I make this app?

As part of learning about the GraphQL schema

Schema is a key concept in GraphQL. It specifies what kinds of data clients can request and what operations clients can perform through a GraphQL API. It consists of type definitions, written in a syntax called the Schema Definition Language (SDL). In many implementations, we pass the type definitions to template literal tags such as gql in Apollo Server and createTypes in Gatsby.

Example from Apollo Server documentation:

const typeDefs = gql`
  type Author {
    name
  }
`;

Example from Gatsby documentation:

exports.createSchemaCustomization = ({ actions }) => {
  const typeDefs = `
    type AuthorJson implements Node {
      joinedAt: Date
    }
  `;
  actions.createTypes(typeDefs);
}

Took me a while 😬, but I just realised that since template literals are strings, a schema type definition is actually, literally (pun intended), a regular string. It is then processed by functions such as gql and createTypes above into a schema format required by respective libraries.

My hypothesis:

const { gql } = require('apollo-server');

// We can do this...
const typeDefs = gql`
  type Author {
    name
  }
`;

// ...and we can also do this?? 🤔
const typeDefsString = `
  type Author {
    name
  }
`;
const typeDefs = gql(typeDefsString);

If true, this means full versatility of where and how we get the data for our schema without requiring a transpiling/compiling step. Instead of manually writing the type definitions in SDL, for instance, we may have a "single source of truth" file in any format readable by JavaScript. We can even programmatically scrape a documentation web page to build the schema.

And thus, I got the idea to scrape the Spotify API documentation page and transform the data into GraphQL SDL.

When this app was finished, I used the resulting object type definitions in my local Apollo GraphQL server, and it worked, confirming my above hypothesis on versatile schema data source.

To see how a large-scale production app’s data models and relations are depicted in a schema

Documentations and beginner-level tutorials, understandably, focus on the API/concept and use highly simplified, shortened schemas. Converting Spotify API's objects to schema format gave me an idea of what I will be dealing with when setting up schema for a production app. This leads to the next point...

To better understand REST and GraphQL API behaviours

Despite identical database structure, models, and relations, different API architectures require different way of thinking. Observing object types designed for a large production app on REST API and converting them to GraphQL schema highlights the different perspectives between the two.

For example, the Spotify API has ArtistObject and SimplifiedArtistObject. The former is used eg. when returning a single artist, and the latter when including artist data in a track or an album. The former contains fields like followers and genres, which are never needed in the latter use cases. This distinction is necessary for a REST API, but may not be needed for a GraphQL one. Clients simply request the fields they need from the ArtistObject type.

How does this app work?

Scrape the Spotify documentation page with request
- For the sake of speed, I copied the HTML into a local file in the node app’s public directory and read it with fs instead.
Parse the HTML string with cheerio to find the objects data.
- It doesn't matter where the data comes from (remote URL, local file), as long as we pass HTML string to cheerio: const $ = cheerio.load(scraper.scrapeLocal()).
- Cheerio is based off core jQuery, so we use jQuery selectors—which for the most part resembles DOM element selectors—to find the data we need: const unformattedObjectTypes = $("#reference-index + .left-split-container > .row:last-child ul li").
- Heads up: As Cheerio relies on the markup selectors to parse data, if we use a remote source (ie. Spotify documentation page) and the markup changes, our code breaks. I use a local file for this app, so this will not happen.
Now I've got a list of object types; each object type has multiple fields, each of which has a name, description, and type. Then I prepare the data to send to our routes. The data preparation process consists of two separate things:
- The first group is minor adjustment/formatting tasks such as getting the innerText of target elements, trimming whitespace, replacing double quote marks, etc.
- I did not have much time to work on this MVP, so I removed double quote marks and omitted description with complex markup (eg. reason field in TrackRestrictionObject has lists and formatted content in the description). Note that we can have multi-line description in GraphQL schema by wrapping it in three double quote marks, and we can convert HTML markup to Markdown syntax for the description.
- The second group is related to syntax and specification differences between Spotify's documentation and SDL requirements.
  - Minor syntax differences: [SomeObjectType] instead of Array[SomeObjectType], Int instead of Integer.
  - SDL uses union types, eg. union TrackOrEpisode = TrackObject | EpisodeObject instead of directly using TrackObject | EpisodeObject in the object field type.
  - SDL cannot have an empty type. TrackObject has empty linked_from, which should be replaced with something else (LinkedTrackObject maybe?).
  - SDL does not recognize generic Object or any type. PagingObject has an Array[Object] type, which could be replaced either once we know what Object refers to, or by making a custom generic scalar type.
- I have not fixed these, but I found these interesting to note. Of course, if I were refactoring a REST API codebase for my own/my workplace's app, I would have more information (and time!) to address them.
Finally, I return the data in appropriate format for each route (schema in plain text, json, and HTML page for the home page). I use Nunjucks for the home page, which is not necessary but makes the code tidier. I also add a parameter to save the data to a static file (object-types.txt and object-types.json) for faster access.

Caveat/notes:

This app simply returns the object types data as string in the SDL format. It does not fetch or serve or interact with data in any way. It demonstrates what a GraphQL type definition looks like without getting into the implementation.
Related to the point above, a GraphQL schema does not only contain object type definitions but also GraphQL-specific types like Query, Mutation, and Subscription. This app does not address those.
This app is hosted on a free CodeSandbox account, so it shuts down after a few minutes of inactivity. If I were using it for a production app, I would host it on a server that is always on.

As I learn more about GraphQL I plan to build a GraphQL server of some sorts with schema from this app. Til then, thank you for reading and take care.

References

GraphQL introduction and beginner tutorials
GraphQL schema and SDL

Pull (fetch) from a forked GitHub repository

Eka — Thu, 08 Oct 2020 09:22:42 +0000

You are working on a project outside of your or your organisation account--an open source project for Hacktoberfest, perhaps. You forked the repo and started working on it.

Meanwhile, the original repo has been updated with new changes. To prevent conflict, you need to pull these changes from the original repo and merge it to your local, forked branch. But wait... how do you do that? ❓🤔

Follow these steps and you'll be good to go. 😎

(1) add remote

git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git

(2) fetch

git fetch upstream

Commits to the remote main branch will be stored in a local branch called upstream/main (same with other branches).

(3) merge to local, then merge to your working branch (if necessary)

git checkout main
git merge upstream/main

# merge to working branch
git checkout eka/working-branch
git merge main

Done!

References

Add Theme UI to your NextJS site

Eka — Sat, 01 Aug 2020 16:58:32 +0000

Theme UI is a React styling library “based on constraint-based design principles”, where we can centralize our design tokens in a regular JavaScript theme object . Although there’s no Theme UI plugin specifically for NextJS like for Gatsby, we can add Theme UI to our NextJS web app/site in three straightforward steps.

1. Install theme-ui

npm i -D theme-ui
# or yarn add theme-ui

2. Create and export the theme object

// src/utils/theme.js
export default {
  colors: {
    text: "#111",
    background: "#fff",
    primary: "tomato",
    secondary: "#3f3f3f",
    muted: "#e0e0e0",
    highlight: "#9f9f9f",
    gray: "#6c6c6c",
    accent: "#3f3f3f",
  },
  fonts: {
    body: "Comic Sans MS",
  },
};

You can use any filename and directory, just make sure you import it correctly in the next step. See more theming references and demo in the Theme UI docs.

3. Wrap our NextJS app with Theme UI’s ThemeProvider

We achieve this by making use of NextJS’s custom App.

// src/pages/_app.js
import * as React from "react";
import NextApp from "next/app";
import { ThemeProvider } from "theme-ui";
import theme from "../utils/theme"; // theme object from step 2

export default class App extends NextApp {
  render() {
    const { Component, pageProps } = this.props;
    return (
      <ThemeProvider theme={theme}>
        <Component {...pageProps} />
      </ThemeProvider>
    );
  }
}

We also add Theme UI’s InitializeColorMode to NextJS’s custom Document to prevent flash of colour.

// src/pages/_document.js
import Document, { Main, NextScript } from "next/document";
import { InitializeColorMode } from "theme-ui";

export default class extends Document {
  static async getInitialProps(ctx) {
    const initialProps = await Document.getInitialProps(ctx);
    return { ...initialProps };
  }

  render() {
    // Replace html lang attribute value with your language.
    return (
      <html lang="en">
        <body>
          <InitializeColorMode />
          <Main />
          <NextScript />
        </body>
      </html>
    );
  }
}

Learn more:

Does it work?

We should be able to use the sx property in our components. Remember to use the @jsx pragma and import jsx in order to use it.

// src/any-component.js
/** @jsx jsx */
import { jsx } from "theme-ui";

export default function SomeComponent() {
  return (
    <>
      <div sx={{ backgroundColor: "primary", color: "#fff", p: 4 }}>
        tomato
      </div>
    </>
  );
}

Run npm run dev (or yarn dev) to check if the theme styles have been applied.

That’s it, we have added Theme UI in our NextJS site!

Go serverless with this JungleJS + Netlify functions starter site

Eka — Thu, 30 Jul 2020 13:07:38 +0000

JungleJS is a static site generator, meaning that it generates every single route and compiles all the assets on build time. Since it’s a Svelte app, we can take advantage of Svelte’s lifecycle to create interactive UI with client-side requests if necessary. For most landing pages, blog, or portfolio/profile websites, this should be enough. It’s simple, performant, and saves hosting costs.

But sometimes we need a server (even when it’s not our own). A common use case for server-side operation is to send authenticated requests. Say we use the Mailchimp API to add users to our newsletter, or maybe the Spotify API to suggest a playlist based on the user’s mood. Both require us to send a key or token to identify ourselves. We cannot do this on the client-side because everyone can open the browser dev tools, find our secret keys, and do anything on behalf of our account.

Does not even take a “hacker” to find our credentials if we send it from the browser.

Here’s where serverless functions come in. In a nutshell, these are a cloud service that allow us to run a server that is hosted, configured, and managed by a third-party, such as AWS Lambda, Netlify Functions, and Firebase Cloud Functions. I just learned about Netlify functions recently, so I made this starter site that combines JungleJS with Netlify functions.

ekafyi / junglejs-netlify-functions

Starter site for JungleJS + Netlify Functions + Storybook + TailwindCSS

JungleJS + Netlify Functions starter site

A starter site with:

JungleJS — Svelte and GraphQL-based static site generator
Netlify Functions — Serverless functions
Storybook — UI development environment
TailwindCSS — utility-first CSS framework

Introductory posts:

Quick start

Or create a new repo with Github template.

Install and develop

# Install the global Netlify CLI package if you haven’t
npm install netlify-cli -g

# Clone and go to project directory
git clone https://github.com/ekafyi/junglejs-netlify-functions.git
cd junglejs-netlify-functions

# Install dependencies
npm install

# Start Netlify Dev server
netlify dev

# (Optional) Start Storybook server in a separate tab
npm run storybook

Netlify Dev serves your site on localhost:3333. Your functions run on localhost:3333/.netlify/functions/{YOUR_FUNCTION_NAME}.

This starter comes with a sample function hello.js, which you can access on:

localhost:3333/.netlify/functions/hello
localhost:3333/.netlify/functions/hello?name=Eka (example with query parameter)

If you start…

View on GitHub

This is a simple starter with a netlify.toml configuration and a sample function in functions/hello.js. It’s based off my previous starter site, which includes Storybook and Tailwind CSS.

Installation

Do any of these:

Clone by running git clone https://github.com/ekafyi/junglejs-netlify-functions.git on your CLI
Create new repo with Github template
Deploy with Netlify
Deploy with Vercel

Then run netlify dev (or ntl dev for short) to start your server.

Your site runs on localhost:3333
You can access the functions at localhost:3333/.netlify/functions/{YOUR_FUNCTION_NAME}
- I include a sample function called hello in this starter, which can be accessed at localhost:3333/.netlify/functions/hello.
- This function takes an optional name query parameter, eg. localhost:3333/.netlify/functions/hello?name=Eka.

Port 3333 is configured in netlify.toml. You can change it to any other value (as long as it does not clash with used ports).

If you are not familiar with Netlify functions or netlify dev, check out my post about getting started with Netlify functions.

Getting started with Netlify Functions — Zero-config setup and our first functions

Eka ・ Jul 25 '20

#serverless #jamstack #beginners

I’m working on a demo site that demonstrates how to use Netlify functions in this starter site, so watch this space!

Bonus Track

Get asynchronous data in JungleJS, the new Svelte JAMstack library

Eka — Tue, 28 Jul 2020 18:14:16 +0000

JungleJS is a new static site generator that uses Svelte and GraphQL. It also has a handy routing feature akin to NextJS and Sapper, where you can have src/routes/[slug].svelte and query for data based on the slug. I made this JungleJS starter site with Storybook and Tailwind CSS so you can get started using it more quickly.

ekafyi / junglejs-storybook-tailwind

Starter site for JungleJS + Storybook + TailwindCSS

At the time of writing, the official docs and template describe two data sources: JSON (whether imported and parsed from local files or written in the JS code) and Markdown files. All well and good if you only need those data sources. But many websites today also get their data from external sources by sending a request to an external API, which is asynchronous in nature.

This is not possible with the current template, so I asked on their Github repo: Is it possible to fetch data asynchronously in JungleJS?

Is it possible to pass data to dataSources asynchronously? #10

ekafyi posted on Jul 26, 2020

Trying JungleJS for the first time now, good work!

I wonder if it's possible to query data from an external source (eg. fetch from external API) then pass it to dataSources items?

The problem is, it has to be done asynchronously. Is it possible at all to return exports in jungle.config.js asynchronously? Or is there any other way to achieve this?

Thanks!

View on GitHub

They responded that they aimed to have this functionality as a user-facing plugin in the future, and kindly gave the code to run JungleJS asynchronously in the meantime.

To save you all the copy-pasting and server-restarting 😉, I added a simple example and published it to my starter site under the branch with-async-data.

Code: JungleJS + Storybook + Tailwind CSS starter with asynchronous data fetching example
Clone: git clone -b with-async-data https://github.com/ekafyi/junglejs-storybook-tailwind.git
Deploy with Vercel
Live Demo

If you use the Netlify Deploy button or the Github template feature, you’ll get the master branch by default. You can run git checkout with-async-data to move to the async branch.

How I made this example

First I modified app.js to run asynchronously as advised by @ConProgramming, the creator, in the issue’s answer above. I did the same with build.js. (Not in the original answer but this is also necessary.)

Next I modified jungle.config.js, which previously exported an object, into an asynchronous function as per the answer. Then I added a simple fetch example with the following steps:

Run npm i -D node-fetch (install and save the node-fetch package as dev dependency). You can use eg. axios instead of fetch if you want.
Fetch data from the free OpenLibrary API. You can replace it with any API you want; simply change the SAMPLE_FETCH_URL value.
- Don’t forget to add the necessary credentials or headers in your request as required by the API.
Pass the returned data to the dataSources in the same format as the existing data source objects example.

// jungle.config.js

// ... other stuff

const fetch = require("node-fetch");

const SAMPLE_FETCH_URL = "https://some-external-api/endpoint";

module.exports = async () => {
  const myResponse = await fetch(SAMPLE_FETCH_URL);
  const myArray = Object.values(await myResponse.json());

  return {
    // .. clientInputOptions etc
    dataSources: [
      {
        format: "json",
        name: "book", // data name as a singleton noun
        items: myArray, // our data as an array
      },
      // ... other data sources
    ],
  };
};

Then the data is processed into the GraphQL layer and available to query from our frontend. As I use the name book in jungle.config.js dataSources, I use the plural format books to get a list of books via GraphQL query.

<script>
  const QUERY = `
    query {
      books {
        authors {
          name
        }
        cover {
          medium
        }
        title
        url
      }
    }
  `;
  const QUERYRES = {};
  console.log(QUERYRES.books);
</script>

The data is available as QUERYRES.books and can be used as we normally would in any Svelte application. This is the simplified version:

{#each QUERYRES.books as {authors, cover, subtitle, title, url}}
  <article>
    <img src={cover.medium} alt="" width="180" height="270"/>
    <h3>{`${title}${subtitle ? `: ${subtitle}` : ''}`}</h3>
    <div>{joinAuthorNames(authors)}</div>
  </article>
{/each}

To build for production, run npm run build. The build is in the jungle/build directory, ready to upload/drop to any static site hosting you want. I use Netlify, where I can drag and drop the folder and have my Jungle site live in a few seconds. ✨

My impressions of JungleJS

🙂 Like

I love Jungle’s approach to SSG. Powered by Svelte, it creates a lean, no-frills, modern JAMstack site with no redundant hydration or run-time tasks. It’s idea for websites where we don’t need complex client-side features and would like more control to add progressive enhancements as we see fit.

Effortlessly good SEO: You can “View Page Source” on the page and see our books data rendered as regular HTML, ready for search engines to crawl.
Effortlessly good Lighthouse score: As shown below, it literally loads the HTML, 2 CSS files, 1 bundled JS file, and the images. That’s it.

This is simply a quick demo. For production, the images should ideally be lazy-loaded, the 2 CSS files combined and/or lazy-loaded, and the JS file deferred for better performance.

🙁 Dislike

Not reallly a “dislike” per se, but given this library is very new, the development experience is still not ideal. For starter there is no live reload, so you have to restart the server to see any change. Also, using GraphQL beyond simple data like in this example may be tricky.

Gatsby, for example, has an integrated GraphQL viewer where we can check our query. They also provide a way to anticipate missing data that would otherwise break the GraphQL query (for example, querying for the optional subtitle field would break if none of the books have a subtitle).

Until then, feel free to try the starter and hope JungleJS grows into a more mature library. 😃🤞

Bonus Track

JungleJS + Storybook + TailwindCSS starter

Eka — Sun, 26 Jul 2020 19:32:32 +0000

📷 Cover image: Isaac Quesada

ekafyi / junglejs-storybook-tailwind

Starter site for JungleJS + Storybook + TailwindCSS

JungleJS + Storybook + TailwindCSS starter site

A starter site for:

JungleJS — Svelte and GraphQL-based static site generator
Storybook — UI development environment
TailwindCSS — utility-first CSS framework

Read my introduction posts on DEV:

Branches

master — JungleJS + Storybook + Tailwind CSS
with-async-data — master + async data fetching example

Quick start

Or create a new repo with Github template.

Install and develop

# Install the global Netlify CLI package if you haven’t
npm install netlify-cli -g

# Clone and go to project directory
git clone https://github.com/ekafyi/junglejs-storybook-tailwind.git
cd junglejs-storybook-tailwind

# Install dependencies
npm install

# Start Jungle server
npm run start

# Start Storybook server
npm run storybook

Jungle runs on localhost:3000.

Storybook runs on localhost:6006.

Directory structure

root
├── .storybook # Storybook config
├── src
│   ├── # ...

…

View on GitHub

JungleJS is a new static site generator. All Svelte goodness + GraphQL data layer = fast, performant static site. Jungle’s underlying philosophy seems to resemble Eleventy, except Jungle uses Svelte.

But as of now, Jungle does not have live reload yet. We have to restart the server any time we make a change. While only partially addressing the needs for live reload, we can use Storybook for developing UI components. Even in project with hot reloading/live reload, it’s useful to have an isolated UI development environment like Storybook, which also provides us with various addons, from accessibility to testing. Finally, Tailwind provides customizable, utility-first CSS, which helps us build our UI faster.

And thus this starter site was born.

For a quick start, you can click the “Use this template” button on the Github repository or run git clone https://github.com/ekafyi/junglejs-storybook-tailwind.git.

Let me know if you're building anything with this!

Bonus track

Getting started with Netlify Functions — Zero-config setup and our first functions

Eka — Sat, 25 Jul 2020 16:55:44 +0000

Serverless functions are server-side functions that are hosted on a third-party service (in this case Netlify). In a nutshell,

We write our server-side functions
We walk up to the third-party service with the functions and say, “Oh hey, could you please run these for me on your server?”
They say “Sure!”
We can now call the functions to do whatever they are supposed to do and return whatever we need for our web application.

Why? With serverless functions, we get the benefits of a server without having our own server. Our “server-side” functions can even live in the same codebase as our website code. How convenient!

Should I use these? In my opinion, this is ideal for small to mid-level projects. If your app has large traffic or other specific/unusual requirements, make sure to compare the costs and implications thoroughly before going serverless.

A misnomer? Much like wireless speakers are not without wires, these functions definitely run on servers; we just don’t need to set up, configure, host, and manage them ourselves. 😁

In this series, we’re going to learn how Netlify functions work by building a web application with a REST API from scratch and deploy it. It’s inspired by Jason Lengstorf’s “Introduction to Serverless Functions” workshop, which was my first encounter with serverless functions.

This first post focuses on getting our local dev environment up and writing our first functions. Before we proceed, please note this post presumes the following.

Basic knowledge in:
- JavaScript and HTML
- How a web application works (server, client/browser)
- RESTful API
- Git version control
A (free) account on:
- Netlify
- GitHub, GitLab, or Bitbucket
Latest node and npm (run node -v && npm -v on your CLI/Terminal to check)

Table of Contents

Installation
Start our development environment
Create our server(less) functions
- 3a. Define our functions directory
- 3b. Add function files to our functions directory
- 3c. Write our first function
- 3d. Write a function with query string parameters
- 3e. Write a function that accepts a data body (payload)
- 3f. Use secret environment variables in our function

1. Installation

1a. Install the global Netlify CLI package

Run on your command line: npm install netlify-cli -g

1b. Prepare your web app

Clone or initialize your project. You can clone this sample repo for a quick start.

git clone -b part-1 https://github.com/ekafyi/hello-serverless-netlify-functions.git

Netlify functions are written in standard (vanilla) JS and work with any modern JS libraries. The sample repo uses the default Eleventy installation. We're not going to write any web code yet, but feel free to use a starter from your favourite library instead.

Don’t forget to cd to the project directory and install the project’s dependencies by running yarn or npm install.

2. Start our development environment

Run netlify dev (or ntl dev for short) to start our local development environment. It’s going to serve our web app (in my case Eleventy), our web server, and a Browsersync interface.

Our web app runs on port 8080
- This our web app’s dev server that we usually start with npm run start or npm run watch (or the yarn equivalent).
Browsersync UI runs on port 3001
Our web server runs on port 8888

If you cloned the sample repo, you should see this page on both ports 8080 and 8888.

What kind of sorcery is this? 🧙🏼‍♀️✨

Netlify Dev is an integrated local development environment that automatically:

Detects and runs your site generator

Makes environment variables available

Performs edge logic and routing rules

Compiles and runs cloud functions

It has a “project detector” that checks our project package.json and configures the dev setup automatically. In most cases, it “just works”—no need to do anything.

However, if you use a less popular library and/or have a custom setup, you can declare your setup by creating a netlify.toml file in your project root that contains your dev setup.

# netlify.toml dev block example
[dev]
  command="yarn dev"
  port=5000

Learn more:

Zero Config, yet Technology Agnostic: How Netlify Dev Detectors Work
List of built-in detectors https://github.com/netlify/cli/tree/master/src/detectors
Netlify Dev documentation https://github.com/netlify/cli/blob/master/docs/netlify-dev.md

Note: If you run extra servers for custom processes (eg. to watch CSS with Sass or PostCSS), you still need to run them separately in addition to ntl dev, OR modify your package.json so they are included in the default dev command.

Now we’ve got our web app running, let’s write our first functions!

3. Create our server(less/-side) functions

📝 Note: Netlify Docs has in-depth explanation on the functions discussed here.

3a. Define our functions directory

I create a new directory called functions in my project root. (You can use any name; make sure to specify the right name below.)

Create a file called netlify.toml in your project root (if you don’t have it already) and add functions="" inside the [dev] block, where the value is the name of our serverless functions directory (in my case, functions).

# netlify.toml
[dev]
  command="npm run build"
  publish="_site"
  functions="functions"

3b. Add function files to our functions directory

Next, create a JS file in our functions directory that exports a handler method. (I use the ES6 syntax here, hence () => { … } instead of function() { … }. Feel free to use whichever you’re most comfortable with.)

// functions/hello.js
exports.handler = () => {
  // ... later
}

The filename without extension represents a serverless function endpoint in this format: {SERVER_URL}/.netlify/functions/{FUNCTION_NAME}.

So, if we have functions/hello.js, we send our request to http://localhost:8888/.netlify/functions/hello.

We can have as many files as we want.

3c. Write our first function

Our function should return a JSON response. This is the most simple function possible.

// functions/hello.js
exports.handler = async () => {
  return {
    statusCode: 200,
    body: "Hello there!",
  };
};

// GET localhost:8888/.netlify/functions/hello
// → Hello there!

Notes:

async means this is an asynchronous function, which I can call from my web app code with a promise. If you’re not familiar with these, read “Introducing asynchronous JavaScript“ on MDN.
List of HTTP response status codes (maybe don’t return 418).

3d. Write a function with query string parameters

The handler method has the event and context parameters, and an optional callback parameter. The event object contains information about the request. It looks like this.

{
  "path": "/.netlify/functions/echo",
  "httpMethod": "GET",
  "headers": { ... },
  "queryStringParameters": {},
  "body": undefined,
  "isBase64Encoded": false
}

path = path parameter
httpMethod = request’s method (eg. GET, POST, PUT)
- As per the suggested RESTful API naming practices, GET /.netlify/functions/users should get the users data and POST /.netlify/functions/users should create a new user. We can do this in serverless functions by getting the httpMethod value.
headers = request headers
- This contains HTTP Headers data such as Accept-Language, User-Agent, etc.
queryStringParameters = self-explanatory (more on this below)
body = request payload
isBase64Encoded = a boolean flag to indicate if the applicable request payload is Base64-encode

Now let’s modify our hello function to return a greeting based on the name parameter in the request.

// functions/hello.js
exports.handler = async (event) => {
  const { name } = event.queryStringParameters;
  return {
    statusCode: 200,
    body: `Hello ${name || 'stranger'}!`,
  };
};

// GET localhost:8888/.netlify/functions/hello
// → Hello stranger!

// GET localhost:8888/.netlify/functions/hello?name=Eka
// → Hello Eka!

We use the event parameter and get the name value from event.queryStringParameters.
- Note: const { name } = event.queryStringParameters is shorthand for const name = event.queryStringParameters.name.
If we have multiple query string parameters in the request, we can access them all as objects in queryStringParameters.
- eg. GET localhost:8888/.netlify/functions/hello?name=Eka&timeOfDay=morning, we can get the name and timeOfDay values from event.queryStringParameters.

We are not discussing the context and callback parameters in this post, but you can read about them in the links below.

Learn more:

Build serverless functions with JavaScript — Netlify Documentation
HTTP headers — MDN Docs

3e. Write a function that accepts a data body (payload)

POST requests are basically similar to GET requests, except they may contain data—eg. user-inputted form data—in the request body. We can access it in event.body and do something with it, such as send it to some external API or database.

// functions/newsletter.js
exports.handler = async (event) => {
  const { body } = event; // Request body data

  // Basic example of sending the data to an external API
  fetch(`https://someserver.com/v1/some/endpoint`, {
    method: "POST",
    headers: {
      "Content-type": "application/json",
      // Add credentials as required by the external service
    },
    body: body, // Send the data
  })
    .then((response) => {
      // Do stuff and returns 200 response...
    })
    .catch((error) => {
      // Do stuff and returns 4xx / 5xx response...
    });
};

// POST localhost:8888/.netlify/functions/newsletter
// → 200 OK

Remember that these functions are regular JavaScript code. body data are sent in JSON-safe string format; request body must be parsed if we want to access it as JS objects, and contrariwise JS objects must be stringified to send in response body.

3f. Use secret environment variables in our function

We briefly discussed sending our data to an external service in the example above. Today, most web apps retrieve and/or send data to and from external APIs, usually with some kind of secret (token or key) in our request header to validate our app.

We should not make this request from the client side (the browser), because everyone can open the browser dev tools and find your credentials 🙀, which then can be used for (eg.) deleting all your data or posting egregious content on your behalf.

With serverless functions, we can have “server-side” code to handle this operation while keeping our credentials private.

Create .env in your project root (if it does not exist yet) and add your secret there.

SPOTIFY_CLIENT_ID=xxxxxxxxx
SPOTIFY_CLIENT_SECRET=xxxxxxxxx

The env data is available in our functions in process.env like so.

// functions/spotify.js
exports.handler = async (event) => {
  // Example of Spotify API "Client Credentials" authorization
  const getToken = async () => {
    const result = await fetch("https://accounts.spotify.com/api/token", {
      method: "POST",
      headers: {
        "Content-Type": "application/x-www-form-urlencoded",
        Authorization: "Basic " + btoa(process.env.SPOTIFY_CLIENT_ID + ":" + process.env.SPOTIFY_CLIENT_SECRET),
      },
      body: "grant_type=client_credentials",
    });
    const data = await result.json();
    return data;
  };

  getToken()
    .then((response) => {
      // Do stuff ...
    })
    .catch((error) => {
      // Do stuff ...
    });
};

Make sure .env is in your .gitignore so it does not get pushed to the repository.

That’s all for now…

You can see the sample repo below and the demo site here.

ekafyi / hello-serverless-netlify-functions

Sample repo for my “Getting Started with Netlify Functions” posts

Hello Netlify Functions

Sample repo for the first post in my “Getting Started with Netlify Functions” series.

View post on DEV.to

Demo:

View on GitHub

We have set up our project’s local development environment, written our first serverless functions, but you may notice we haven’t done anything with our web app. We’re going to do it in the next post, so stay tuned!

Bonus Track

With serverless functions, you can send secrets in your requests securely. Here is my favourite (but unfortunately unreleased) version of “Secrets” by Strawberry Switchblade.

DEV Community: Eka

First impressions on Next.js Automatic Font Optimization

Misnomer (for now)

How to use it?

How does it work?

Why use it?

Best paired with...

preconnect to the font host origin

Add display=swap to prevent FOUT

Caveats

Issue 1: Does not fire on client-side navigation change

Issue 2: Stops working arbitrarily

Conclusion

What’s (ahem) next?

Serverless GraphQL Server: Deploying to Netlify Functions, 3 ways

Getting started with Netlify Functions — Zero-config setup and our first functions

Eka ・ Jul 25 '20

Basic code and dependencies

package.json

graphql.js

netlify.toml

Option 1: No build

Option 2: With build

Option 3: With TypeScript

Connecting Git repo to Netlify

Conclusion

ekafyi / hello-graphql-server

Serverless GraphQL Server on Netlify Functions, 3 Ways

Quick Start

Else

Power up your (API) mocking game with casual

boo1ean / casual

Fake data generator for javascript

Fake data generator

LOOKING FOR CONTRIBUTORS

Installation

Usage

Embedded generators

Table of Contents

1. Installation

2. Basic usage

3. More basic examples

Combining generators

4. Custom generators with casual.define

5. Custom providers with casual.register_provider

6. Localization

Typing and mocking a GraphQL API server with Apollo

Overview

Part 1: Typing

Object types

Query type

Scalar types

Enum types

Union and interface types

Option A — with union

Option B — with interface

So... are they interchangeable?

Half-time

Part 2: Mocking

Mocks out of the box

Custom mock resolvers

MockList

Putting it together

References

Serving nothing through GraphQL

What do we need?

Steps

1. Install dependencies and import functions

2. Create our type definitions schema

3. Create our server object

4. Start the server

Random remarks

Converting Spotify Web API Objects to GraphQL Schema Object Type Definitions

Why did I make this app?

As part of learning about the GraphQL schema

To see how a large-scale production app’s data models and relations are depicted in a schema

To better understand REST and GraphQL API behaviours

How does this app work?

References

Pull (fetch) from a forked GitHub repository

`preconnect` to the font host origin