Achieving end-to-end type safety in a modern JS GraphQL stack – Part 2

Read Time:2 Minute, 52 Second

Welcome back! This article is the second and last part of the Achieving end-to-end type safety in a modern JS GraphQL stack series. Read the first part if you haven’t yet!


I won’t go into the details of why Svelte, but I like Svelte a lot. It feels great writing Svelte code. And did I mention that it also offers type safety?

The easiest way to set up a new Svelte website is with SvelteKit; let’s go back to the packages directory and create a new SvelteKit project:

This creates a bunch of new files in the packages/app directory. Let’s take a look at the most important ones.

  • src
    • routes
      • +page.svelte: this is the index page of the website and also a Svelte component
  • package.json: the package manifest, with the dependencies and scripts
  • svelte.config.js: this is the Svelte configuration file

The package.json comes with a few scripts out of the box:

  • dev: starts the development server
  • build: builds the application for production
  • check: checks the code for type errors (yay!)

You can run svelte dev to see the hello world, but we need a missing piece before we can do anything useful: the GraphQL client.

GraphQL Zeus

You can think of GraphQL Zeus as Prisma for the frontend: it writes GraphQL queries out of JavaScript objects and produces the proper return types.

In the packages/app directory, add the following dependencies:

Let’s update packages/app/package.json:

Run yarn build, and you should see a new src/zeus/ directory with a bunch of files. Let’s put all the pieces together!

Typed Board

How do we create a message board out of all of this? Keep reading – we’re almost there!

We have a few things to add to packages/app for everything to work:


Zeus is a powerful tool, but it was not made to be used for server-side rendering. We will solve this by creating a small wrapper around the generated client:

It will make our GraphQL queries much nicer to write.


This file provides the data to the +page.svelte component, both on the client (on browser navigation) and on the server (when using server-side rendering).


And that’s it! We now have a working message board with end-to-end type safety. If you make a type error in this project, the compiler will catch it at build time. Huh, I am missing the most critical part…

Here is our finished message board!

Wrapping up

It’s time to set up the whole check my types build scripts. Thanks to Yarn 4, that’s a matter of only one command. Add the following scripts in the root package.json:

This build command triggers all the packages’ build commands in the correct (topological) order, and they are all set up to catch type errors. I also added a dev command that starts all the dev servers in parallel, for convenience.

And this concludes this unusually long article. I hope you enjoyed it and that you will find it helpful. If you have any questions, feel free to ask them in the comments below or where you found this article.


CyberSEO Pro - OpenAI GPT-3 autoblogging and content curation plugin for WordPress