 Courses from Nik Graf

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

graphql

When it comes to designing GraphQL schemas it's important to first understand what good design means.

For once it's definitely to have queries, mutations and types **driven by the business domain** in order to let developers build the desired use-cases with ease. Nevertheless a well designed schema also allows you **extend or change it based on new requirements** without making breaking changes.

In this lesson we will walk through a simple process on how to kick off a schema design process based on wireframes or UI designs. In combination with a set of solid conventions this will help you to get started, but still be able to iteratively improve your schema.


Kicking off a GraphQL Schema Design Process

A common requirement for connections is to add and remove items. We could go with two separate mutations: add & remove versus a single update mutation. In almost all situations it's better to have two separate mutations and in this lesson we explore why.

GraphQL Mutations to update Connections

GraphQL brings joy to using APIs. Even though it's based on a type system, GraphQL in many ways is more flexible than REST.

But the flexibility that makes GraphQL a joy to work with can have its downsides if you aren't careful.

Schema design is an area where one small oversight at the beginning can get you stuck having to deal with weird naming, bloated duplicates, and other annoying workarounds.

It doesn't have to be like this!

Nik Graf has extensive experience designing GraphQL schemas, for a variety of business applications.

In this course, Nik has prepared several examples following different design patterns. Through exploration and comparison, you'll come away with actionable knowledge for designing and extending schemas.

Follow Nik, and avoid making Schema mistakes that will come back to bite you later.

Designing GraphQL Schemas

When iterating on new GraphQL schema, it is great to have a server implementation allowing you to only provide type definitions and the server returning mocked results. This enables you to quickly iterate on ideas and verify them with example queries.

Apollo Server offers this by enabling the mocked mode. In this lesson create a new server with mocking enabled, customize mocks and walk through how to combine mocks with resolvers.

This setup then will be the basis for our schema design explorations. Let me add that while Apollo Server works well for this case, any other GraphQL server might do as well.


Setup an Apollo GraphQL Server with automatic Mocking 

While it's very appealing to pick a short and crisp name for a field, not naming the things exactly what they are can cause issues and confusion in the long run.

In this lesson we walk through one example in detail and see what issues a wrong naming decision can cause. After that we walk through a couple more example to get a better feeling of the recommended convention.

Naming Conventions for Query Fields in GraphQL

In GraphQL every field is nullable by default. While not ideal for the developer experience when consuming a GraphQL Schema with a client, this was a conscious decision by the creators of GraphQL. 

In this lesson we explore the background for this decision which will cover the following areas:

- Error handling
- Authorization
- Deprecations during Schema Migrations


When and Why to use Nullable vs Non-nullable Fields in GraphQL

While it's certainly possible to version a GraphQL Schema, it's common practice to not do so.

That's fine when just adding new queries or fields, but now and then we want to change a type or remove a field. Leveraging multiple deploys and deprecations we can make breaking changes in a GraphQL schema without affecting a single user.

In this lesson we use one field renaming example to walk through such a multi-step process.

Evolving a GraphQL Schema incl. Breaking Changes without affecting a Single User

Naming variations can easily be solved by postfixing the name with the variation. This though can quickly lead to a bloated schema, which we want to avoid.

On the contrary by using arguments our schema becomes less flexible.

In such cases GraphQL Aliases become a vital element to enable developers to do the same things as with multiple fields, but without any of the downsides. 

Naming Conventions for Fields with GraphQL Aliases in Mind

A Connection can be extended in multiple ways:

- Fields representing meta information on a entity relationship can be added
- PageInfo itself can be enhanced
- Arguments for filtering or ordering can be applied

In this lesson we walk through all of them to demonstrate the flexibility of the Connection Specification.

Extending GraphQL Connections with additional Fields and Arguments

When naming queries there are almost now rules or recommendations. Nevertheless it's recommended to at least have some conventions in order to reduce cognitive overhead for developers.

In this lesson we explore some the the common best practices.

Naming top-level Query Fields in GraphQL

Relay comes with a specification and a set of well define conventions for GraphQL Mutations. By following the conventions, we not only design Mutations in a way that they can be extended with easy, but also reduce a lot of cognitive overhead.

We can summarise the conventions into 5 rules:

1. Mutations are named as verbs `createProduct`, `introduceShip`, `deleteCollection`.
2. There must be a single argument input
3. The input type name is the capitalised mutation name with a `Input` postfix e.g. `CreateProductInput`, `IntroduceShipInput`.
4. The returned value is a new custom type that can contain various fields.
5. The return type is name is the capitalized mutation name with a `Payload` postfix e.g. `CreateProductPayload`, `IntroduceShipPayload`.


Mutation Input and Payload Structure in GraphQL

Being able to resolve related entities in one query is one of the most beneficial features of GraphQL.

While the simples solution often is the best, this doesn't hold up for GraphQL connections. The ideal solution is based on the [Relay Cursor Connections Specification](https://facebook.github.io/relay/graphql/connections.htm).

In this lesson we start based on a simple solution and apply one feature request after another. Eventually we end up with the Connection Specification. 

Paginate Entries using the Connection Specification

In theory it's quite easy to dynamically generate queries at runtime based on a parameter, but not a lot of GraphQL clients handle it well. It's not so much about the clients, but all the tooling around it like generators, editor integrations and the opportunity to leverage persistent queries.

Using plural instead of singular arguments will allow your clients to use static queries for situations where they usually would need dynamic ones.

Optimising GraphQL Mutations for Static Usage

In this lesson we design the mutations for a webshop checkout flow in two variations. First based on the data model, then based on the domain model.

Once we have both available we can compare them and explore the pros and cons.

Design GraphQL Mutations by focusing on the Domain rather than the Data Model 

In this short clip Nik shares why is story how this course came to be.

Course Intro for Designing GraphQL Schemas 

Feedback & Questions are very welcome at [https://twitter.com/nikgraf](https://twitter.com/nikgraf)

Thanks to everyone involved helping me to create this course, but especially to:
- Mikhail Novikov [https://twitter.com/freiksenet](https://twitter.com/freiksenet)
- Sean Grove [https://twitter.com/sgrove](https://twitter.com/sgrove)
- Marc-André Giroux [https://twitter.com/__xuorig__](https://twitter.com/__xuorig__)

Course Outro for Designing GraphQL Schemas

While being specific is great when designing GraphQL Mutations, in some cases this can lead to a large number of Mutations. Especially when the use-case is to update one entity, it raises the question if can or should do just one update mutation.

It's certainly possible, but requires some tradeoffs. Most commonly we have to make non-nullable fields nullable. In this lesson we use an `updateProduct` example to elaborate why this tradeoff is needed.

Tradeoffs when designing GraphQL Mutations to update multiple Properties on one Entity

GraphiQL Spark is convenience layer on top of GraphiQL allowing you to run queries or mutations completely client side. In addition the query/mutation response is rendered once GraphiQL is mounted, which makes it ideal for blog posts.

In this lesson we start from an empty create-react-app and add a GraphiQL Spark example.

You can find more examples of GraphiQL Spark at the documentation: https://nikgraf.github.io/graphiql-spark/

Use GraphiQL Spark to demo a GraphQL schema without an endpoint

Cascading Style Sheets bring order and beauty to our applications.

The CSS keyword `currentColor` allows you to set the color of all sorts of CSS properties like background-color, border-color, stroke, fill to the current font color. In this lesson we demonstrate this setting the stroke of an SVG to `currentColor`.

`currentColor` is well supported by all browser vendors. Even IE9 has it as you can see here: https://caniuse.com/#feat=currentcolor



Leverage the CSS keyword "currentColor" to ensure a SVG stroke inherits the Font Color

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Whenever I need to make a change to a file that includes a part I don't grasp I try to gather as much informations as possible. One tool that turned out to be very helpful to build up context was seeing who wrote the code & when.

In this lesson I demonstrate you how this can easily be achieved using the VS Code GitLens extension and how to set it up in a way that it's not constantly bothering you.

Get Git Blame insights directly in VS Code using GitLens

React is one of the web’s most popular frameworks for building JavaScript applications. 

If you know what you’re doing, React can drastically simplify how you build, use, and maintain code.

Whether you’re a React newbie or you’re ready for advanced techniques, you can level-up with egghead. Explore our in-depth courses, lessons, and community resources to build more powerful applications and crack open your career.

react

We will learn how to set up the Apollo Client using Apollo Boost, connect it to a GraphQL endpoint and use the Apollo Provider to connect it to our React Application. In addition we demonstrate how to use an Apollo Consumer

Setup and Connect an Apollo Client to a React Application with Apollo Provider

Mock Service Worker is an API mocking library that allows you to write client-agnostic mocks and reuse them across any frameworks, tools, and environments.



Mocking WebSocket APIs with Mock Service Worker


When attempting to load the same module twice in JavaScript you'll hit a cache and code won't re-run. In scenarios where you actually do want to have state in your modules, you'll have to use a cache-busting technique by passing a query parameter to a dynamic import. This lesson walks through how to add a query parameter, how to add the appropriate types for loading dynamic modules in TypeScript, and when these techniques are valuable.

Import the Same JavaScript Module Multiple Times with Cache Busting



The include keyword in GitHub Actions empowers you to add custom variables to your matrix strategy, providing flexibility beyond standard configurations. In this video, we'll explore how include allows you to define specific combinations of variables, enhancing control over your workflow runs. You'll see how this feature enables you to tailor jobs for unique environments or scenarios not covered by the default matrix options. By leveraging include, you can efficiently manage complex build processes with greater precision. This technique helps you streamline your CI/CD pipeline, making it more adaptable to your project's evolving needs.

Use GitHub Actions Matrix Include for Complex Job Configurations

While running `zod` schema validation agains domain-rich objects, the error message saying that _a string is not a number_ might not be really useful.

Especially, when you need to provide a meaningful feeback to the user, e.g. after they have submitted a form with lots of data.

`zod` allows to customize messages on a very granular level. We can also extract repeatable customization to `zod` error maps.

Finally, in order to process an error message further (e.g. display it to the user), we need to handle the `zod` validation errors effectively. Especially, when a big object validation has failed and we could receive a handful of errors.

That's what we learn in this lesson. 🔥

Customize zod Error Messages and Handle zod Errors Effectively

customize zod validation messages, customize zod schema property messages, reuse error maps across different schemas, navigate through zod error objects

You might want to run `zod` schema checks in different styles.

Sometimes you prefer to conditionally throw the error - that's what `parse` does. But another time you'd prefer to receive a `boolean` property that determines whether the validation was successful or not - and perform further actions accordingly.

Additionally, the error-throwing API of `parse` works extremely well with [TypeScript assertion functions](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#assertion-functions). Their combination is just... perfect! 👌

That's what we learn in this lesson.

Use parse and safeParse Runtime Type-checks with zod

use zod parse function to conditionally throw ZodError, use zod safeParse to get a boolean value and run typescript type guard over success property

In this lesson we learn that TypeScript cannot guarantee correct shapes of responses. That's due to TS performing checks in compile-time, while the response will be availbale in runtime - when TS doesn't exist anymore.

In some situations, such as HTTP requests, runtime type checks such as `zod` are essential for providing quick feedback around data-related errors.

Understand where are the possible mistakes to make while using TypeScript with HTTP calls. Use `fetch` and `axios` along with `zod` schema checks.

Also, note that similar mistakes or mistakes could happen while using web storage (e.g. `localStorage`)

Validate HTTP API Response with zod, fetch and axios

use zod as an HTTP response validation tool along with fetch and axios in order to make sure that the response has expected data structure

In this lesson we learn that the `zod` schemas become the single source of truth.

We shall not update TypeScript types manually, since they are generated automatically from the schema.

Same with validation functions.

Whenever the schema changes, all the rest will update accordingly. It's an important mind shift.

Treat zod Schemas as Single Source of Truth

Zod Schemas are the single source of truth for both typescript types, and interfaces - and runtime validation functions. Schemas should be updated first.

`zod` is powerful, but writing the schemas manually for existing JSON objects, especially big ones, can be time-consuming.

But that's what `quicktype` is for! You can get 80% work done instantly! 🥳

Depending on your need - whether you want to automate the process, or do it just one time, you can:
- use an online app
- use an IDE extension
- run a CLI script
- generate a script to be executed within CI/CD environment/tooling

And this is what we learn in this lesson! 🔥🔥🔥

Get started with zod quickly!

Generate zod Schemas Automatically using Quicktype App, Extensions and Scripts

Use quicktype app, extension or scripts to automatically generate zod schemas from existing json files. Save time and get started with zod quickly!

`zod` is a powerful library allowing to run runtime type-checks.

It's complementary to TypeScript, which does type checks in compile time.

In this lesson we create few schemas that represent primitive type values, along with `zod` utilities which make these more precise. We also create object schemas and nest one inside another.

All schemas are being validated against example values. We analyze how to interpret error messages in case of failures.

Perform Runtime Type-checks on Primitives and Objects with zod

Create zod schemas to validate primitive type and object type values in runtime. Analyze the errors to see how a value doesn't correspond to schema expectations


Using Cursor Chat, you can easily reference an entire directory of files and ask it to generate anything based on those files. This opens up the possibility of using your current code as a reference guide to create new code that follows existing patterns. With this approach, the result can be a polished prompt you can use with any AI to generate consistent and reliable output.

Focus less on crafting the perfect prompt upfront - what matters most is testing and iterating based on the AI's responses. The more results you see from the prompt, the more you can reinforce the good results and prune out the bad results until your prompt is polished enough that you can rely on the prompt to give you consistent quality results.


Nik Graf

Search Results