From GraphQL Zero to GraphQL Hero with RedwoodJS

Rate this content
Bookmark

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!

32 min
09 Dec, 2021

Video Summary and Transcription

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

Short description:

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

Short description:

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.

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.

3. Redwood.js Application Folder Structure and Schema

Short description:

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

Short description:

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

Short description:

You can use types across different files in Redwood.js. Services in Redwood.js are chunks of the GraphQL API split by functionality. The names of queries and mutations in the SDL file are automatically mapped to JavaScript or TypeScript functions exported in the service implementation. The implementation consists of simple Prisma calls that can be customized. Let's explore how to create another query to find popular albums.

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.

6. Implementing 'popAlbums' Query

Short description:

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

Short description:

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

Short description:

We can import resolver functions and use them in other services, separating backend functionality and improving maintainability.

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.

9. Traversing and Retrieving Data in GraphQL

Short description:

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

Short description:

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

Short description:

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

Short description:

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.

QnA

Redwood.js Open Source and Production Capability

Short description:

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

Short description:

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

Short description:

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

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Interactive web-based tutorials have become a staple of front end frameworks, and it's easy to see why — developers love being able to try out new tools without the hassle of installing packages or cloning repos.But in the age of full stack meta-frameworks like Next, Remix and SvelteKit, these tutorials only go so far. In this talk, we'll look at how we on the Svelte team are using cutting edge web technology to rethink how we teach each other the tools of our trade.
JSNation 2023JSNation 2023
28 min
SolidJS: Why All the Suspense?
Solid caught the eye of the frontend community by re-popularizing reactive programming with its compelling use of Signals to render without re-renders. We've seen them adopted in the past year in everything from Preact to Angular. Signals offer a powerful set of primitives that ensure that your UI is in sync with your state independent of components. A universal language for the frontend user interface.
But what about Async? How do we manage to orchestrate data loading and mutation, server rendering, and streaming? Ryan Carniato, creator of SolidJS, takes a look at a different primitive. One that is often misunderstood but is as powerful in its use. Join him as he shows what all the Suspense is about.
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
Top Content
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.

Workshops on related topic

GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Top Content
Featured WorkshopFree
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.

Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q&A
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)
React Advanced Conference 2022React Advanced Conference 2022
95 min
End-To-End Type Safety with React, GraphQL & Prisma
Featured WorkshopFree
In this workshop, you will get a first-hand look at what end-to-end type safety is and why it is important. To accomplish this, you’ll be building a GraphQL API using modern, relevant tools which will be consumed by a React client.
Prerequisites: - Node.js installed on your machine (12.2.X / 14.X)- It is recommended (but not required) to use VS Code for the practical tasks- An IDE installed (VSCode recommended)- (Good to have)*A basic understanding of Node.js, React, and TypeScript
GraphQL Galaxy 2022GraphQL Galaxy 2022
112 min
GraphQL for React Developers
Featured Workshop
There are many advantages to using GraphQL as a datasource for frontend development, compared to REST APIs. We developers in example need to write a lot of imperative code to retrieve data to display in our applications and handle state. With GraphQL you cannot only decrease the amount of code needed around data fetching and state-management you'll also get increased flexibility, better performance and most of all an improved developer experience. In this workshop you'll learn how GraphQL can improve your work as a frontend developer and how to handle GraphQL in your frontend React application.
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
WorkshopFree
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.