Rock Solid React and GraphQL Apps for People in a Hurry

Well, it's definitely been a minute since I started working with GraphQL. It's been about 5 years in fact, and in technology years that's quite a while. And when I was first starting out with GraphQL I didn't really care how long it would take to work on a project or get a graph QL app up and running. But these days I find more and more that I'm in a hurry with my projects and I want something that is faster to get going with and faster to maintain. And so that's what I'm going to talk to you about today, how to deal with react specifically and graph QL if you are in a hurry.

My name is Ryan and I do a lot of things around the Web. But one thing I'm very focused on today is course lifts and course lift is course hosting for people who want to have all of the mechanics of how to put together their course landing pages, how to put together their sales information, etc. Done for them so that they can focus on making their course and we help them sell their course. Check it out at course lift on Twitter if you're interested.

So going back to 2017, five years ago, when I started getting involved with graph QL, it was an awesome time because there was just so much energy in the community around graph QL. It was fairly new. I think that it dates back to 2012 at its inception but it was around this time in 2017 that people started getting really excited about it and that excitement was really palpable. This is me at GraphQL Summit in San Francisco. I got to do a talk there back in 2017 and there was just a ton of energy in the room about graph QL. People want to put it everywhere. People wanted to use it in all their APIs, from all their frontends, and you could really get that sense at the conference. It was around this time that I started working on a large project for a brand new client. I had been working for Auth0 at the time but I started to break out and go on my own, doing consulting work and I started to work on big projects that used GraphQL in this new case of this new project. It was around this time that I was really getting my footing with GraphQL. I was trying to figure out how to work it into this project and how to make it really good for the client in particular. What I noticed is that there were a lot of frustrations that came about as I started working on this project. I could bucket these into a few different categories. The first one is that it was kind of unclear to me at the time how to deal with different modules, how to separate parts of the API into different portions, how to deal with things like, okay, I want a user's module and then I want to have a module for some other resource. How to bucket those things off and then bring them all together in a cohesive way just wasn't really clearly established. And so, because there weren't these conventions in place, you were sort of left to figure those things out on your own. And so, I came up with a convention that worked in my project, but it definitely was quite bespoke and maybe wasn't the best way to do things. This led, I think, to a lot of repetitive and manual work. I'd be copying and pasting module folders over, changing names, and then having to import things into a main file. Put all that stuff up into a make executable schema in Node. And it was just this repetitive kind of manual task that I had to deal with.

And at that time, also, there were no really good frontend abstractions for your frontend backend author time integration. I remember that it wasn't really all that clear how to get information when you're working on the frontend as to what the backend could offer up in terms of resources or fields on your resources. And so this integration between your frontend query clients and your backend schema, it just wasn't all that well established at that time how to make those things work well together. So what this led to really was a set of bespoke and brittle solutions. I put together things that I thought worked well in the application and it turned out that these were a little bit brittle. So things like things breaking as I would add new modules, forgetting to import one of the new pieces of the schema into my main file where I make the executable schema. Things like having to deal with file uploads and authentication. All these different pieces of the application that are fairly standard in most places, just weren't all that standard in GraphQL at that time.

Things have definitely gotten better over the years. Adoption has grown. More and more large companies are using GraphQL and more developers everywhere are trying it out. I think nearly all the technical points of GraphQL have gotten better over the years. We've got better server libraries these days. We've got more of them in fact. We've got better ways to arrange these conventions across our projects. Tooling is better all around. We've got integrations from code editors and we've got integrations between front ends and back ends at author time now, which is great. We've got things like code generation, which helps to make modifications to our code in an easy way. And ultimately, type safety has really been a big benefit of all of this. Being able to know the types that are available on the GraphQL API and then being able to use those across the application stack has been really beneficial for author time type safety.

But I think there's still some room for improvements and I think that's because new GraphQL developers, they're often left confused. I've talked to many GraphQL developers who just have a hard time understanding all the pieces at play when they're trying to get started. And I think that's because the learning loop for GraphQL can be quite challenging. Needing to figure out like what a schema is, what a resolver is, and how to interact with those two things from the client can be a bit challenging. This question of like, where does GraphQL fit in the stack can be one that is challenging as well. Some people think that you should put GraphQL between your server and your database, for example, whereas others think it's strictly from your client to your server. And so informing new developers on where GraphQL really should fit into your stack can be a challenge.

How do you work with other APIs when you're dealing with GraphQL? How do you work with APIs that aren't built on GraphQL, trying to integrate those? And then what tools are needed to make the whole stack fit together? And that can be a challenge for new developers as well. And so I think if we can get early wins, early wins in the sense of being able to figure out the clear benefits of GraphQL in a very quick way, I think that it's possible then to get developers more excited about GraphQL. And so if we want more GraphQL adoption, if we want more people to be trying it out and using it in their projects, I think that focusing on those early quick wins is a critical piece of it.

So in my mind, there is an ideal experience and it kind of looks like this. We should have the benefits, the clear benefits, of that client-server relationship be more easily seen at the outset without having to think about all the mechanics. So without having to think about, well, what's the definition exactly of a schema? What does a resolver mean? What is the client piece? What is that all about? Instead, being able to show the clear contract that exists between those things and being able to do so in a way where the developer doesn't need to think about all the internals and the mechanics, I think that is a very big win. Having a way to be able to handle other pieces that you would find in any other kind of environment, I think is important too. Things like authentication and authorization, file uploads, those sorts of things being able to have a clear way to show how to do those things because they're necessities in applications. I think that being able to demonstrate how to do those things early and easily is an important part. And then automatically be informed about the GraphQL schema across the stack. So getting type information from the GraphQL schema that exists, being able to use that type information to inform ourselves at author time, and having an easy way to do that, I think is key. There are numerous ways that this is made easier these days. There are more and more frameworks, more and more kind of getting started packages out there that help with this sort of thing. But the one that I'll talk about today and the one that I think is probably the best way to bring this experience to life is a newer framework called RedwoodJS. RedwoodJS is this highly opinionated framework. It brings together lots of different pieces of tech into a very cohesive and very nice to use way. And one of the things that I love about it is it offers a lot of conventions and patterns that make it really easy to have consistency across an application, especially if you're working with multiple developers. And it's a very nice framework that brings together a lot of great tech that we'll touch on today.

What does a Redwood app look like? Well, it brings together these items. We've got React, GraphQL, Node, Prisma, Storybook, and Jest. Those are the main pieces. There are some others as well. And it brings these technologies together in a way that is super cohesive and super easy to get started with and to go beyond with.

We don't have to worry too much about these pieces. You know, as our application grows, they just keep working and they work very well.

When it comes to a Redwood app, we've got two sides. Redwood apps exist in a mono repo, in a Yarn workspace. We've got a web side, and we've got an API side. And so this mono repo approach is great because it allows us to work within a single project, but work on both sides, the web and the API side.

And so the question often is around Redwood, what does it do? Does it just kind of like install a bunch of packages for us, for those technologies? Does it just give us a package JSON and then we install all those individual pieces of tech? And the answer is no, it has a lot more than it does. It gives us a huge set of generators, which saves a ton of time generating code. We get scaffolding for things like being able to take a model and then be able to give ourselves the whole CRUD story around it. So all of the pieces of schema that we need, resolvers that we need. And then also all of the front end parts that we need as well, to be able to do CRUD. We get authentication out of the box. So you know, typically if you're working with authentication in GraphQL, you might be reaching for a custom directive. We get that stuff automatically with Redwood. We get routing solved for us with Redwood. We get a very nice implementation of a router within the React layer with Redwood. It's a very smart abstraction, works very well. We get things like layouts, you know, a convention for having an application shell, for example, that can be used across the application. We get code mods. When it comes time to upgrade the Redwood version that you're on, oftentimes there's code that needs to be updated across the application, and we can just run a simple NPX command to get that code updated across the whole app for us, which is great. We work within monorepos. It makes things much simpler when we're dealing with a single repo for the front end and back end of our application stack, rather than having multiple pieces that we have to worry about, you know, committed to different repos and deployed in different ways, et cetera. And then the thing I love most is just custom patterns that Redwood offers, things like cells, which we'll get into. Cells are this abstraction that gives us a way to handle the whole lifecycle of a CRUD operation. And we're going to see that in some more detail. Generating components is very simple. We use a yarn command, so it's yarn Redwood generate components and whatever your component name is, for example. We get the same thing with a page. We would have a component that might just be an isolated bit of a UI that we might be working on. We might also want to have a page, which is kind of like a larger shell where our components go.

And then we might want to generate a layout as well, which is going to be a kind of an application shell. You can think of it like that, which ultimately offers up something that looks like this, having our app shell with any number of pages that might be in it.

And then those pages themselves would implement various components. And this is a pretty typical way that an application is laid out. You've got like maybe a nav bar and sidebar in your layout, then you've got pages inside that can be navigated to and then components that do the work of the application.

Then if we're dealing with, you know, a server resource, something that would reside as a schema bit on our server with a resolver, we can target an SDL to be generated. So it'd be yarn, red would generate an SDL, giving it a name. And then we would get a full GraphQL schema, a full set of resolvers and we would be able to use it immediately with GraphQL calls.

So that's a lot of the theory. Why don't we see Redwood JS in action and we can see how GraphQL really shines within a Redwood app. So when we're dealing with Redwood and we want to get started with a new project, we can do so with Yarn. We can do Yarn create Redwood app and then give the app a name. Let's call this one GraphQL Galaxy. And then I'm going to say I want TypeScript. Typically this is what I always do. You know, TypeScript is what I use by default, but you can get Redwood in a standard JS flavor if you want as well. Just don't put on the dash dash TypeScript at the end.

When we do that, we're going to get a new application started for us. It's going to install all sorts of dependencies. It's going to go through and put together all of the packages that are within a Redwood application. So React, GraphQL, we've got Storybook, Jest and more. And it's going to put all of those things together for us into our new package. It's going to run Yarn install, and it's going to generate types right off of the bat. So type generation is something that happens automatically within Redwood JS, and that's going to happen for us right here at the installation phase as well. So we'll give this just a minute to run, and then we'll hop into the project and see how to work with GraphQL in it.

All right, we are all set here. So I'm going to CD into GraphQL Galaxy, and let's open this up in VS Code. And we'll give a really quick tour here of what's in the directories. So as I mentioned, we've got two sides. We've got a website and an API side.

Here's our website, all of the stuff that goes into the client portion of our application. Then here's the API side, and this is where stuff like our database models reside with Prisma, and it's also where we're going to manage our GraphQL pieces. So the first thing we might do is we might fire this up and take a look at what it looks like in the browser. For that, we can do Yarn redwood, or if we want to, keep it short, rwdev. And when we do, we are going to have a new project over in the browser that we can look at.

So this is the main splash page for Redwood. We don't have anything yet in terms of pages, but we can generate one and let's do that right now. Let's go and generate a page. To do that, I'm going to open up a new terminal, and I'm going to do Yarn redwood, or just rw for short. Generate a page and let's call this page our galaxy page. And we'll see what this looks like over in the browser. When we generate the page, it goes into the web directory, if we go to Source, into Pages, there's our galaxy page, and it's got things that we are interested in, like our React component that makes up the page and also a test that comes along with it for free, and a Storybook story as well that we can work on.

Over here, our page is showing up, let's navigate to it. Here is our galaxy page. So for this page, maybe we want to have a galaxy resource on our backend that we can work with, so something in our database, a resource that we can do some crowd operations against. With that, let's come over here, back over to the terminal, and we are now going to use something called a scaffold. But the first thing we have to do is set up our model. Let's come to the API directory, and we will go into our model, which is going to be under DB, schema.prisma, and what we'll do is we'll take out this example that comes with the Redwood installation, and we'll give ourselves a new model called galaxy. This is going to be like a table which will hold galaxies. So maybe the Milky Way, and Andromeda, and all the other ones that exist in the vast universe. Let's start by having an id field here. We will just make this an integer for now, and the default value can just be auto increments, so we'll auto increments that id. We'll want to say that this is also the id for this particular table. We might want a name. The name can be string. We might want a description, which will be string as well. And then typically we want to keep track of when a resource was created. So created at can be a field. That is a datetime type, and the default can be now. And then maybe updated at can be there as well, and we can track when updates happen.

That's a datetime field, and we can use the updated at decorator so that we can automatically get those values. So we have a galaxy table, and we are using, in this case, SQLite as our database. If we run installation on this, we should get everything wired up.

So let's, I should say if we run our generator for this, we should get everything wired up. So we can do yarn redwood prisma db push, that should give us our database. So there's our database, dev.db, and it's going to have that galaxy table in place now. And so what we can do to give ourselves a really easy way to work with data here is we can do yarn redwood scaffold, rather generate, scaffold galaxy. Let's run that command and we'll see what we get.

So we have got a layout. We've got routes. We've got all sorts of stuff. If we go to our routes file here, this is our routing file at the react level. We've got a whole bunch of new paths. We have got a path where we can add a new galaxy, we've got a path where we can edit an existing one, and all sorts of stuff that points to different components that have been created for us. If we take a look within our web directory. So we've got a new page here which is a galaxy page. I created an initial page called galaxy, which we could probably get rid of now, since we have another dedicated resource called galaxy page. of components that fit underneath this galaxy resource, which will give us all of the stuff we want to do for managing CRUD.

If we look in the API directory, we've got a bunch of stuff as well. For example, galaxies.sdl. So this is the GraphQL schema on the server that we want for managing this resource. We can see that immediately it gives us what we might expect based on an initial kind of sampling of this model that's in the database. Taking the fields that are on this model, we can interpolate here that we might want to have ID, name, description, all of these things available as parameters on this object. We get queries for galaxies, plural, single galaxy by its ID. We get an ability to do mutations right away. And if you notice here, we are requiring auth right away. So we've got this decorator require auth. If we don't want that, we can choose to skip auth, which is useful at develop time. But it's a very nice feature of Redwood that it automatically will give us authentication to protect our resources in case we forget, for example. So we've got everything in place here to give ourselves a full set of CRUD operations.

If we look in the services directory here in galaxies.ts these are the accompanying resolvers that will be used to do all this CRUD. So why don't we take a look over in the browser again. If we refresh, there's nothing on the page here. And that's because we need to get ourselves to a spot where we can edit it. So if we go to galaxies slash new, here we go, we are able to add a new galaxy in. In Milky Way home. Let's call this home as a description. We'll save this. There's the record in our database. We can edit it to be something else. We can save that. We can delete it. We can show it. We've got all sorts of operations that are just given to us for free by Redwood by virtue of generating this scaffold.

The important part that I'll hone in on here is that all of the GraphQL parts are solved for us just by virtue of running that command. So, for example, if we go to our components directory to Galaxy and then we go to Galaxy cell, here is our GraphQL query that was generated. It asks for all of the fields back that we've got on that model. It sets up all of the states that we might be in for doing a crud operation. What if there is a successful operation that happens? It sets us up for that. What if we are in a loading state? What if we're empty or there's a failure? It gives us those as well. And then the accompanying server pieces for this, like we already looked at, are already there, just generated automatically.

So, when we're thinking about a way for developers to get started with GraphQL in a very low-friction way, a very easy way where they can just start to see the benefits of GraphQL itself, I think that Redwood provides a very clear path for that. Things are generated automatically. We don't need to spend time figuring out exactly the syntax of the SDL piece that we might need, how to tie up a resolver to it, how to put the query piece in. It's just done for us automatically. And then we can spend time figuring out how all of these pieces operate together. But that very easy way to get started is done for us, which I think is a very big win.

So if you're new to GraphQL yourself and you like what you've seen in terms of a clear getting started path for it, check out RedwoodJS.com and it's as easy as we showed today. Or if you're an experienced GraphQL developer and someone you know is interested in GraphQL, I might recommend that you tell them about Redwood so that they can have that very easy getting started experience. Get the mechanics out of the way, get a very clear path to just getting the benefit first and then figure out the rest after. Thanks very much. My name is Ryan and once again I am the founder of Courselift. If you're interested in course hosting that helps you market and sell your courses, check out Courselift.com or Courselift on Twitter. Thanks very much.

Hey Ryan, welcome. Thank you so much for being here. Just a reminder to the attendees, you can ask your questions to Ryan on Discord and the Andrew Meda Q&A channel. So yeah, Ryan, let's go ahead and start by taking a look at the results from the poll question that you asked before your talk. Sounds good. So again on Slido, we can take a look and see. It looks like most people have answered, about 50% have answered generate schema model. Closely behind is generate SDL model. So what do you think about those answers? I think people were on kind of the right track, but it looks like the correct one was voted lower than the incorrect one. It is SDL, to get yourself a full set of CRUD resolvers, of your SDL for your backend. So if you have some model in your PRISMA schema, you can do yarn redwood generate SDL, and then your model name, and then you get all that code generated for you.

Awesome. Yeah, it sounds like a really great way to just get things rolling and give you everything that you need. So, great. Awesome.

Well, let's go ahead and start with some of the questions that we're seeing. The first is, how does redwood differ from other frameworks and meta frameworks, things like next, or blitz, et cetera.

Yeah, so redwood, it's an interesting kind of concept. It brings together various pieces of technology that are already established and are well known. So, of course, like we saw in the talk, React, GraphQL, things like Jest, things like Storybook. It brings these altogether and gives you a cohesive way to like, use them without much fuss, right? But one of the most difficult parts I think, about starting a project, that you wanna use all those pieces of technology in, you gotta wire them all together, and you gotta follow docs to do all that. Redwood just solves that for you.

I would say like Next.js, for example, much more focused on React. Of course, you can do API kind of things with Next, but Next doesn't have an opinion so much about how you would put GraphQL into the mix, for example. It surfaces a way for you to have a front end and a back end, but is less opinionated perhaps in that way. Still opinionated in the fact that it gives you kind of, you know, it's own domain specific way of using React and using a back end, but brings together fewer of those tools.

I would say Redwood is much more closely related to something like Blitz. Where Blitz has similar goals, it gives you, you know, commands to run, to scaffold out an app for yourself. It gives you a way to tie together various pieces very easily. So Redwood is kind of similar in that vein to Blitz, but with its own set of opinions, et cetera. And then if you look at other frameworks, I mean, if you, I mean, maybe you call React itself a framework, some people would say it is, others say it's just a library. But it differs in that way because React is just for the, you know, the user interface for the most part. And then, you know, same thing with frameworks like Angular, for example. You would more so see Redwood doing all of the stuff across the full stack for you. Whereas Angular's just for the front end. So I think that's a little bit of how they differ.

Yeah, it's interesting. I think if you look at frameworks, libraries, you know, utilities, like APIs, and you think about a few vectors around, is this front end, back end, full stack? Is this opinionated versus non-opinionated? And is this more of a library versus a framework where it's going to be very directive in how you use it? Yeah. So I think it seems to be like an interesting overlap across those three vectors. If you want to get up and running very, very quickly, have it cover as much of the stack as possible. And then also have those guidelines in place for you to be able to make decisions that are in line with the best practices.

It covers a lot of those use cases, so to speak. For sure. And, and one thing that was important to Redwood at the outset, is that it be targeted towards It's easily deploying to the, in a JAMstack sense, so deploying to serverless. Where, without really any fuss at all, you would deploy your GraphQL endpoints to a serverless function. You could deploy any, kind of individual functions you might be wanting to work with as serverless functions as well. So just, like, super easy to work with serverless too. Yeah, and we're seeing like from an architectural standpoint, teams that can work in that environment, they're able to move pretty quickly, which is great. So awesome.

Another question is kind of in line with that, actually. So which features of Redwood offer the most productivity gains? Yeah, for me it's generators. Those are pretty huge. You know, there's this argument to be made that generators might not be the most important thing for a framework because once you've generated your code, you're then kind of maintaining components you've already built. And so you're not, maybe, always using generators. But for me, especially when starting a project, being able to scaffold things out and generate, get a whole bunch of code just done for you is huge. And I've started using, I got on the train with like ChatGBT giving me code now. I am using Copilot and stuff like that. So the more code that can be written for me, I'm all for it. I'm not a purist that says I've got to write all my own code. I will happily let the computer write the code for me. So Redwood is great for that, you know, just generating code to get you out the door. And then you make the appropriate changes that you need, of course, to your components and build from there. So it's a huge, it's a huge boost. Awesome.

And one last question we have time for. Is there any feature that's coming up that you're looking forward to? Well, there's talk now about kind of handling authentication in a bit of a different way. Redwood has been their authentication model just quickly has been kind of strictly tied to a provider. You can use many different providers, but it's pretty well coupled to that provider that you might choose. And now there's work to be done to decouple authentication that has traditionally been coupled to a specific provider. So I'm looking forward to that. Awesome. Well, can't wait to learn more about that. And so thank you so much, Ryan, for answering our questions and for your amazing talk. We really appreciate you being here. Absolutely. Happy to be here.