Forem: Jess Edwards

What's the difference?

Jess Edwards — Wed, 17 May 2023 09:56:09 +0000

I found myself wrangling with what I thought was an odd TS issue yesterday afternoon. During a quick chat about it, my boss gave me this gem of an example and I had to share it.

What's the difference between?

someString && obj[someString] ? [obj[someString]] : []

and

const specificVal = someString && obj[someString];
const result = specificVal ? [specificVal] : [];

To break down the first statement, we're saying

If someString is truthy (not null or undefined etc.) and obj has a key someString, the ternary should return an array that holds the value of someString.
If the conditional is falsy, an empty array is returned.

The second statement breaks this into two steps, first by defining specificVal, and then using a ternary to return an array with that value or an empty array.

Just looking at them, they're pretty similar statements, so what's the difference between them?

A whole lot. It might manifest itself as a TypeScript issue, but it's there for a reason.

Typescript can't infer and guarantee that obj[someString] in the conditional statement is going to be the same as obj[someString] in the return statement, so we split it in to two variables.

Here's a fun example of that - Proxies make objects that on access, can run code to return a result!

const map = new Proxy({}, {get(target, prop, receiver) {return Math.random(); }})

Consider doing something like:

const value = map[1] > 0.5 ? map[1] : 0

This won't be consistent with returning something higher than 0.5 or 0.

Splitting it up now fixes that problem.

const v = map[1]
if v > 0.5 ? v : 0

Essentially object and array access can be just as dynamic as functions (via Proxies, getters and other traps) and we need to treat them as such in places to make TypeScript happy.

Shoutout (and all credit) to James Canning for the example and explanation!

GraphQL: A brief introduction into queries and mutations

Jess Edwards — Tue, 24 May 2022 09:28:12 +0000

You've probably heard of "queries" and "mutations" a bunch of times - in this article I'll go over the basics of what they are and how to use them.

In short

On a basic level, we can think of queries as doing the same thing as a GET request in a RESTful API. Mutations can be compared to methods like DELETE, PUT, and PATCH, or anything else that updates the data.

Queries

Queries are kinda like functions in JavaScript. They can be named or anonymous, take arguments or not take them, but they always return some sort of data.

{
  posts{
    title
    author
  }
}

You can think of a query as asking for a specific field on an object. We can't query the whole object, we have to query the fields it contains.

// won't work
{
  posts{
  }
}

GraphQL still recognises queries when they don't have a name or use the 'query' operation type. It's shorthand syntax, but it is better to specify the type of operation we make and give it a name. The operation type can be query, mutation, or subscription, and we have creative freedom in choosing a name for it.

It is best to choose a name that reflects what is happening (GetPosts to get all posts, UpdatePost to update posts etc.) and its conventional to use PascalCase when we name queries and mutations.

Arguments

Queries, like functions, can take arguments - in some cases they might even be required. If an argument (or field) is required, it'll have an exclamation mark after it and won't work if you try to query it without the parameter it requires.

query{
  postByID(id:3){
    title
  }
}

Variables

In the code snippet above, we're writing our arguments directly into our query string, but there will be times when we want our arguments to be dynamic, because we might not know in advance what the query criteria will be, e.g. give me all the posts with ___ as the author.

We can make this work by using variables. To use variables, our query has to have an operation type and a name.

query GetPostByID($id:Int!){
  postByID(id:$id){
    title
  }
}

We've given the query a name, declared the parameter it takes, and the type of that argument. We will have already declared that this query takes a parameter and the type of it in the Schema, so its good to check that whatever we're using here is the same as what we've already declared.

We can now replace the hard coded value in the query with $arg. This arg has to have the same name as the parameter. The $ doesn't do anything special, its just highlights the variable.

Using variables helps make your code more DRY and dynamic.

Default variables

We can provide default values by adding the default value after the type declaration.

query GetPostByID($id:Int!=2){
  postByID(id:$id){
    title
  }
}

If we do this, we can call the query without passing a variable. When we do pass a variable the default is overridden.

Mutations

We write mutations in the same way. We use the mutations operation type, pass in the data we want to mutate, and can use variables to make the mutation more dynamic.

Testing this out for yourself

If you want to mess around with basic queries and mutations yourself you can do so with this super basic demo app. Happy coding :)

GraphQL: A brief introduction to schemas, types, and resolvers

Jess Edwards — Mon, 23 May 2022 09:32:16 +0000

Schemas, types, and resolvers; what are they and how do they fit together?

Let's start with schemas - it's where we define the shape of our data - we do this by giving it a type.

When we create a schema, we do so in a different language. Don't panic, it's simple. It's called schema definition language and its very similar to defining an object.

type Post {
    id: ID!
    title: String!
    author: String!
    body: String!
}

This Post type has four fields with key names (id, title, author, body) and scalar types that describe the information stored there.

Scalar types

Scalar types are built-in types provided by GraphQL, and you’ll probably recognise most of them - they are String, Int, Float, Boolean, ID .

We can define relationships between types too; for example, if we wanted to store more information about an author, but separately to the Post, we could do this:

type Post {
    id: ID!
    title: String!
    author: Author!
    body: String!
},
type Author {
    id: ID!
    name: String!
}

The type associated with the author field is now the Author type, which is made up of fields which have their own scalar types.

We also define any queries or mutations we make in the schema too. When we define the type a query or mutation will have, we have to make sure that whatever the associated resolver returns has the same type.

type Query {
    allPosts : [Post!]!
}

And resolvers?

Resolvers are functions that resolve a value for a type or field in a schema, and they do a similar job as controllers do in REST.

We have defined the return type of our queries in the schema, the resolver now takes the data that we get from the query and transforms it into a shape that matches the one that was described by the type in the schema.

That might be a lot to think about, so picture it this way:
There's a query type in the schema that says it returns a triangle. When we get the data, we see that it actually gives us a square, so we write a resolver function to transform that square into a triangle.

Resolver functions can return objects or scalars. If an object is returned, execution continues to the next child (like from Post to Author in the example above), until a scalar value is returned at which point the execution is completed. If null is returned, the execution stops.

The resolvers for query and mutation types have to have the same name as the query or mutation type that they are resolving, that's how GraphQL knows which resolver to invoke.

Resolvers are like normal functions, so you can pass arguments to them too. Its often convenient to destructure these parameters.

And there you have it, a brief introduction to schemas, types, and resolvers.

GraphQL - A brief introduction

Jess Edwards — Fri, 20 May 2022 08:38:23 +0000

At a first glance, GraphQL can seem quite intimidating. There's plenty of information out there about it, but a lot of it is pretty cryptic (it's even hard to get a base line definition of what it is).

I've recently spent some time breaking it down into more digestible chunks - here are my findings.

It all starts with an API

It's impossible to talk about GraphQL without talking about APIs. If you're new to programming, this is for you. Otherwise skip this section.

MuleSoft have a great video talking about APIs and they use the following metaphor:

An API is the messenger that takes your request and tells the system what you want to do, and then returns the response back to you. Think of an API as a waiter in a restaurant. Imagine you’re sitting at the table with a menu of choices in front of you, and there’s a kitchen that will prepare your request for you.

What’s missing is the critical link to communicate your order to the kitchen, and deliver your food back to your table. That’s where the waiter, or API, comes in. The waiter is the messenger that takes your request and tells the system, in this case the kitchen, what to do. And then delivers the response back to you, in this case food.

What is it?

Now we're familiar with APIs, it will make a bit more sense when I say that GraphQL is a query language for APIs.

Query languages are used to get data - you'll probably already know of SQL, that's another query language (it lets us access data from a database). GraphQL doesn't work with databases, but instead it lets us access data from an API.

Why not REST?

To get to grips with why it's useful, it makes sense to consider the problems that fuelled its development.

REST architecture (Representational State Transfer), was developed in the 90s as a way to improve the efficiency go comms systems. It let us transfer XML or JSON data and gained popularity super quickly.

As the applications it was used for gained complexity, the more problems started appearing.

Firstly, with REST, different resources are fetched from different endpoints. This means that when there is a need for a lot of different information, there'll be A LOT of endpoints. This can make our code messy, repetitive, and difficult to maintain.
With this came the problem of over and under-fetching. Over-fetching is when you fetch too much data and then don't use all of it. Under-fetching is when your fetch doesn't return all of the data you need, so you have to make another fetch request.

GraphQL was designed to eliminate those problems. It's done a pretty good job of it and is now commonly used by companies that handle large data and need to have access to complex data structures - companies like Facebook, Netflix, AirBnB, and Twitter.

The fundamentals

When making an application with GraphQl, there are two parts to consider, the client and the server.

GraphQL exists as a layer between the two. The client side will render the UI and in doing so, will use GraphQL to request data from an API. GraphQl then decides what to return.

Requesting data is called a query and its like a HTTP GET request. Requesting to update or change the data is a mutation, and its like a POST / PATCH / DELETE request.

The server receives requests from the client and either fetches and returns the data from a query, or makes some changes to the data and returns it as a result of a mutation request.

And that's essentially it. Of course there are a million ways to make this more complicated, but this is a basic outline of how it works.

Apollo? Relay?

If you google anything to do with GraphQL, you'll usually find yourself somewhere in the Apollo docs. In fact, a lot of the time you'll probably find the Apollo docs more informative than the GraphQL ones, but that's a complaint for another time. Let's talk a little bit about Apollo.

As well as being a query language, GraphQL is a specification, it describes one way of accessing data over the internet. You have to write a different sort of GraphQL code on the client than on the server and a lot of developers find this annoying. So, there are libraries like Apollo, that implement the GraphQL standard to write both client and server side code.

Apollo is an implementation of the GraphQL specification. It comes bundled with Apollo Server, Apollo Client and a bunch of useful modules.

There are other implementations of GraphQL too. Relay, like GraphQL, was developed by Facebook. Implementations such as Relay and Apollo provide great additional features, but it's a good idea to get to grips with the basics before using a library.

Fin.

I hope this has been helpful! In my next post, I'll talk about the basic building blocks of GraphQL - schemas, types, resolvers and so on.