Instant Serverless GraphQL Backends

♪♪ ♪♪ ♪♪ ♪♪ ♪♪ Hi, I'm Jamie, Developer Advocate at Graphbase. In this short presentation, we are going to have a look at how you can add a graphql backend to your frontend application. We'll be using a service called Graphbase throughout this video. It allows you to go from schema to api in only a few short steps. Using the schema-first approach, you can build and deploy a backend only by writing your graphql SDL. Connect this to GitHub, and Graphbase takes care of the rest. There's so many different features that I encourage you to go and check out, but in this video, we'll explore some of them. And at the end, we'll use a user management platform to authorize requests to our Graphbase backend. There are many other things that we're working on at Graphbase, and we'll soon allow you to bring in other data sources to work with your backend. So let's dive on in. Here I have a next.js application. I'm going to use the mpx command to initialize a new Graphbase project in the root of my next.js project. So this shows how you can add Graphbase as a backend to your existing project. Here we can define all of our models using graphql SDL. We use the custom directive model to tell Graphbase to generate an api for us, and then we can use the scalar types and other directives, such as unique here, and in this case, for the URL of a post, we can use an opt-in to further validation with the URL scalar. We can then go on to add relations between our models, and then we can run the mpx-graphbase-dev command to run a local Graphbase api on localhost 4000. If we open this up and we have a look at the schema and the documentation, we can see all of this was automatically generated for us from the Graphbase CLI. And all of this works locally, and it gives you an api to create, update, delete, and read data. So in the case here we are creating a new post, we can provide a custom URL, and we can get that data back. If we try to create this again, we can see here that the URL directive and the add unique directive have kicked in. We're not able to create a duplicate post with that same URL because we said it was unique. Now let's go on to create another post, and this time we'll create an inline comment as a relation when we create a new post. So here we'll give it some text, and we'll submit that mutation. Next, let's create a new comment, but this time we'll take the ID from an existing post, and we'll now link this comment when we create it. Now let's have a look at fetching all of our posts using the collection query.

We can opt into using the pagination, and for each of our nodes, we can get the fields that we like. We can take this a step further by fetching the related comments of a post, which also supports pagination. Finally, we can retrieve singular records for our data in our back end by using the ID or any unique field. Let's take the ID of one of our posts, and we'll now use the mutation to update. We can update using the ID or, again, using that unique field, and here we can provide a new title value for this post. Now if we update our query when fetching all of our posts, and we get the ID of a comment, we can now use the mutation that's generated automatically to delete one of our comments. So we can provide either the comment ID, or if we had any unique fields, we could provide that inside of the arguments. Next, let's create a GitHub repository and push all of our code to GitHub. Once we've deployed the code to GitHub, we can then sign in to GraphBase using our GitHub account. Then we can search for our repository, and we can connect and create a new project on GraphBase. And this wouldn't be a SaaS app if there wasn't confetti. We can then explore the dashboard inside of GraphBase to explore the current schema and the playground where we can create and update data that's happening at the edge. Now let's imagine we want to add the ability for users to vote on certain posts. Well, I could update the UI and the back end at the same time in a branch. Then I can commit all of this code to GitHub and open a pull request, and automatically, GraphBase will deploy a unique preview environment for that specific branch. So here I can work with data that's scoped only to that branch, so I'm not affecting anything that is in production, and I can safely work and show all of my colleagues to make sure that the voting functionality works as we expect. So here we can see we are querying and mutating some data inside of our back end that's in that isolated branch. Then once the team's happy, all we need to do is merge and approve that pull request, and GraphBase will take care of deploying this to the edge. GraphBase also comes packed with many other features, things including authentication, authorization, permissions, and custom directives for trailing any updates to queries using the new live directive. You can connect GraphBase to almost any user management software using JWTs or any OpenID Connect providers to automatically handle and authorize requests sent by users or groups of users. So let's check that out. Let's create a project with Clerk. We'll give it a name of graphql Galaxy. We'll allow passwords for our authentication type, and we'll create the project. Now that's created, we'll create a JWT template for GraphBase, and here we can configure many things, including the group-based authentication strategy.

You can find out more about GraphBase at graphbase.io.

Let's install a few dependencies, including apollo Client, so we can make a request from our index page on our application, and we'll configure the Clerk provider using the next.js hooks. Now we'll create our pages for sign-in and sign-up for accounts with Clerk. Thankfully, Clerk takes care of all of this by providing ready-to-go and ready-to-use components that we can embed inside of our application.

So now we've added those, we can just configure a few more things, including our environment variables, so our front end knows how to communicate with Clerk and GraphBase. Let's run both our local CLI with GraphBase dev and also our next.js application. We'll create a new account with our email, and then we can update our index page to create a query that calls to our GraphBase back end. If we head to the index page, we should see that the query is running successfully because we are signed in, and we are sending a valid authorization header. This token is generated from Clerk, passed to GraphBase, and validated.

But if we update our schema now to only allow the delete operation, if we go back to our application and try to run the query to fetch all of our posts, we now should see that there is an error. If we inspect this error and have a look into why, we should see that the operation for the list type is no longer valid. Hopefully this very quick video has given you an idea on what back end to use for your next project. Check out graphbase.com where you can join the private beta for free today. Thank you. ♪♪♪