Full-stack JS today: Fastify, GraphQL and React

Rate this content

First there was LAMP, then there was MEAN and JAM. But now it’s 2022 and times have changed… What does the modern full stack look like? It’s built entirely from free and open source technologies, it’s scalable beyond imagination, it can run on premise or in the cloud, it should get out of the way and not lead to vendor lock-in, and most importantly it should “just work.” There are so many tools to choose from. Choosing the right stack from day one can be the difference from project success to smoldering pile of software ashes. Using fastify, mercurius, urql, and react we can build high performance full-stack applications using all javascript technologies.

25 min
17 Jun, 2022

Video Summary and Transcription

The Talk discusses building a modern full stack application with JavaScript and GraphQL, emphasizing the importance of prioritizing the critical 20% of challenges. It highlights the benefits of building a productive and transparent tech stack with modularity and developer-friendly tools. The use of PostGrey as a relational database and Fastify as a server framework is recommended. The Talk also explores the advantages of using Mercurius and Urql for GraphQL implementation. Additionally, it mentions the use of React, SSR, and Fastify Vite for full-stack SSR and modular components. The Talk concludes by mentioning the advantages of this stack for complex functionality and the possibility of using Fastify in a serverless infrastructure.

Available in Español

1. Building a Modern Full Stack Application

Short description:

I'll be talking about building a modern full stack application with JavaScript and GraphQL. Let's focus on the last 20% of the project, the hard part that we often overlook. The Prado Principle, introduced by Vilfredo Prado, states that 80% of our outcomes come from 20% of the challenges. Steve Jobs applied this principle at Apple, reducing the number of computer models and devices. Let's learn from this and prioritize the critical 20% from the beginning.

So happy to be here. Thanks, everyone. I'll be talking about building a modern full stack application with JavaScript and a little spoiler, we're going to be talking about GraphQL, all open source, because that's what we love. My name is Cody, I work at NearForm, I teach web development course at the local university where I live in France, but enough about me. What I really want to do is I want to challenge everyone here, do a little exercise with me.

Close your eyes and imagine your next project. You've got all the requirements in from your stakeholders, you know what you want to build, and what are you going to do when you close your eyes? You're going to start thinking about those tools and those frameworks that you're going to reach for. When I do this, and I start thinking about those tools and frameworks, what I'm saying to myself is this time it's going to be different. This time it's going to be right, this time it's going to be rainbows, and this time it's going to be unicorns.

I think we all do that because we want to reach for new technology that's going to help, it's going to solve all of those problems that we had in our last project. I think the trap is, though, is we might get like 80 per cent through our project. When we reach that 80 per cent, all of a sudden something happens. Those real-world non-functional requirements hit that last 20 per cent, and it's that last 20 per cent that's really hard. Where do we find ourselves? We are thinking about rainbows and unicorns, we end up with something like this. I don't know how many times I've been like this, trying to fix real problems in a production application. We've got complex CI pipelines, we've got problems with scaling, we've got problems with performance, security things we didn't think about in the beginning, authorisation, authentication, so I feel like there's this massive gap between what we imagined and the reality, because we are all just real-world people fixing real-world problems. We're devs, we're trying to do the best we can, and I think what I want to challenge us to do today, let's focus in on that last 20 per cent, that hard 20 per cent that we don't always think about in the beginning.

So, I want to talk about this guy. This guy, his name is Vilfredo Prado. We call it the Prado Principle. I know you can't read that text but you will in just a second. Vilfredo Prado, this Italian economist, he came up with the idea of the 80-20 rule. I keep talking about these percentages and he said, you know, like, maybe just 80 per cent of our outcomes in our projects are going to come from 20 per cent of the challenges, of the requirements. That's what I want to challenge us to do today. Let's think about that 20 per cent from the beginning. So there's the Prado Principle in its entirety. And I think Steve Jobs knew this. When he came back to Apple in 1996, they had like 15 desktop computer models, he cut them down to one. They had a whole bunch of portable devices, I think they called them laptops back in 1996, he cut them down to one. Peripherals, printers, deleted them all.

2. Building a Productive and Transparent Tech Stack

Short description:

I want to focus on the hard 20% that can lead to an 80% increase in productivity. Building a tech stack with modularity allows us to adapt to evolving requirements. Developer experience is crucial, with tools that guide rather than hinder. Running applications anywhere, without reliance on cloud services, is important. Community-supported, open-source projects provide security and transparency.

Got rid of them all. He wanted to focus in on that last 20 per cent, that last 20 per cent that really mattered. So today, what I want to focus on, what I want to challenge us to focus on is that hard 20 per cent. And maybe, just maybe, we can gain 80 per cent in our productivity.

So how can we build this tech stack, this magic tech stack, that's going to focus in on that hard 20 per cent, that 20 per cent of non-functional requirements, help us get speed of delivery and ensure that our production-grade application can work the way that we want, that we can fix things while it's in production? To do that, I want to lay out some principles when I'm going to build my tech stack. These are the principles I'm going to think about. The first one's going to be modularity. And I think one of the challenges, the traps that we can fall into, is we're going to reach for that framework that says it does it all, and we think it's going to do it all, but maybe it doesn't do it all. What happens when we hit that moment when it doesn't do something we want, and we have We have to reach for something else, or throw away the framework and start from the beginning. So if we can build a tech stack where we can swap out layers of the stack when something isn't working, we've won something, right? Like our stack suddenly becomes modular and we can adapt to the situation, to the requirements as they evolve.

Next up on our principles is going to be developer experience. That's why we're here. We're all devs. We're all fixing real things. I want the tools like help me, like guide me, not get in the way, right? And I want to be able to run my application anywhere. I want to be able to run it on my laptop while I'm in the train, when I don't have Wi-Fi or the airplane, like it needs to run locally or in the cloud, on site, docker, whatever it is. That's really important to me, too. I don't want to be reliant on some cloud services and I can't run my end to end tests on my machine because I'm reliant on that internet connection that doesn't exist in the hotel. Based on my principles, it's community first. I'm talking about open source projects. Community supported. They're going to be more secure, ideally, right? Because more people, more eyes are looking at the code. Bugs are going to get fixed. Things aren't hidden from you. I think that's really important when it comes to a tech stack. I'm talking about a hundred percent open source. Not just that 80% and 20% of the magic secret sauce is running in a cloud service that nobody can see. I want to see 100% open source. My next and last principle is going to be transparency. This is related to open source and that idea of a community supported project.

3. Transparency and Starting from the Back

Short description:

We love abstraction layers, but what happens when abstraction doesn't work? Let's talk about starting from the back when building a tech stack. The stack starts with PostGrey, a relational database that most developers are familiar with.

Also transparency, when we talk about abstraction. We love abstraction layers. That's what makes our lives easy. That's what makes us productive and develop things fast. What happens when abstraction doesn't work? I want to be able to peel off those layers and get my hands in on the nitty gritty. The dirty parts. Like we saw in that first meme of people fixing things. I want to be able to reach under those abstractions if I need to. They shouldn't be hidden from me.

So let's talk about the stack. Now the stack. Most people when we start building a tech stack, we often start from the front and work our way back. I think that's the wrong approach. If we want to fix that last 20% of the non-functional requirements, then we should start from the back. That's what I challenge us to do today. So I'm going to turn the whole problem upside down, inside out. We're going to start from the back. So let's talk about the stack.

You're going to see this slide with the waffles quite a bit. I found them to be pretty tasty. So we'll see that often in this presentation. So first thing on the stack, we start from the back. You can flame me. You can send me your hate mail. You got my Twitter handle there. But my friends, there's an elephant in the room. And the elephant's name is PostGrey. Why would I talk about PostGrey? PostGrey is awesome because relational databases, I also love document-based, no schema databases. But devs know it. And I'm willing to bet in this room, anyone who has a computer science degree or software engineering degree, I bet you've taken a relational database course.

4. PostGrey and Fastify

Short description:

I'm willing to bet money on that. PostGrey is the best relational database with JSON support. Connection pooling allows for insane scaling. PostGrey provides a powerful dev experience. Fastify is a server that allows for building monolithic applications and evolving with code.

I'm willing to bet money on that. So devs know it. You can add devs to your project without a lot of challenge. And I think that's really important.

Next up, I'm saying it right now. Quote me on it. It's the best relational database. Not only is it the best relational database, it's also like no-SQL ready because they've had JSON support, I think, since version 9, and we're up to like 14 is the current release. So the JSON support just gets better and better. So if you want to build a document-based database, you can do it in PostGrey. That's one of its superpowers.

Sports connection pooling, I'm not going to spend a lot of time on that. I need to speed up a little bit. But connection pooling, we're going to have insane scaling. That's another thing we have to think about when we're building that big tech stack. So we can do connection pooling, we can suddenly cut off tons of resources doing the TLS handshaking if we can share connections. And last thing I want to talk about is that dev experience because I can run PostGrey, I can spin it up on my laptop here in like a second in a docker container and I can run all my tests directly. And, you know, love it, hate it. I have that relationship with SQL, but it is crazy powerful. aggregations across multiple tables, or if we were talking about collections in a document based database, I can do it.

Next up on the tech stack we're going to talk about the server. If we're going to talk about the server, we're going to be talking about Fastify. I just couldn't help but thinking about that Fastify cat eating some of those waffles. This is my node.js server and it's inspired by happy. It's going to be really familiar to anyone who's used Express before. It's easy to use. And what's amazing about happy, Fastify, is that it allows you to build a monolithic application today when you're doing your POC. As your project grows and your requirements grow, inevitably, you're going to want to split that up probably into services, create some sort of microservice architecture, and Fastify, with that plug-in architecture, it's going to let you evolve with your code. So Conway's Law is always going to come into play. Essentially, your code is going to look like your organization, and Fastify lets you do that.

5. Fastify, Mercurius, and Urql

Short description:

Fastify is an open-source, transparent, and modular framework that supports plug-ins. It's perfect for building applications. The API layer will be GraphQL, specifically using the Mercurius plug-in. Mercurius solves real-world GraphQL problems out of the box, with features like caching, federation, authentication, subscription, and file uploads. The caching in Mercurius is exceptional and provides excellent performance as the application scales. On the client side, we'll use Urql, a powerful GraphQL client.

It's open-source, it's transparent, and it's modular, because we have those plug-ins. Again, it can run anywhere. That's one of the things we love about Fastify. And that plug-in architecture is just kind of programming Xen when each plug-in is isolated from the others, and you can logically build your application.

So now let's get to the good part, our API layer. It's going to be GraphQL. If we're using GraphQL on the server of Fastify, we're going to be using Mercurius. Mercurius is a GraphQL plug-in, a GraphQL server for Fastify. And it's going to solve real-world GraphQL problems today, like out of the box. This is what's so cool about Mercurius. It supports caching, federation, authentication, subscription, file uploads, all those things you didn't think about when you wrote your first GraphQL server, it comes with those in the form of a plug-in that are supported by the core project, or it comes with them out of the box. That's what's so amazing. And the caching, we're going to talk about that in just a second. The caching is really amazing in Mercurius, and that's what's going to give us some amazing performance as our application scales. It integrates the GraphQL server, so we get a timeline where we can see our queries going by and we can debug them in our browser. Oh, sorry, that's the next step, I skipped a step. That's to allow us to debug our queries in our browser as we're building them. It has loader support built in. I don't have time to go into that. Inevitably if anyone here has built a GraphQL server, you're going to have that problem where your data is in a graph, so you have some sort of hierarchy to it. If you're fetching parents, eventually you're going to have to fetch children. You don't want to do one after the other. You want to queue up all the parents and then queue up all the children and maybe do two queries to your database to get all your data. And loader lets you do that, and that comes built into Mercurius and that's one of the things that I love about using Mercurius.

We're going to switch over to the client side. If we're going to use GraphQL on our client, what are we going to use? We're going to use Urql. I call it Urql. You might call it U-R-Q-L. U-R-Q-L. I think Urql has a nice ring to it.

6. Urkle GraphQL Client

Short description:

Urkle is the best GraphQL client that supports all major front-end libraries, including React. It offers powerful caching capabilities, offline support, and a hooks API. Additionally, Urkle provides useful developer tools.

It is the best GraphQL client. It's going to work with all the major front end libs. We're at React, so it supports React as its principal front end lib. Caching. It does some crazy caching. cache things using your query as the key into the cache but can also normalize your data and cache things by ID, ID of the entity. This lets you pull items out of the cache that have already been queried by a different query. And you've got offline support. If we have the ability to store things in cache, we can store it in the index DB in the browser and our application can suddenly run offline. All the things that we might want in a GraphQL client, Urkle has that out of the box. And, of course, it has a hooks API. We're here talking about React. It's a magic API and they have some dev tools.

7. Building a Pizza Application with Urkel

Short description:

So I split the component into two segments to fit it on the slide. I'll build a pizza application with slash pizzas to list all my pizzas. The use query hook returns a result object with data fetching error. I can easily handle errors and render data. Urkel allows us to get data from the cache without going to the server. Setting up GraphQL APIs to match our business domain and storing data in the cache simplifies our application.

So had to throw in a couple of code snippets. This is really one component, but I split it into two segments to fit it on the slide and we'll build a pizza application. I'm going to have slash pizzas in my application that's going to list all my pizzas. I'll probably have, like, slash pizza, slash an ID, to get details. So this is the list. And we have that use query hook. I guess I have my query on the left. And in the top of my component, I have the use query hook. And that returns a result object which has these three keys in it. Data fetching error. This is amazing because, like, the API is built for writing React components. So if there's an error, I can show one thing, pop something up. I can have a loading spinner. Super easy. And finally, I can actually render my data. And if I've configured my cache correctly, if I run that query, and now I'm going to get details for a pizza, I have a similar query on the left. This time I'm going to get it by ID. If I've set up my cache correctly, you know, my component looks about the same on the right, you just have a little different query. Suddenly, like, Urkel lets us get the data out of the cache without having to go to the server so I'm going to visualize this very quickly here. So I have two components on the left. My pizza component and my pizza component. I'm going to make that query. It's going to work its way down the database. It's going to come back. But things are going to get stored in the cache. So now what's going to happen, though, if I've set up Urkel the right way, when I finally do that query on the client, it's coming right on the cache client side. No trips to the server. And this, this is amazing because if we, like, set up our GraphQL APIs to match our business domain and we can store things in the cache, like, imagine if, like, we don't really need to worry about application state, like, global state, redux, all those things can make our application really complicated. Had to throw this in there. Like, this is how I feel when I don't have to write redux code.

8. React, SSR, and Fastify Vite

Short description:

We love React because it's always evolving yet stable. Components help us architect our code. Vite is a must-use tool. An honorable mention is SSR with Fastify Vite, which allows for full-stack SSR and modular components. It integrates with major front-end libraries and handles page-level templating and routing. Fastify DX, released by Jonas Galvez, sets up React and Fastify Vite transparently. Building non-functional requirements into our tech stack from the beginning ensures unicorns.

Every day I feel like that when I'm not doing it. So, of course, we're here at React Summit. Gotta talk about React. Why do we love React? Well, because it's React. And we're all here, like, devs know React, so you're gonna be able to ramp up your team, add resources. That's one of the things we love about React.

It's always evolving but, yet, it's still stable. Okay. 18 had some changes that all shocked us, but, like, we were ready for that, right? Components make us architect our code in a good way. Dev tools, we love it. Vite. If you're not using Vite, use it. Go check it out. Yeah, if you're not doing it, just do it.

So, honorable mention. I'm running a little short on time, but honorable mention here is gonna be SSR. Like, we have to talk SSR a little bit. Now, what's awesome, if we're using Fastify and Vite, there's a little plugin for Fastify called Fastify Vite which lets us do SSR, so suddenly we have a full stack where we can do SSR and each component is modular going back to those principles. Works with all the major front-end libs. It's going to handle the page-level templeting and it's going to integrate all those routes that you probably have in your React router. It's going to add those into the Fastify server so we can map our client-side routes into routes on the server. I'm just going to go really quick here, if anyone wants to talk about this with me, we have a booth, a near-form booth out here, come see me and we can talk about that in more detail. It's customizable, it's not magic, it's super transparent. An honorable mention, my colleague Jonas Galvez, he just released Fastify DX which is going to have React and Fastify Vite all set up, out of the box, ready to go, check out this project, if you haven't, it's still kind of in beta. He just released it, I think, two weeks ago, and it's going to be out of the box, having everything set up but in a transparent way that you can customise.

So, when I started the talk, we're talking about unicorns and rainbows. Maybe we can't have both. If we start thinking about the problems that we're inevitably going to have in a production application, those non-functional requirements, and we build those into our tech stack from the beginning, we can still have unicorns. We may not have any rainbows, but I've still got a unicorn. So I just want to review this stack super quick.

9. Why Use This Stack and NearForm

Short description:

This stack is built for complex functionality and non-functional requirements. It is highly customizable and has a modular design. The transparency and community support of open-source projects make it a great choice. If you have any ideas for naming the stack, let me know. I work at NearForm, maintaining important open-source packages and providing professional services. Check out the proof of concept pizza app I built and feel free to ask me any questions. Thanks, everyone!

Why would I use this stack? Like I said, it's built for that complex functionality, those non-functional requirements that are going to happen at the end. That last 20 per cent, we're thinking about that from the beginning, it's highly customisable, we can swap things in and out, still has that modular design.

All the abstraction layers, they're transparent, we can peel the covers off, we can get our hands dirty if we need to, and of course it is a community... All community-supported projects, open source, got lots of eyes looking at them.

So that's why I would use this stack, and that's how I sell this stack to your team when they're reaching for that framework that claims to do everything. I just want to real, real quick, ask you all a question. We had the lean stack, we had the mean stack, we had the jam stack. What's my stack called? The best we could come up with is Frump, Fastify, React, Urkel, Macarius, Postgre? Doesn't really have a ring to it. I thought of like firm or merf. Those are a little weird too. If you have any ideas, send them to me on Twitter or come see me at the booth. I'll be happy to talk about that.

I work at NearForm. Like I said, we do have a booth. We're the maintainers of some really important open source packages and MPM, and we do professional services, but we also get to work at open source and contribute to open source. Awesome place to work. If you want to know more about NearForm, hit us up at the booth. Be happy to talk about that. I built a proof of concept, that pizza app. You can check it out at this URL. You can also see my slides. And if anyone has questions about these things or they want to go into deeper details, I'd be super happy to do that. Come see me at the booth or hit me up on Twitter. Thanks, everyone. Thank you. Step over into my office. Into the office we go. That's nice. First of all, I do have a bit of a bones picker view here. So much amazing food in your slides, you make me hungry.

10. Using Fastify in a Serverless Infrastructure

Short description:

Is it possible to use Fastify in a serverless infrastructure? Absolutely easy. The answer is yes. Go to the Fastify website, and they have a link right on the home page serverless, and they're going to show you how to set it up.

Well, it is about that time, right? Nice. Let's jump into those questions. Remember, if you want, you can also come find him at the booth and also in the Q&A booth right after this. But let's jump straight into that question. Let's do it.

The top one. Is it possible to use Fastify in a serverless infrastructure? Because this is something I'm always trying to do things serverless. Absolutely easy. The answer is yes. It's a big yes. Go to the Fastify website, and they have a link right on the home page serverless, and they're going to show you how to set it up. AWS, GCP, Azure, whatever your service platform is. They have directions to set it up in all of them. Perfect. So big yes. Awesome. Awesome.

11. Advantages of Mercurius and Ercu

Short description:

Mercurius comes with built-in features like federation, authentication, and caching, making it convenient to use. These features are readily available and well-documented in the readme.

So let's talk about the advantages of two, of Ercu and Mercurius versus Apollo, and let's just combine them into two. What are the advantages, disadvantages of the two? I don't want to criticize any of the existing frameworks, but what I love about Mercurius is that it comes with all those things, those little magic bits that we might not have thought about when we're using the other frameworks. It comes with those built in, out of the box. So the moment we need to do federation, or the moment we want to do authentication, or adding caching, it just comes out of the box. They gave it to you, it's right there in the readme, it tells you how to set it up. So those are the things I love about Mercurius and why I'd work with that.

12. Cons and Disadvantages of the Stack

Short description:

Let's talk about some of the cons and disadvantages of this stack. The initial development velocity may be high, but we need to consider the challenges of maintaining production-grade code. Spending more time in the beginning can save time in the end.

Nice, nice. And Ercu on the front end, sorry. Nice, and a lot of people who have used so many different types of stacks, I'm always trying to compare them, let's just talk about some of the cons and disadvantages of this stack so that we can evaluate it with others. Yeah, I think that's a fair question, I think that's definitely a fair question. The disadvantages are maybe it's that initial development velocity, so if we reach for a framework that claims to do it all, it's going to launch us super fast into a high development velocity, so I think that's definitely an advantage to a big framework. But what I want to caution everyone is to think about what's going to happen once it goes in production, once you start having those other challenges when you got to fix things in production-grade code, are you going to be able to do that when you're using that big framework? There are advantages and disadvantages, I think maybe if we spend a little bit more time in the beginning, we can save a ton of time in the end.

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

GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
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!
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
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.
React Summit Remote Edition 2021React Summit Remote Edition 2021
43 min
RedwoodJS: The Full-Stack React App Framework of Your Dreams
Top Content
Tired of rebuilding your React-based web framework from scratch for every new project? You're in luck! RedwoodJS is a full-stack web application framework (think Rails but for JS/TS devs) based on React, Apollo GraphQL, and Prisma 2. We do the heavy integration work so you don't have to. We also beautifully integrate Jest and Storybook, and offer built-in solutions for declarative data fetching, authentication, pre-rendering, logging, a11y, and tons more. Deploy to Netlify, Vercel, or go oldschool on AWS or bare metal. In this talk you'll learn about the RedwoodJS architecture, see core features in action, and walk away with a sense of wonder and awe in your heart.
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.

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
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
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
Top Content
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.
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
Top Content
In this workshop we'll dig deeper into data modeling. We'll start with a discussion about various database types and how they map to GraphQL. Once that groundwork is laid out, the focus will shift to specific types of databases and how to build data models that work best for GraphQL within various scenarios.
Table of contentsPart 1 - Hour 1      a. Relational Database Data Modeling      b. Comparing Relational and NoSQL Databases      c. GraphQL with the Database in mindPart 2 - Hour 2      a. Designing Relational Data Models      b. Relationship, Building MultijoinsTables      c. GraphQL & Relational Data Modeling Query Complexities
Prerequisites      a. Data modeling tool. The trainer will be using dbdiagram      b. Postgres, albeit no need to install this locally, as I'll be using a Postgres Dicker image, from Docker Hub for all examples      c. Hasura