We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
From GraphQL Zero to GraphQL Hero with RedwoodJS
AI Generated Video Summary
Tom Pressenwurter introduces Redwood.js, a full stack app framework for building GraphQL APIs easily and maintainably. He demonstrates a Redwood.js application with a React-based front end and a Node.js API. Redwood.js offers a simplified folder structure and schema for organizing the application. It provides easy data manipulation and CRUD operations through GraphQL functions. Redwood.js allows for easy implementation of new queries and directives, including authentication and limiting access to data. It is a stable and production-ready framework that integrates well with other front-end technologies.
1. Introduction to Redwood.js
Tom Pressenwurter introduces Redwood.js, a full stack app framework for building GraphQL APIs easily and maintainably.
♪♪ ♪♪ ♪♪ 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.
2. Redwood.js Application Overview and Setup
Tom Pressenwurter demonstrates a Redwood.js application, with a React-based front end and a Node.js API on the back end. Prisma is used for database communication. He then creates a new Redwood.js app called 'tracks' and sets up the development environment.
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.
3. Redwood.js Application Folder Structure and Schema
Here's the Redwood.js application folder structure with the front end and backside API. The Prisma schema file defines the database structure, including an artist table and an album table. We can connect the two to allow artists to have multiple albums. To see the application, we'll run 'yarn redwood dev'. The front end is a placeholder, and the backend lives on port 8911. We'll need to run a migration to put the schema into the database.
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.
4. Adding Data and Generating GraphQL Functions
We can easily deploy migrations into a production server. Now we have the database schema established. We can add sample data using a seed file and the 'yarn redwood prisma db seed' command. Redwood JS provides GraphQL functions for listing and creating data. By generating a scaffold for artists and albums, we can perform CRUD operations. The GraphQL schema now includes queries for albums and artists, as well as create, delete, and update operations. With Redwood, we can quickly work with data and focus on developer experience.
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.
5. Implementation and Creating Queries
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.
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.
6. Implementing 'popAlbums' Query
To implement a new query in Redwood.js, create a function that returns the desired data from the database. In this case, the 'popAlbums' query orders albums by likes in descending order and returns the first 10. Redwood.js makes it easy to separate and manage functions in the GraphQL API. This is the simplicity and magic of Redwood.js, allowing you to quickly build and add functionality to your GraphQL API.
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.
7. Adding 'info' Service and 'top album' Query
In our GraphQL, we add an info service with a schema that extends the query type. We create a top album query that returns the most popular album and requires authentication.
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.
8. Implementing 'top album' Query
We can import resolver functions and use them in other services, separating backend functionality and improving maintainability.
9. Traversing and Retrieving Data in GraphQL
In GraphQL, you can traverse data to get specific information. For example, you can retrieve an artist's name or explore related albums. This flexibility allows you to easily display relevant data on your application's homepage. Despite minor naming errors, GraphQL's ability to traverse and retrieve data is impressive.
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?
10. Understanding the require auth Directive
Let's talk about the require auth directive in Redwood.js. By default, every GraphQL query and mutation is secured. Redwood.js allows easy integration of third-party authentication services or the option to roll your own. The require auth directive is implemented in the directives folder and uses a validation directive to accept or reject access. The require auth function checks if the user is authenticated. If not, an authentication error is thrown. To bypass authentication for specific queries, the skip auth directive can be used.
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.
11. Implementing 'sub-limiter' Directive
You can build authentication right into your SDL files. Redwood.js provides a transformer directive called 'sub-limiter' that allows you to limit the number of records returned based on user subscription. By implementing the transform function, you can modify the result value. This directive can be used on the albums query to restrict access to subscribers.
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.
12. Implementing Sum Limiter Directive
Add the sum limiter directive to restrict the number of albums returned. Easily test functions with generated tests. Redwood.js offers advanced features like depth limiting, secure by default functionality, logging integration, and caching. Learn more at redwoodjs.com and follow us on Twitter at redwoodjs. Sign up for free stickers!
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.
Redwood.js Open Source and Production Capability
Redwood.js is MIT licensed and free to use. It's still pre 1.0 but in the release candidate phase. It's quite stable, with bug fixes ongoing. The first user experience is a priority, and there's an amazing tutorial available on redwoodjs.com. Redwood is a full stack web application framework, not just GraphQL. It's suitable for production use, with funded startups already building with it.
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.
Redwood.js Frontend Features
Redwood.js has a React-based frontend with features like cells for declarative data fetching, making it easier to manage and optimize the data fetching flow. It also offers pre-rendering capabilities for improved SEO and performance. Check out the website and tutorial for more details.
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.
Comparison to Other Frameworks
Redwood.js differentiates itself from other full stack frameworks by integrating a suite of tooling, including Storybook, Jest, and GraphQL. It offers a seamless experience for building projects or startups. While frameworks like Blitz.js and Remix provide full stack capabilities, they do not leverage GraphQL. Redwood.js is optimized for using GraphQL as the transport protocol, allowing easy integration of additional clients.
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.
Redwood.js Front-end Technologies
Redwood.js is designed to be a multi-client architecture, allowing for easy integration of different front-end technologies, such as React, Vue, and Svelte. The goal is to provide flexibility in deploying websites or apps with various front-end frameworks, all consuming the same GraphQL back-end.
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.