From GraphQL Zero to GraphQL Hero with RedwoodJS

♪♪ ♪♪ ♪♪ Hey, everyone. Tom Pressenwurter here with a simple question for you. What's the easiest way to get a GraphQL API up and running? We all love GraphQL, but it can feel a little daunting sometimes to get a project going. And here's another question. Can it be easy and maintainable? Can you keep things in an orderly fashion over the long term? Well, that's where Redwood.js comes in. Redwood.js is a full stack app framework, perfect for everything from rapid prototyping to building startups. I've been working on it for the past two years, and I think it's become something really useful, both on the front end and the back end.

Let me show you what a Redwood.js application looks like. On the front end, we have a web application, single page app, React-based. And on the back end we have a Node.js based API written in JavaScript or TypeScript. The front end talks to the back end using Apollo Client and speaks GraphQL to the back end where we use GraphQL Helix and Envelop to create the GraphQL server.

In your business logic, you'll use Prisma to talk to a database. While Redwood.js provides the front end and the back end, today I'm gonna focus mostly on the back end and creating the GraphQL API. So let's go look at some code.

Okay, so the first thing I'm gonna do is create a new Redwood.js app using yarn create Redwood app, and I'm gonna make a simple music app. So I'm gonna call it tracks. This is going to fetch all the dependencies. Run yarn install, et cetera. Usually takes a little while, so let me speed that up for you. There we go. I'm gonna go into that directory and I'm gonna open up VS code from there. First thing I'm gonna do, I'm gonna grab a terminal window here and I'm gonna make this a git repository so you can more easily see what files I'm changing.

Okay, so here's a Redwood.js application folder structure. We've got the website that I talked about the front end and we've got the backside API. And in here, we can find in the DB folder, schema.prisma. This is the Prisma schema file that's gonna tell us what our database looks like.

There's some sample data in here. For me, I want to have an artist table and that's just going to have a name that is a string and I'm also gonna have an album table that will contain album information. That's gonna have an ID, that's an int, it's an ID and it'll be auto-increment and it's gonna have a title that's a string and it's going to have a number of likes, that's an int.

Now, I want to be able to connect these two so that my artists can have multiple albums. So, I'm gonna say, I'm gonna have an album and that's going to be album array. When I save this, boom, we get some nice things that Prisma does for us. So it'll connect these two for us and I'm just gonna rename what it calls this and I'm gonna say it's always gonna have one of these connections. So, that's it for now, just an artist and a number of albums as the schema.

Now, let's boot up our application so that we can see what it looks like. We haven't really done much yet. The schema doesn't actually exist in a database yet but just boot up the application, we'll run yarn redwood dev. This is going to start both the backend and the front end so that we can see the full application connected and we'll be mostly interested in the backend in this talk but it's useful to know that the front end exists. So here's the front end. Right now, it's just a placeholder. The backend lives on 8911 port slash GraphQL and in here we can see the schema of what's already there. So far, there's not too much. Some scalers, some introspection stuff. There's really not much going on yet as we would expect.

So what do we wanna do next? We have our schema. We need to actually put that into a database. So let's run a migration to do that. So I'll run YARN Redwood Prisma because we're using Prisma. Migrate-dev and that's gonna take our schema, it's gonna look at what changed and it's gonna create a migration for that and put it in a migrations folder that will appear here in a second once I give it a name. And here it is. So I'm gonna say add artist and album. So now it will create this migrations folder for us.

This allows us to easily then deploy these migrations into a production server eventually. And so now we have the schema established inside the database.

Okay, great. But it's not very interesting until there's some data. So we can put some data, some sample data into the database using this seed file here. I've handily got some seed data over here. So I'm just gonna wipe out this file. I'm gonna paste in mine. This is just a bunch of sample data that it's gonna input in there. And I can put that into the database using yarn redwood prisma db seed. So that'll run that file and just enter that sample data into the database so that we can play with it. So there we go. That's done.

And now we need a way to look at the data. And wouldn't it be handy to have some GraphQL functions to be able to list out and maybe create new ones. Luckily, Redwood JS has exactly what we need. And so we'll run yarn redwood g for generate, and we're gonna create a scaffold, which is going to be the stuff on the front-end and the back-end in order to create the CRUD operations that'll get us started. Then we can modify from there. So I'll create a scaffold for artist, and I'll create one for album.

And now once we have those, let's look over in our GraphQL again at our schema. You'll see now that there's a bunch more stuff in there. So we have a bunch of queries around albums and artists, as well as creating and deleting and updating. So let's run of one of them and see what we got. Let's look at albums and we can say, give me the title and the number of likes, execute that and here we go. Now we've got a bunch of albums in the database that we can play around with. And we've got GraphQL functions in order to be able to see all of that stuff all in a couple of minutes. This is really what it is to work in the Redwood world. Like we try to make all of this stuff super easy. We really focus on developer experience, getting you to where you wanna be as quickly as possible. Okay, that's all fine and good.

You've got your schema, but what did we generate? Is that stuff any good? Well, let's go look. So let's look in the source GraphQL albums. And in here we find the SDL. The GraphQL Schema Definition Language that represents what our GraphQL API looks like. So we see the album type, we have some queries and we have the other stuff that you've already seen in the schema.

Similarly, we have another file where the artist is defined. And indeed you can use types across these things. We stitch them together for you. So we make this part of creating a GraphQL API very easy. Really excellent organization. Everything's in its place. Everything is separated exactly where you want it to be.

So how are these implemented? Let's look in services. A service is a chunk of your GraphQL API split up by functionality. And so here we can see, again, let's look at albums, albums.js. And in here you'll see a bunch of regular functions exported. They each take arguments, perhaps. And this will look familiar to you. It looks very similar to what you might put in your resolvers, if you're creating one big giant resolver object.

The nice thing about Redwood.js is that we will automatically map the names of your queries and mutations in your SDL file to JavaScript or TypeScript functions that are exported. So, for instance, in the SDL, you have the albums query, and in the albums.js service implementation, you have an albums function. And this is how we match them up. So we simply look for exported functions of the same name, and that's how we map them. And you'll see why this becomes important later on.

So, okay, here's the implementation. These are simply schema, or sorry, Prisma calls that you make, simple stuff, not too complicated. And if you want to change this stuff, you can go in and customize this to your heart's content. If you want to get rid of the ability to create an album via GraphQL, you can simply delete this implementation, delete the statement from the SDL and you're done. Now let's look at what it looks like to create another query. So let's go into albums and say, I want to have the ability to find popular albums.

So I'll create a new query called popAlbums, and it's going to return an array of album, and none of those will be null. And I'm going to add this require auth directive on it, which I will show you what that's for later on. It's underlined here because it says service not implemented. So we have some nice things that we do in VS Code to help you out. And one of these is to let you know that, hey, you define this in the SDL, but you haven't written the service for it yet.

Okay, great. So let's go write the service implementation, the resolver for this. It's gonna look a lot like albums. So let's export const popAlbums, and that's going to be a function, no arguments. And it's going to return the DB of the album table. I'm gonna find many of those. And I'm going to, let's say we want to order all of the albums by likes, in reverse, descending, and then take the first 10 of those. So with Prisma, we can say order by, likes, descending, and take the first 10 of those. So let's save that. And let's go over and see if that's now available after the server reloads. So we should expect to see pop albums, and indeed, there it is. And let's get back the title and the likes, execute that. And so here we go. Now we have some albums, and the likes are ordered by descending order. And let's see, there's only 10 of them. So great. We've implemented a new function, a new GraphQL query. As easy as that, it makes sense. We export a function. It's very easy to sort of separate it from all of the other ones. And it's as easy as that. So this is the magic of Redwood that you've seen so far. As easy as that to get your GraphQL API up and running, add something to it. Now let's go a little bit further. Let's say I want to add a new service and add something on that, right? But I'll do it by hand this time.

So in our GraphQL, I'm going to add something. I'm going to call it info. It'll be our info service. And in there all we have to do is we, just like the other ones, export a const, it's called schema. And it's going to be GQL, GraphQL. And in there, we have our query type that will extend. And I want to create something that's going to give us back a single album, the most popular album. So I'll call it the top album. And it's simply going to reply with a album and I need my required auth directive.

So let's save that. It's the error, no implementation. So let's give ourselves a little quick shortcut here. And this is going to create the implementation for us and stub it out now in the info service. I'll clean this up a little bit, no arguments. And so you remember how those functions that the resolver functions are now just regular JavaScript functions. Well, that means we can import them. So let's import pop albums from the album service. And because we already have that available, let's just pull the first one off of there. So let's get all of the popular albums. We're going to call that, we have to go wait on it because it's async. And then let's return albums zero and let's just return the first one. And of course we used to wait. So we have to make this function async. So let's save that. And now we would expect after the server restarts that we will have a new query called top album. And so let's see what the title and the number of likes are in there. Oops, likes, plural. So here we go. We've got 9808 likes, that's the top album just as we expect. So that was pretty cool, right? So we can import those resolver functions and use them other places in services. So it really gives you a way to separate out your backend functionality, your business logic in a logical way, which gives you long-term maintainability and makes it really easy to look at and understand what's going on.

Another cool thing about GraphQL is that of course, you can traverse things. So let's say we want to know who the artist is and get their name, we can execute that. Boom, there's their name. And of course we can go deeper. We can say, maybe I'm on my homepage and I want to show the top album and recommend to you some of the related albums. So I'll say, okay, well, what are your albums of this artist? And I want the title and the number of likes so I can display those on the homepage. And it appears that I named this thing incorrectly. Actually called album. Okay, so here we go. Now we can see the related albums. Don't you love GraphQL? So cool, isn't it?

Let's talk about those directives that we saw. So remember albums and the require auth directive. Well, let's see what that does. We in Redwood land, we call these secure services. That means that out of the box, every GraphQL query and mutation that you do is gonna be secured by default. Now, we haven't installed any authentication and Redwood.js makes it really easy to add third party auth integrations like OAuth or Netlify Auth. Or you can roll your own and have it stored in your own database. And we have an entire functionality called dbouth to do that.

So when you do that, require auth will actually start doing something. Right now, it will just allow everything to come through as you've seen here. There's no authentication necessary. Well, let's look at how require auth is implemented. And that's up here in the directives folder. So require auth comes in, it says, here's what it looks like in the SDL land, this gets merged in. And this is a validation directive, which means it's going to either accept or reject your access. And in here we're calling this application require auth, which is up here and it just pulls something from source lib auth, this require auth. So let's look at that. Source lib auth. And in here is require auth and it calls is authenticated, which just returns true. So if we come in here and we say, well, instead of doing that, I'm gonna fake being an authentication service. What if I'm not authenticated and I'm gonna throw a new authentication error and it's just gonna say, nope. Okay, so now we will expect that our queries aren't gonna work. Now we forced that there is no, everything is unauthenticated. So let's try running this again. And here we go. Nope, unauthenticated, and now nothing that uses require auth is gonna work. So let's say we wanted to get album and get the title and the likes. Nope, GraphQL says nope, right? Because it's behind require auth. Okay, well, what if we don't want authentication? What if this query is on the homepage and you don't need to be authenticated? Well, that's why we have another directive called skip auth. So albums query, let's tell it that it can skip auth now because it's publicly available.

So albums query, let's tell it that it can skip auth now because it's publicly available. So now let's run that query. Hey, there we go. It works again. So authentication can be built right into your SDL files. You have it available on a very fine grained basis by query and you'll see it on mutations. And that then is integrated with all of our authentication techniques, making it super easy.

So what if you wanna create your own? There's another type of directive called a transformer directive. And I'm gonna show you what that means. So let's generate one. Yarn redwood generate directive. And let's say I want to, if you have a subscription to my service, then you're gonna get all the data you want. But if you don't have a subscription, then I wanna limit the number of records that you can get back. So I'm gonna call this a sub-limiter because it's a subscription limiter. So sub-limiter. This is going to then generate a new directive. I have to tell it I want a transformer directive. It's gonna generate a stub for me. And here it is. So, I mean, this is a real implementation. It's got a bunch of comments in here, but the bulk of it is, there's a transform, it receives the result value as it already is, and it lets you modify it. So in here, instead of pretending this is a string, which mine will not be, mine will be arrays, I can say, I wanna slice it and restrict it to only three items. Now, this is gonna do it for everyone. If I had some more logic in here, I could say, if context.currentUser, because this is, you can always get the current user, the authenticated user by calling context.currentUser, . something, something, something has subscription, et cetera, that I've implemented, then that would be how I do that here. I don't have that. This is just gonna always restrict. Where am I gonna use that? I can use that on an albums, on my albums query. I can say, instead of giving it all to you, I only want it to be available for subscribers. Here we go.

Add the sum limiter directive onto the albums query, and now, instead of getting all of the albums, of which there are about 100, I will expect this will be restricted to three. And so there we go. I can take certain bits of implementation and I can slice them in different ways and I can attach them v the SDL where that makes sense, which is really handy and can really clean up your code.

Instead of putting all of that in the services file for every single thing and replicating it all over, here it is just in the SDL. And what's really great is I can copy that and I can say, well I want that to be true also for popular albums. Guess what? You only get three. So I can put it on there and now I can say pop albums and we will expect that indeed I, I'm still unauthenticated there cause I didn't skip off, remember? So skip off. And now that's a public query that I can make. And let's see if it worked over there too. Let's execute that. And here we go. Now I only have three albums that have been returned.

And unfortunately that's all the time I have today, but this goes much, much deeper. We make it easy to test each of these functions that you create because they're isolated. You can unit test them very easily with the tests that we generate for you here. We have advanced features like depth limiting to avoid people abusing your service, all of the secure by default functionality, logging integration and even caching coming very soon. So if you like, what you've seen and you want to learn more, go to redwoodjs.com, check it out, follow our project on Twitter at redwoodjs. And if you want some free stickers, which I know you do, go to redwoodjs.com, and sign up for some free stickers. Thanks for listening.

What do you think about these answers here? Is this what you expected or? Well, let's see. I was hoping that a lot of people hadn't heard about Redwood so that they could now have heard about it and answer that they had in the future. So let's see, never heard about it. Yeah, 30%. I heard about it, but never tried it out. That's actually amazing. I like to keep track of how much Redwood is in the public consciousness, are we getting the word out? And so, this is great, this is actually, I thought it might be lower than this, but this is amazing. I mean, like, the hearing about it is the first bit. Tried it out or using it on a project, 0%. Well, there's nowhere but up from there. We're a young project, so I think that this is, I mean, this is exactly where we wanna be when it comes to this stuff.

We wanna be where people have heard about it, and now they can go to the next step. Exactly, I think these are good stats. Some of them have never heard about it, so now they have, and now they can try it out and go from there for sure. Exactly, exactly.

Yeah, let's go to the audience with some Q&A, and I'll remember, audience, if you have any questions for Tom, go ahead and put those in the Andromeda Q&A in Discord, and we'll answer those right now. We do have a couple of questions already here for you, Tom.

First one is, is Redwood open source? Yes, Redwood is MIT licensed and free to use, so the sky's the limit. Use it for anything you want. Make it your own, change it. We love contributions, obviously. We have over 250 people who have contributed to the framework already. We've actually been working on it for several years, so it's become fairly mature, but it's still pre 1.0. Though a 1.0 is coming very soon. We're in the release candidate phase now, and so we love contributions. That's why it's open source. I'm a big proponent of open source. It's helped me out a lot in my career, and I've always enjoyed participating in open source, so absolutely, MIT licensed, free to use.

Awesome, yeah, I love open source as well. What about the production capability? Is it ready for production use? Well, it's not quite 1.0. Like I said, we're in the release candidate phase now. We just entered that about a week and a half ago, and so it's quite stable. There are still some bug fixes that we'll do. We intend to be in release candidate phase probably until February or March of next year, so a couple of months as we work through bugs and just make sure that the first user experience is really top-notch. We have an amazing tutorial that if you're interested in what you saw today, go to redwoodjs.com and breeze through the tutorial a little bit, and you'll learn a lot more about not only the backend, but the frontend as Redwood is a full stack web application framework. It's not just the GraphQL side that you saw today. It really it has a full web application side as well, and so we work very hard on that, and we should in a couple of months be 1.0, which means I would say absolutely, yes, use it in production. Though there are startups, funded startups today are building with Redwood and in production, so it can be done.

Amazing, awesome. Well, speaking of that, like you showed off a bunch of really cool stuff. You made it look so easy on the backend.

What about the frontend though? What is that like and what are the strengths with the frontend? So Redwood is right now React based frontend, and we do a lot of work to integrate the frontend and the backend. So we have a feature that we call cells, which is a declarative way to do data fetching. So once you have your GraphQL backend on the frontend, if you wanna do data fetching to get data and then render a React component, use what's called a cell, and you just say what your query is, and then you say what you wanna happen, what component you want to be rendered when you're in a loading state, when you're in a failure state, when you have an empty result set returned, or when you have a successful return, you just list out what those components would be, instead of having all kinds of conditionals that you have to wade through in your code base, it makes it a lot easier to manage, and it allows us to get into the lifecycle so that in the future, we can do even more interesting things and optimize that data fetching flow, but that's one of many things that we do.

We have pre-rendering capabilities, so in your routes file, you can just say you want a specific page to be pre-rendered and then at build time, we'll pre-render that page so that statically available, which is great for SEO and performance, and then it will be hydrated on the client and presented to the user. And this is just a few of the features that we have. You can go to the website obviously and check out everything that's there. The tutorial covers all this stuff really well. So if you're intrigued, definitely go through the tutorial. That's the number one thing that you should do if you wanna learn more.

Yeah, it sounds very interesting and it sounds like it solves so many issues that other frameworks might have or they're trying to solve for as well. And speaking of that, what other full or how does Redwood compare to other full stack frameworks? And Metin specifically wants to know, are there any that you're afraid of? So we live in the same space as I suppose, Next.js, obviously very popular, is awesome. It's an amazing little framework. Now it doesn't bring much more to the table. Like there's a lot of things that work with it, but you're gonna be doing most of the work yourself to integrate those things. And so compared to Next, Redwood integrates a huge suite of tooling, Storybook is included by default, you don't have to set that up, it's fully integrated. Jest, testing, integrated. GraphQL on the backend, integrated. All of these tools that you're gonna eventually want to add if you're building a project or building a startup are already there with Redwood. So that's the biggest difference when it comes to something like Next. Now there's other frameworks that are more full stack being built as well today. Things like Blitz.js, which is built on top of Next, adds full stack backend capabilities. They also integrate Prisma from the database side, but it's built in more of a Next context. So if you're into Next, that's one to check out. And then there's also Remix, which has recently been open-sourced and is taking a bit of a different stance there. Now neither of these other two are leveraging GraphQL. So if you're watching this conference, I'm guessing that you're into GraphQL. And so if you wanna use GraphQL as your transport protocol from your front end to your backend and make it easy to add additional clients as you go forward, a mobile client or a command line client or what have you, then Redwood is gonna be super optimized exactly for that case. And a big reason to choose Redwood will be for GraphQL, which none of the competing ones will offer you.

Nice. So you mentioned that the front end uses, or you said right now the front end uses reactive, are there plans to maybe change that to something else or maybe incorporate other front ends like an Astro type of thing? Yeah, so from the beginning, we've intended for Redwood to be a multi-client kind of an architecture, which is why we use GraphQL. One of the things that we can do in the future because of that is very easily add other client rendering technologies. So you could imagine that in addition to a React-based front-end website, we could have a View or a Svelte-based front-end website that still just consumes the same GraphQL back-end and indeed you could use multiple of those if you had different sites that you wanted to deploy using different front-end technologies over the ages or really it's no different than having a React-based, like a React Native mobile app side which we would love to add sometime and once we get to 1.0, we'll start looking into what of these other technologies people are interested in us working on and making those things much easier to integrate with your GraphQL back-end as well. So the sky's the limit when it comes to front-end technologies.