DEV Community: Anna Collins

From Wordpress to Contentful

Anna Collins — Tue, 08 Sep 2020 19:48:07 +0000

So the situation might sound familiar to you. You work for a really cool tech company with a great product, using all the latest technologies. It’s all fun and games… until you have to work with the blog… written in Wordpress 😱. What’s the problem with Wordpress you might ask? It’s easy to use, has great SEO… Well, it’s only easy to use if you know how to use it, and not one of the developers in my company knows how 🤔. So when things start going wrong and you as a developer are asked to fix them, it’s not so fun. Not to mention the worry of security issues or scalability.

This scenario has been the case in both of the previous two companies I’ve worked for. And even though it’s a headache for developers, migrating the blog seems like such a huge project to tackle and due to a lack of resources and time, it’s just not high enough up on the list of priorities. At Typeform, thankfully, we decided that enough was enough, and we tackled Wordpress head on.

This is the blog in Wordpress that we are currently migrating: https://www.typeform.com/blog/

First things first, what did we actually need? We came up with a list of Must Haves:

A static site using Next.js to align with the stack used for other public assets.
Contentful as a CMS. We were already using Contentful for copies on the public website so the marketing team were already familiar with it.
The exact same design and functionality as the current blog.
The same customisation abilities as the current blog.
A similar editing experience to Wordpress.
The ability to preview content when editing.

And our blog needed to have 4 types of pages:

Home page
Article page
Category page (a list of all articles of a given category)
Author page (a list of all articles of a given author)

Contentful works by creating models for each entry type, so first of all we created a loose version of the models we were going to need. One for each of the pages Home and Article, one for a Category and one for an Author, with a home page referencing various articles and an article referencing a category and an author. We created some mock entries using the models so we could start fetching data in our Next.js project.

We also created models in the front end for each entry type to keep development easier and so we knew what each component was expecting in terms of props.

When we fetched the data from Contentful, we did it by page type, using the corresponding model to transform the data and then saved it in a .json file per page type.

Next.js generates routes out of the box based on what’s in the /pages folder at the root. Since we needed dynamic routing based on the data fetched from Contentful, we made use of the exportPathMap function in the next.js.config file (which overwrites the default) along with the files we generated from the Contentful fetch, to dynamically create our routes. Each route is provided with a page from the /pages folder which is to be rendered, along with a query where any data needed for the page can be passed.

Static pages are hydrated without their route parameters provided and after hydration, an update is triggered to provide the route parameters in the query object, so we are unable to retrieve the page data from the route query. Instead, we use getInitialProps in the page which receives a context object including the query, amongst other properties. The value returned becomes available as props on the page.

Great! So now we have all the data from Contentful and have generated a route for each page with the required data on each page available through its props. It’s time to start rendering components. As with most blogs, the structure of each article is the same except for the article content itself. We wanted to make the editor experience as similar to Wordpress (or a WYSIWYG editor) as possible, so for the article content field in the article entry, we made use of the Rich Text field type in Contentful. This field type allows editors to use different headings, font styles, links, bullet points etc. But apart from this, and more importantly, it allows us to insert other entries.

For example, in the section above, we have a paragraph with a drop cap and a quote with an avatar. Neither of these are possible in the native rich text field. We created separate entries for these content types and inserted them into the rich text as seen below.

In the article model in our Next.js project, for the article content field (the rich text), we transform the response using a RichText model which maps through all the blocks in the response and either returns the block itself if it is a standard block (not one of our custom embedded entries) or the corresponding model if it is a custom embedded entry (i.e. the drop cap for example).

We can then in our ArticleContent component for the article page map over these blocks and return the corresponding component.

One last thing to address are the standard blocks in the rich text. The response is not so easy to work with so luckily Contentful provides us with a package '@contentful/rich-text-types' which exposes a method, documentToReactComponents, that we can use really easily inside a component to transform the response json into HTML.

Et voila! We have all the data where it needs to be and we can now start adding any necessary fields to contentful and begin styling the page 💃

We set up 3 deployment environments for the project:
Production: This is a static bundle in s3 built on every push to master using Travis. The content fetched is all published content from Contentful.
Staging: The same as production except built on every pull request created.
Authoring: This is a SSR application deployed on every push to master hosted on Now. It contains all content, including draft content, from Contentful. Content is refreshed on every change in Contentful by a web-hook. This will enable the marketing team to preview their changes in Contentful.

So now for the fun part, the actual migration! Luckily using the Wordpress API and the Contentful API, we were able to fetch all articles and their content from Wordpress and run a script to create all the entries in Contentful and fill them with all the required titles, subtitles, slugs, images, metadata, author name, category color… everything except for the article content rich text as this was too complex to migrate via a script. But since we already have the entries created and the images uploaded, it's just a matter of copying and pasting the content from Wordpress into the rich text field, creating the odd custom entry and inserting the images into it. We migrated one and it took us 15 minutes to input the data and check everything else was OK, so for the 200, that’s around 50 hours work, quite a while but not so terrible. Also the Contentful API is pretty good and easy to use. Here's a simple example of how to add an entry, creating and linking its metadata entry to it.

So that’s where we’re currently at with our blog migration! We are pretty close to finishing it, just a few tweaks after speaking to the blog owner and then we plan to hire a contractor to migrate the rich text content. We will work on performance too when it’s all done, deploy a few of the pages live to check SEO is all ok, and 🚀 All in all I think it has been pretty successful, and not as much of a drama as one might at first think!

Slice Machine from Prismic

Anna Collins — Mon, 29 Jun 2020 08:00:00 +0000

In May my colleagues Aitor, Núria and I attended our first virtual conference, Jamstack Conf. Check out Núria's blogpost here on the virtual conference experience! Amongst other talks was a lightning talk by Renaud Bressand, a project manager at Prismic. If you don't know, Prismic is a CMS. We often use it in our JAMStack projects at Codegram so we were super interested to hear what they had to say. Prismic announced in the talk the release of their new open source project Slice Machine! Well it sounds pretty cool, right? Let's take a look at what exactly it can do for us.

So as I said, Prismic is a CMS where we can handle content for our websites. To look at a simple example, we could take an entry for a news article. We might know that every article has a title, a headline and a main image so we can add those fields to the article content type in Prismic, but what about the rest of the article? We don't want to restrict the editor to stick to a rigid predefined template. And we want to make the editing experience as visual and intuitive as possible. That's where Prismic slices come in. Enter Slice Zone...

Slice Zone is a section you can add to your content types to give the editor more freedom when entering content. You are able to define a number of different content types which the user can then select from, in the order they wish. Let's take our example of a news article. Maybe a news article can be composed of: text, images, quotes, videos, subtitles, tweets, CTAs etc. Slice zone lets the user select the types and input content in the order they wish.

So that's Slice Zone, what about Slice Machine? Slice Machine takes Slice Zone to the next level by making it super easy for editors to build pages made up of component sections without any help from developers. Prismic describe it as "In it’s most basic form, Slice Machine is an open-source CLI and a component library". Let's see how it works.

First of all we need to install the Prismic CLI

$ npm install -g prismic-cli

Currently Slice Machine is only available for Nuxt.js projects, so we'll also need to create one of those

$ npx create-nuxt-app annas-slice-machine

And now from inside the project, run the Slice Machine setup command

$ prismic sm --setup

This will connect the default component library and add dependencies (you will see these extra configurations added to your nuxt.config.js file along with a sm.json file). This command will ask you to login to an existing Prismic account or to create a new one and will create a new repository in the account with a standard "Page" custom type for starting out.

You can add the Slice Zone to an existing page but here we're going to create a new page _uid.vue with the following code

<template>
  <slice-zone type="page" :uid="$route.params.uid" />
</template>

<script>
  import SliceZone from 'vue-slicezone'

  export default {
    components: {
      SliceZone
    }
  }
</script>

The Slice Zone component has two props here, the type, which at the moment we only have the page type that comes out of the box, and uid which is the unique identifier for the page and will be the name of the route.

In your newly created Prismic repository add a new page type. You'll see here the Slice Zone and all the possible premade components you can add to your page. You can go on over to the storybook to see what these components look like. They've been created by Sara Soueidan and are accessible and responsive too!

Once you've added a uid and a slice for your page, you can run npm run dev and go over to [localhost:3000/uid-of-page](http://localhost:3000/uid-of-page) and see that a page has been created with the route of the uid you just added in Prismic. That was easy peasy right!?

So you might be thinking it's cool, but that you need more control over the design of your page. Well Slice Machine provides ways to customise the default library by using themes, allowing you to make small changes such as colors and text align. But better than this, it also allows you to easily create your own custom slices via the CLI

$ prismic sm --create-slice

This command will prompt you to provide the name of your slice, and the custom types that you want this slice to be available, for example the page type, which is currently the only type we have.

In your project a new folder slices will have been created and inside that a folder with the name of your new component containing two files, index.vue and model.json. Your new slice will also appear in the Slice Zone for the page type where you can update and add/remove entries from it via the Prismic dashboard. Due to still being in beta, you will need to update the model.json file manually but Prismic say they are working on a Custom Types API where you will be able to send custom types to the repo with a CURL request 🎉

We've only scratched the surface but I think Slice Machine could be a great tool for making developers lives easier and for giving more freedom and control to editors with JAMStack websites!

My journey into GraphQL (part 2) - Getting started with Prisma

Anna Collins — Fri, 28 Feb 2020 08:00:00 +0000

After learning the basics of GraphQL (see part 1 of my journey here), I got stuck in and started building stuff. Firstly, a small server using GraphQL Yoga, which made it super easy to get started! It’s built by the folks at Prisma who I’d heard great things about, so I wanted to find out what all the hype was about.

Prisma is an ORM. An ORM is a library which enables us to interact with a database from the server in a language of our choice. For example instead of having to write SQL to read and write to our My SQL database, we could use an ORM which would enable us to read and write to our database in JavaScript.

Prisma has all the abilities of other ORMs but it comes with some added extras. First of all it’s database agnostic. It currently supports Postgres, MySQL, MongoDB and Amazon RDS and they are working on support for a number of others including Elasticsearch, Cassandra and DynamoDB. You can read and write to your database in JavaScript, Typescript, Flow or Go. And the best part, it exposes your database as a GraphQL API, providing you with all basic CRUD operations and also GraphQL subscriptions. This means if we’re using GraphQL both between the client and the server, and between the server and the database, it makes the server really simple to write.

So let’s get started! Firstly you’ll need to install the Prisma CLI, which you can do from the command line with NPM $ npm install -g prisma. To run locally you will also need to have Docker installed on your machine. If you don’t have it, download the version for your operating system here.

Now we’ll need to create a database. You can connect a database you already have or create a new one. I’m going to set up a new one using Heroku since it’s really easy to use and for what we need right now it’s free. If you haven’t got an account already, sign up and then click on New in the top right and select create new app giving your app a name. When you are redirected to your app’s dashboard, click on Overview in the navbar and then for Installed add-ons click on Configure Add-ons and search for Heroku Postgres. For what we need we can select the free plan and once created, click to open Heroku Postgres and a new tab will open with your database dashboard. You can navigate to settings and view credentials for your database, we will be needing these in a moment to connect to Prisma.

We’re going to connect Prisma to a GraphQL Yoga server, so we will need to set up a server first. GraphQL Yoga is a server library and makes it easy to create a Node.js GraphQL server. It also provides GraphQL Playground, a GraphQL IDE that lets you interactively work with your GraphQL API. Create an empty project and run $ npm init. Create an index.js file where we’ll set up the server and install GraphQL Yoga $ npm install graphql-yoga.

To set up the server all we need to do is import GraphQLServer from graphql-yoga, create an instance of it, passing it the typeDefs and resolvers, and start the server. For now we can use a basic Hello World example.

const { GraphQLServer } = require('graphql-yoga')

const typeDefs = `
  type Query {
    hello(name: String): String!
  }
`

const resolvers = {
  Query: {
    hello: (_, { name }) => `Hello ${name || 'World'}`
  }
}

const server = new GraphQLServer({ typeDefs, resolvers })

server.start(() => console.log('Server is running on localhost:4000 🚀'))

Add a start script to your package.json file.

"scripts": {
   "start": "node index.js"
 },

And we’re good to go! Run $ npm run start and go to localhost:4000 to see the playground, the GraphQL IDE which allows you to interact with your server. You can explore the docs and schema using the tabs on the right, but for now we only have one query, hello.

Now to install Prisma in our project. Prisma is going to sit between our server and our datbase and we will be able to use the CRUD operations and subscriptions it provides to interact with our data, in our resolvers. Since we’ve already installed the CLI, we can run $ prisma init prisma, where prisma is the name we are going to give the prisma server in our project. Prisma will then guide you through a series of questions. We can select to use an existing database, select Postgres and then follow the steps to add your database credentials from Heroku. When asked to User SSL select yes and for the programming language for Prisma Client select Don’t generate as we are going to build the server ourselves. Here you could select a language and instead of writing your own schema and resolvers using Prisma to help, you could use what Prisma generates directly. Once finished, you should see the following new folder in your project.

prisma
- datamodel.prisma
- docker-compose.yml
- prisma.yml

We have three new files, a yml file with some default config, a docker-compose.yml file which will start up our docker container and contains the connection to our database and finally, the file we are going to be changing will be the datamodel.prisma file. Here we define our types for which Prisma will generate the GraphQL API to interact with our database and which also defines the shape of our database. Let’s imagine we are creating a server for a blog. Our schema could consist of 3 types, for example:

type User {
  id: ID! @id
  name: String!
  email: String! @unique
  password: String!
  posts: [Post!]! @relation(onDelete: CASCADE)
  comments: [Comment!]! @relation(onDelete: CASCADE)
  updatedAt: DateTime! @updatedAt
  createdAt: DateTime! @createdAt
}

type Post {
  id: ID! @id
  title: String!
  body: String!
  published: Boolean!
  author: User! @relation(onDelete: SET_NULL)
  comments: [Comment!]! @relation(onDelete: CASCADE)
  updatedAt: DateTime! @updatedAt
  createdAt: DateTime! @createdAt
}

type Comment {
  id: ID! @id
  text: String!
  author: User! @relation(onDelete: SET_NULL)
  post: Post! @relation(onDelete: SET_NULL)
  updatedAt: DateTime! @updatedAt
  createdAt: DateTime! @createdAt
}

Fields can be decorated with @id, @createdAt and @updatedAt which are managed and created by Prisma and are read-only. Prisma ensures anything decorated with @unique will be unique. Prisma also has a type DateTime for time values in ISO format.

You will notice that some fields are decorated with @relation and are passed a value for onDelete. This is to tell prisma how to deal with related data when deleting an item. There are two values, SET_NULL and CASCADE. SET_NULL means that Prisma should simply delete the item itself and CASCADE means that Prisma should also delete any related items. For example you will notice on type User, on fields comments and posts, onDelete is set to CASCADE because if a user is deleted, all their posts and comments should also be deleted. Whereas on type Comment, onDelete on the author and post fields is set to SET_NULL because if a user’s comment is deleted, it’s not necessary to also delete the post or the user.

Now we’ve got our types defined in our datamodel.prisma file, it’s time to deploy our Prisma server. First we need to start the docker container. Make sure Docker is open and running on your machine and then start your container by running $ docker-compose up -D from inside the newly created prisma folder. We can then generate and deploy our Prisma server. Stay inside the prisma folder and run $ prisma deploy. Once finished, your Prisma server is deployed to localhost:4466 where you can see all the operations created in the schema tab. You can use this url to interact with your database and explore the operations Prisma has created for us. After deploying you can also see the changes reflected in your database. A User, Post and Comment table have been created with the columns corresponding to the fields on our types. You can use a GUI such as PGAdmin to connect to your database and see these changes.

The next step is to connect Prisma to our GraphQL Yoga server. To do this we need to create an instance of Prisma and pass it the required config. Install prisma-binding, $ npm install prisma-binding and create a new file prisma.js at the root of the project. One of the properties we need to pass our Prisma instance is the schema for the API it has generated. We can see all the operations in the playground at localhost:4466 but in the datamodel.prisma file in our project, we only have the types defined. We need to generate the full schema including all these operations we see in the playground to pass to our Prisma instance.

To do this we need graphql-cli so download it in your project, npm i graphql-cli, then create a .graphqlconfig file to tell graphql-cli how to generate our schema and where to save it.

{
  "projects": {
    "prisma-blog": {
      "schemaPath": "generated/prisma.graphql",
      "extensions": {
        "endpoints": {
          "default": "http://localhost:4466"
        }
      }
    }
  }
}

Here we tell graphql-cli to use our project with the name we gave it when initiating, prisma, at the endpoint localhost:4466 and to save the generated schema in a folder calledgenerated at the root of our project. Create a script to generate the schema in the package.json file.

"scripts": {
   "start": "node index.js",
   "get-schema": "graphql get-schema -p prisma"
 },

Run $ npm run get-schema and you will see the new folder with the generated schema at the root of your project. If you take a look at this file you can see that it is much bigger than the file where we defined the types and it now contains all the operations we can see in the playground. We can now create the instance of Prisma and pass it the schema we just generated and the endpoint.

const { Prisma } = require('prisma-binding')

const prisma = new Prisma({
  typeDefs: 'generated/prisma.graphql',
  endpoint: 'localhost:4466'
})

module.exports = prisma

And in our index.js file we import and add our instance of Prisma to the context in the server as follows

const { GraphQLServer } = require('graphql-yoga')
const prisma = require(“./prisma”)

const typeDefs = `
  type Query {
    hello(name: String): String!
  }
`

const resolvers = {
  Query: {
    hello: (_, { name }) => `Hello ${name || 'World'}`
  }
}

const server = new GraphQLServer({
  typeDefs,
  resolvers,
  context() {
    return {
      prisma,
    }
  }
})

server.start(() => console.log('Server is running on localhost:4000 🚀'))

So that’s us all set up and ready to start using Prisma in our own resolvers. In our server we should continue writing typeDefs and resolvers as normal, except in our resolvers we can now utilize Prisma to make interacting with our database super easy. I’m not going to go over how to write typeDefs or resolvers in this post but I will show you some examples of how you can use Prisma. You can explore the playground to see which arguments your new operations are expecting.

We can now read prisma from the context, the third argument passed to the resolvers. A really simple example would be a query to fetch all users. We need to pass the info argument as this will tell Prisma what data we want back for the user.

users(_, __, { prisma }, info) {
  return prisma.query.users(info)
},

Another example is a createPost mutation resolver. We pass the arguments in first and then the info as in the previous example.

createPost(_, args, { prisma }, info) {
  return prisma.mutation.createPost({
    data: {
      title: args.data.title,
      body: args.data.body,
      published: args.data.published,
      author: args.data.authorId
    }
  }, info)
}

And a final example we could have a deleteUser query. Remember, since we added @relation to the fields comment and post on this type with a onDelete value of CASCADE, this operation would also delete any comments or posts of the user.

deleteUser(_, args, { prisma }, info) {
  return prisma.mutation.deleteUser({
    where: {
      id: args.id
    }
  }, info)
},

The Prisma docs are pretty good and here you can find the documentation on how to use Prisma to interact with your database. Prisma also has an integration with Heroku to make deploying your server really easy too.

So there you go. You’re all set up to start writing your server using Prisma and since your database interactions are now so easy, you can concentrate more on other things like authentication in your sever. Prisma would be a great option for setting up a server quickly or for MVPs and here at Codegram we plan to start experimenting more with it. From a first glance I think it seems really cool and I’m looking forward to using it in production 🙌

My journey into GraphQL (part 1) - GraphQL 101

Anna Collins — Tue, 14 Jan 2020 08:00:00 +0000

I’ve just started at Codegram as a junior developer and my first week has been mostly preparing for the first project I’ll be working on by learning some GraphQL 🙌. My work experience is almost all front end based, so this was a good chance to delve into the back end a bit, which I have been wanting to do for quite some time. The chance to learn new technologies and skills was one of the things which attracted me to Codegram in the first place and I was looking forward to getting stuck in!

So what actually is GraphQL anyway? GraphQL is a language used to query an API for data by stating exactly what data you want to get back. The difference between GraphQL and REST is that with GraphQL, the client asks for the specific data they need, and gets this data (and only this data) back, whereas with REST, this might sometimes require making multiple calls to the API to retrieve all the required data, whilst receiving a lot of unnecessary data at the same time.

Hmm, ok. Still not sure I totally understand the difference, so let’s look at an example. Imagine I have a REST API to interact with data on Burger restaurants in Barcelona. I love burgers and I want to fetch a list of all the restaurants’ names, with all the different burgers they have, and a list of the toppings on each burger. This may mean that I have to perform multiple calls, one to fetch a list of all the restaurants, /restaurants, then one for each restaurant to fetch a list of their burgers, /<restaurantId>/burgers , and then one for each burger to fetch its toppings, /<burgerId>/toppings. That’s quite a lot of calls, and I will surely receive unwanted data along the way, for example when I fetch the restaurants I might receive its address and rating, which I’m not interested in right now.

“So just create a new endpoint fetching the data you need in one call” I hear you say. Yes, this could be a solution, but it’s not really feasible to be pestering the back end folks for a new endpoint every time you need a different set of data, is it?

Let’s see how we could make the same call with GraphQL (getting back only what we ask for).In GraphQL we don’t have different endpoints, we make all calls to the same endpoint, only changing the payload we pass.

  query {
    restaurants {
      name
      burgers {
        name
        toppings {
          name
        }
      }
    }
  }

So the simplest version of a request is kind of like querying keys on an object. The returned value that we get is in the same shape as the request, so we know exactly what we are expecting in return. The shapes of the objects you’re able to query are defined in the schema, which is defined in the server. To create a GraphQL server, we need to define all the types and operations, and also what are called resolvers, which is how we resolve each operation, normally being interacting with our database.

For example in our case, we have three different entities, restaurants, burgers and toppings, so our schema for these would be defined something like this

  type Restaurant {
    id: ID
    name: String
    address: String
    rating: Int
    burgers: [Burger]
  }

  type Burger {
    id: ID
    name: String
    rating: Int
    toppings: [Topping]
  }

  type Topping {
    id: ID
    name: String
  }

As you can see, each property on each entity has a type. There are 5 scalar types to choose from:

Int: A 32-bit integer
Float: A floating point value
String: A UTF-8 character sequence
Boolean: true or false
ID: A unique identifier

Or it can be one of one of our custom types defined above (or an array of any of these types).

As well as defining the types we have, we must also define the operations that we can perform on our data. With GraphQL we have 3 different types of operation:

Query: A read only fetch. We can think of this as what would be a GET in REST
Mutation: A write followed by a fetch. We can think of this as like a POST, PUT or PATCH request in REST.
Subscription: Allows the client to subscribe to an event and receive real time updates from the server when there are changes. There is no simple REST equivalent to this operation.

For our burger API, we could for example define the following queries

  type Query {
    restaurants: [Restaurant],
    burgers: [Burger],
    toppings: [Topping],
    restaurant(id: ID): Restaurant,
    burger(id: ID): Burger,
    topping(id: ID): Topping
  }

We would also need to provide resolvers for each of these queries. This would usually involve reading from our database to return the required entry(s). I’m not going to go into detail here as I want to keep this post general and language agnostic.

You can see that the last three operations also take in an argument, being the ID of the entry you want to query. For example, if we wanted to query a specific restaurant, we could query by its ID to retrieve its name and the name of its burgers as follows:

  query {
    restaurant(id: 1234) {
      name
      burgers {
        name
      }
    }
  }

A new burger restaurant has opened in Barcelona, hurrah! 🎉 We now need to add it to our database. So we need to define a new mutation in our schema as follows:

  type Mutation {
    createRestaurant(id: ID, name: String, address: String, rating: Int): Restaurant
  }

The operation takes an ID, name, address and a rating as arguments and returns us the created restaurant when done. (Again, we would create a resolver for “createRestaurant” in our server, usually writing an entry to our database.) So let’s go ahead and add it

  mutation {
    createRestaurant(
      Id: "12345",
      name: "Anna’s Burger Joint",
      address: "Carrer Aragó 191",
      rating: 5
    ){
      name
      id
    }
  }

From the returned restaurant entry, we can select whichever values we like from it, in this example I have chosen to receive the name and ID.

As you may have guessed, I’m a huge burger fanatic, so I would love to be notified whenever a new restaurant is added to the database 😍. For this I could use the Subscription operator. I would create a subscription that returns a restaurant to the client listening whenever a new restaurant is added to the database. I’m not going to go into detail in this post about how subscriptions work as they are slightly more complicated than Query and Mutation. Rather than returning data directly, they return an AsyncIterator which is used to send data back to the client.

So after a first peek at GraphQL, I must say, it seems pretty cool! We have way more control over the data we receive when we make a call to our back end, and when we make the call we know the shape of the response we are expecting in return. This can be especially useful for example if you require different data across different devices or if you don’t know the use case. To use REST and simply creating different endpoints for each device is exactly the problem we are avoiding by using GraphQL. I can’t wait to learn more about it and start using it in real life projects ❤️

If you want to learn more about GraphQL, they have great docs so I suggest starting there. And if you can't wait to give it a go and start playing around making queries, you can try here with the Star Wars GraphQL API. Just click on the docs tab on the right and start exploring!