Design-Driven Full-stack: an End-to-End Dev Workflow that Scales

Rate this content
Bookmark

I’m going to show you something you haven’t seen before — a simple, integrated workflow made possible by React, RedwoodJS, and Storybook. We’ll start from scratch, generate code for components, design and mock state, then finish with a secure API and CRUD UI.


Sounds hard? It was. But not anymore! 🤯


You’ll learn how to bridge existing development gaps between stateful designs, data fetching, and your API using Redwood Cell components — a one-stop-React-shop for fetch, state, mocks, and design. Teams can move faster. Solo devs can iterate more quickly. And there are secondary benefits from documentation to security to accessibility, which add up to improving long-term maintainability at scale.


Get ready to be inspired by what you’ll be able to build!

David S. Price
David S. Price
32 min
17 Jun, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

This Talk discusses the challenges of building full stack applications and introduces Redwood.js as a solution. It emphasizes the importance of design-driven workflows and the use of Redwood Cells to handle state and simplify complex tasks. The Talk also highlights the seamless integration between the front end and back end using mock data and the optimization of workflow for performant teams. It concludes with a mention of Redwood's authentication features and the importance of community and collaboration.

Available in Español

1. Introduction to Building Full Stack Applications

Short description:

Hello, Amsterdam. It is really good to be here. Are you okay if we have some fun? We're going to have some fun. My name is David and I come to talk about building a full stack application. Sometimes things can go out of hand quickly when building a full stack application. There's a lot of dynamic complexity in assembling all the parts. The JS ecosystem has both beauty and tensions. Our goal is to ship features as soon as possible.

Hello, Amsterdam. People of Internet Land, all around the world. It is really good to be here. Are you okay if we have some fun? Would that be okay? All right. I mean, some of it, we're going to do a walkthrough. But some of it, well, it may get a little bit strange. But we're going to have some fun.

Again, my name is David and I come to talk about building a full stack application. If oh, yep, there we go. Oh, we went too far. My clicker. My clicker clicked. That's a question I want to ask you. So you want to build a full stack application. Yes? All right. Well, I've got some good news. But of course, you always start with the bad news. And the bad news is that sometimes things can go out of hand a little bit quickly, right? Is anyone, so question for you, anyone who's built a full stack application, who would say raise of hands that you've used probably 75% of those tools or tools like that in your application? Raise of hands? Right? How about 80, 90%? Raise of hands? Right. Okay. Maybe three out of four, but that's a part of the beauty of the ecosystem that we work in. And it's also one of the tensions of the ecosystem that we work in.

So what happened before this train literally went off the rails? You're shipping features, right? You just want to build features as quickly as possible, design, dev, deploy, on repeat. And sometimes it doesn't always go the way that you want it to go. There's this way that we assemble all the parts that adds a lot of dynamic complexity, right? And complexity means often going off the rails. The beauty of the JS ecosystem is its diversity, the modularity, and the rate of innovation. The bane of the JS ecosystem is its diversity, modularity, and rate of innovation. Right? It's powerful, but sometimes it goes wrong for the same reasons that it goes right. All right. So, again, our goal, we want to ship features, we want to do it frequently. We want to ship features as soon as possible.

2. Architecture and Process Challenges

Short description:

And as our application scales, we want to ship features continually. We need an architecture and process that works efficiently across the stack. Config, integration, and dependencies add overhead. Separation of concerns is important, but it requires integration and config when bringing them back together.

And as our application, as our team scales, our user base scales, we want to ship features continually, frequently. Design, dev, and deploy. And it's not just the technology.

So, that's what I want to talk about today. We need both an architecture and a process that's going to work across a stack as efficiently as possible. So, what gets in the way of architecture and process? Oh, it did a thing again. Hang on a second. You know, I don't trust my clicker anymore. Uh-oh. Did I just give away something? All right. What gets in the way? Has anyone done config before? Oh, come on, raise your hands. I know we'll get there, right? Yeah, config. Well, come on, all you do in JavaScript is config. If you're not raising your hands, then you're lying.

I'm a framework developer, so all I do is config, but I don't know if I love config. Integration, config, dependencies, all of that adds overhead over time, because also, you've got to move fast and keep up with those dependencies. As break and changes happen, you have to keep up with config. Conventions. Separation of concerns. Now this is actually interesting. In full stack, what you're taught to do is you're taught to separate concerns, which you have to. That could be at the specific endpoint level. Maybe you're creating an integration with a third-party application. Your entire API, right? We want to separate concerns. We want to separate from the front end, right? Working with React, working with state, working with data. If we want to just do design and lay up, we want to separate concerns. What happens when you need to bring those separate concerns back together? What are you doing? Oh, come on. That was a... So what was overhead? You're doing integration and config, right? So even when you separate concerns, then you have to come back and do integration and config on them, right? Okay, next one. Clicker.

3. Design Driven Full Stack Workflow

Short description:

Clicker let me down today. Security. Is your API secure? Design driven full stack. A workflow for people that like to ship features. I'll show you how to have a full stack workflow from start to scale. Starting with a standalone project, we'll create components, design isolation, and work with data. We'll build API and UI for CRUD and make it secure. All in this presentation.

Clicker let me down today. Security. Is your API secure? Really? Because you did it? You wrote the CI test too, right? All right. Bad news. Let's go to the good news.

Design driven full stack. Yes, we kind of made that up. But it's a workflow for people that like to ship features. And I'm going to show you how you can have a full stack workflow end to end that includes that architecture process I talked about that lets you ship efficiently from the start of your project all the way through to scale.

So here's what that means. I want to start with a standalone project. And we're just going to have a file that's going to be HTML and CSS. And we are going to do a walkthrough. It takes me about 25 minutes and I knew that wouldn't fly. So we're going to go through some recorded and do a little bit at the end. I want to show you this. We're going to start HTML, CSS, JSX file. We're going to create a component. We're going to design an isolation and do layout. And then this coupling place. We need to work with data because data is what we need to couple. But the lack of being able to mock data specifically for fetch and state is often where coupling breaks down. Right? So we're going to work through that stage of doing mock data. And then we're going to build out all of our API for CRUD. We're going to build out all of our UI for CRUD. And then we're going to make it secure. And I'm going to do all that. How much time do I have, Ellie? Nevermind. Don't answer that. But we're going to do that in this presentation.

4. Design Driven Full Stack Solutions

Short description:

And that is what we call design driven Full Stack. So how does design driven Full Stack solve those four challenges I showed you? Overhead. We're going to handle the overhead. I want to show you and introduce an innovation at Redwood called Redwood Cells. And lastly, I'll show you what it looks like to be secure by default, your frontend backend. And again, this is with Redwood. That's where I work. I'm a co-founder at Redwood. It's an open source project, so, you know, work, but there's other ways to do this across other systems.

And that is what we call design driven Full Stack. Sound good? See that now? That's good! I may be a little sleepy. So you all are helping me out. Keep it going.

So how does design driven Full Stack solve those four challenges I showed you? Overhead. We're going to have endian configuration, zero configuration, out of the box. We're going to have code generators and setup generators, so that you can get going without having to think about, wait, what add-on do I need for Storybook again? Wait, how do I actually mock data in Storybook? But then, what do I tell my back-end developers about that? So we're going to handle the overhead.

Conventions? True. I want to show you and introduce an innovation at Redwood called Redwood Cells. And Redwood Cells are a way to handle data, state and fetch. And I want to show you separation of concerns, and how we use data as a coupling, then, once we have the data structure defined, to then move into Crud and then integrate the frontend and the backend. And lastly, I'll show you what it looks like to be secure by default, your frontend backend. And again, this is with Redwood. That's where I work. I'm a co-founder at Redwood. It's an open source project, so, you know, work, but there's other ways to do this across other systems. And I just want to show you, for your stacks, some ideas and concepts that you can bring to it. So bear with me for a second.

An analogy. Alright. Say you wanted to harness all the power in the universe to build your full-stack application, you might try to seek out the infinity gauntlet, right? Because what else... I know. This is going to get, just bear with me, it's going to get a little strange, but right? We want to grab the infinity gauntlet so that we can harness the full power of the JavaScript ecosystem that wants to run us off the rails, so that we can do our full-stack application. So each one of these different steps, you can imagine, isn't that beautiful? You know, if you turn Keynote into a video game, it's a lot more fun to make slides. Each one of those is an infinity stone. Our mission is to go and grab the infinity stone so that we can get the infinity gauntlet before, is that the Mad Titan himself? Thanos is trying to get the infinity gauntlet too because every good story has a villain, so ours has a villain too, and it's Thanos. We want to ship features, and remember Thanos? He wanted to do exactly the opposite. Alright? So that's our quest. But how do you beat Thanos? We've all seen the movie, it did box office well. How do you beat Thanos? Yeah! I think I know who that was.

5. Building a Dynamic App with Redwood.js

Short description:

We're going to build a dynamic app and symbol the Avengers. We'll start with an HTML and CSS JSX file using Tailwind. Then, we'll create a dynamic web page with CRUD UI and an API. Redwood.js is a full stack, fully integrated, fully featured application that includes GraphQL and React.

Right? With a team. Okay, so here's where we're going. We need the Avengers. And what we're going to do is build a dynamic app and we're going to symbol the Avengers. See? It's fun, right? We're going to have a great time here.

Alright, because what I really want to show you is a bunch of code. But what we'll do is start with the JSX file there, and all it is is HTML and CSS. By the way we're going to use Tailwind and we're going to build a dynamic page to assemble the Avengers and all the team members there. Sound good? Alright. Let's see how this goes.

Okay, start with a quick little video. But this is the file we'll start with. It has some data in it that we're going to use and I just want to show you it's HTML and CSS. And then where we want to go to, this will be the dynamic web page that we're going to end up with, okay? Here's the CRUD UI. It's got an API with it. If you noticed, Vision was missing. That guy. By the way, WandaVision was great. Anyways, so you can add Vision in and now we've got a full CRUD application, right? That's what we're going to do.

Okay. Redwood.js. Real quick on Redwood. Started by a guy named Tom Preston Warner. He was a co-founder at GitHub. Built one of the largest, helped build one of the largest Rails applications in existence. Also built on Jekyll. And four years ago, conversations around what Redwood could be. Now, Redwood.js is a full stack, fully integrated, fully featured application that we say is going from side project to start-up as quick as possible. And includes a few of your favorite tools, right? So, you'll recognize GraphQL. React.

6. Creating a Redwood App with Storybook and Yarn

Short description:

We're at the React conference. Prisma. Storybook and we're going to use Tailwind. Infinity Stone 1. Overhead. How quickly can we go from install to coding features? We're going to create a new Redwood app. Spins up in, I know. Yarn, packages, installing. We just started Storybook. Full stack, code base, Storybook fires up, all the add-ons are already ready for you. Quick note on the Redwood project code base. You've got Yarn workspaces. Two main projects, your API and your web. A proper API, like Rails services for your business logic.

We're at the React conference. Prisma. Storybook and we're going to use Tailwind. Okay. Those are our tools.

Infinity Stone 1. See? It's more fun already, right? Infinity Stone 1. Overhead. How quickly can we go from install to coding features? And all I wanted to show you is that I wasn't cheating, all right? Well, I could have been cheating because I could have edited the videos, but you don't need to know that.

All right. So, we're going to create a new Redwood app. Spins up in, I know. Yarn, packages, installing. Okay. So, I sped all that up. We're going to CD into the directory. Oh, sorry. And then immediately we did not start our local dev server. This is really important. We just started Storybook. All right? Full stack, code base, started Storybook, Storybook fires up, all the add-ons are already ready for you. There are no stories yet because we haven't even started coding. Accessibility is activated. Storybook is ready to go. So, that was our first step, install, run the Storybook process.

Quick note on the Redwood project code base. You've got Yarn workspaces. So, there's two main projects in there, your API and your web. We call it a proper API. If you're familiar with Rails, it's going to feel and look a lot like Rails services for your business logic.

7. Creating a Page with Storybook and Tailwind

Short description:

We also have functions for server lists or using Fastify for deploy. The web is a React application. The first thing we need to do is get our page ready. We use a generator to create the page. You'll notice Storybook, which allows you to design inside of it using code. It comes with three generated files: main JSX file, story file, and a test. As you make changes to your CSS, you'll immediately see those changes inside of Storybook. Storybook is a wonderful tool for UI development.

We also have functions for server lists or using Fastify for deploy, GraphQL for the SDLs. And you'll notice Jest comes pre-config. And the web is a React application.

We'll get a bit more into that. But just, that's the code base. I don't have any more time to go into it now than we'll be looking at.

The first thing we need to do is get our page ready. And again, we're capturing stone number one here. I want to show you what we do with boilerplate.

So, this is a generator to create the page. You aren't generate page team, right? You got to start with the team page. That's done. You'll notice Storybook, the process is running and immediately Storybook, now you're seeing that page. We just have some boilerplate data that shows up and wouldn't it be nice if in one command you could just set up Tailwind? And it worked with Storybook, right? And so immediately you're designing inside of Storybook using code that you're going to use. Notice there's three files that got generated. This is going really quickly, I know. And those three files were your main JSX file, your story file, and a test. So it comes with a just test out of the box. And all I'm doing here is copying and pasting.

We want to work inside of our new page component. So I'm copying and pasting that starter code that I had. And now you have your page mocked up, not mocked up. You have your page created inside of Storybook. And as you're making changes to your CSS, in this case, I just want to replay that right there. As you're making changes to your CSS, you'll immediately see those changes inside of Storybook.

Has anybody used Storybook before? Yeah. Do you love it? Come on. We love it. Storybook is wonderful. And if you haven't used it, it's probably because of config and integration.

8. Introducing Redwood Cells and Handling State

Short description:

I recommend checking out Storybook. Next, let's simplify the hard things and introduce Redwood cells. These cells handle React State, GraphQL, client-server, fetch requests, and endpoints. In the component architecture, we have a page, a team member component for layout and styling, and a Redwood cell that handles data and passes props to the team member component. Let's generate the Redwood cell for team members, which includes handling state: empty, failure, loading, and success.

I really recommend you check it out. Storybook is an amazing tool. All right. Next up, conventions. So how can we make the hard things simple and get Infinity Stone Number 2? I want to introduce you to Redwood cells. And Redwood cells are going to handle all the hard things about React State. GraphQL, client server, because we like to talk about GraphQL, but I don't know if we like GraphQL. And also fetch request and endpoints.

This is the component architecture I'm about to build out. I started with a page. So I already have the page. Next up, I'll have a team member component. And I'm going to use that predominantly for just the layout and the styling of a team member. Page component, you could basically think about it as a wrapper. Sorry, layout. In the way I'm doing it here. But there's a middle component now. And that's the Redwood cell. And what I will use that, the work that that cell is going to do... That's a good metaphor, right? Would it be an analogy or a metaphor? I screw that up sometimes. Anyway. The work the cell is going to do is that it's going to handle the data and pass the props down to the team member component. And that's it. I'll show you that code here in a second. But first off, let's get going. And of course there's a generator for that. I want to show you generating the Redwood cell for the team members. And immediately, you see these one story, but there's four substories there. And those are handling state. Empty, failure, loading and success.

9. The Structure and Benefits of Redwood Cells

Short description:

Isn't that interesting? The team members cell in Redwood is effectively a higher order component that handles queries and states. It helps simplify complex tasks by leveraging conventions.

Isn't that interesting? Where did we get that from? And if you look at the team members cell, we have several things going inside of this one component. We have a query. We have all of our states. Loading, empty, failure, and success. We also have two other files that were generated there, the stories and the tests. But does anyone, what does this remind? This is a Redwood cell. The structure of a Redwood cell. Does this remind anyone of anything in React speak? It's effectively a higher order component. Not technically. I said effectively, because we've been corrected. But you can think of it as a higher order component. So it has the query for the GraphQL. We are using Apollo client. You have four states all inside of one component. And, again, this infinity stone, see, the analogy's really working. This infinity stone is helping us with conventions. And it's letting us leverage conventions so that we can make some things that are really hard and complex a lot more simple.

10. Cascading Code and Passing Props

Short description:

I'll show you how the code cascades down the hierarchy from the page component to the team member cell. GraphQL queries are used to pass props to the cell. The mock is created for storybook.

I talked a little bit about the cell. But, again, you'll notice at the top there's a query, GraphQL query. We'll do some more work on that. And then we have, effectively, four components, the loading, empty, failure, and success. All right.

Next video I want to show you, there's a lot of code moving around. But remember that diagram I showed you, the architecture, the hierarchy that I want to create? Page, cell, and then a team member inside of it. I'll talk you through it. But all I'm doing is moving the code down the hierarchy. So I'm kind of cascading code. So that each component can do individual work. So here we go. First we're gonna start, the page component is where the code is. And I start with importing the team member cell that I've created. So that I'll go down. I don't need this data here anymore. Right? That was never meant to be other than just to start the process. And here, for my unordered list instead, that's where the team member cell is gonna do the work. And now, I'm over in the team member cell. In that unordered list that I just copied, I'm now pasting that in. Right? Just working down the hierarchy. And I'm also... like... I know GraphQL queries. Scary. But just props. Think of props. What props do I need? And I'm putting them in my query right there. Next up is a mock. And this is a mock for storybook.

11. Mock Files and Creating the Team Member Component

Short description:

We're using mockServiceWorkers with Storybook to show the success state with mock data. You can instantly see your components with mock data across different states. There's a cell story file and a cell mock file. The story file gets its data from somewhere. We need one more component, the team member. The cell will handle the data, while the new component will focus on the layout using HTML and CSS.

Right? So if you've never seen a mock file before... by the way, we're using mockServiceWorkers for this. It goes with Storybook. Right? So, it's what Storybook is using to now show the success state with mock data. Isn't that cool? And what you can't see... I just couldn't do it side by side at the time coding. But you're working Storybook and instantaneously you're seeing your components with mock state across each of the states... sorry, mock data across each of the states immediately. So, that's pretty fun.

One thing I want to show you really quickly, there's a cell story file and a cell mock file. There's no magic there. It's just an import. All right? Kind of makes sense? The story file is getting its data from somewhere. All right.

Next up, we have... there was one more component we needed. Do you remember? Team member. You do remember. You were actually paying attention. That's good. Team member. And... I want the cell to do the work of the data. Because that's query and state for me. So, that's fetch and state. I want to move everything else into a new component that I'm calling my team member. And that's where I can think about my layout for the team members. So, that'll be HTML and CSS. Again, just moving code around. It's strange to not be typing this.

12. Importing Team Member Component and Using Mocks

Short description:

But it's so much more efficient. We're now importing the team member component into the team members cell. Lastly, that mock that I created for my cell, I can use that same mock file for the team member component because I want to see that in storybook. I have all of my components displaying stories inside a storybook. It's a beautiful thing and it's really fun and magical to use.

But it's so much more efficient. And you don't get to discover what a terrible typist I am. All right, here we are. We're now importing the team member component into the team members cell, the plural to help us remember that it's iterating. Cleaning up our props. And here inside the team member, this is the component. And now this is where all of the HTML that's going to be for layout is going to be. And I need to make sure I pass in member. Actually, I'm glad I'm not doing this live right now. That wouldn't have gone well. You would have not been impressed. All right. Lastly, that mock that I created for my cell, I can use that same mock file for the team member component because I want to see that in storybook, right? In a cell, we'll be passing the props down to a team member, so in this case, I can handle that at the mock level. And then immediately, and again, it's more impressive you can see it full screen. I have all of my components displaying stories inside a storybook, right? The data is being passed up at the page level. I can see the mocks for the cell and the member. It's all getting, it's just all there. It's a beautiful thing and it's really fun and magical to use.

13. Coupling Front and Back End with Mock Data

Short description:

Okay. So we have two stones so far. We're going to couple the front and back end development using mock data and state. We'll create a model in our data schema using the same structure as the team member cell query. With Redwood dev server, we can quickly move from local dev to working across the stack. Alignment between front end and back end is crucial, and we achieve it with cells and mock data.

Okay. So we have two stones So far. Following a bit. Is that cool? Has anybody seen something like that before with storybook? Yeah, I didn't think we wanted this to be. This was a vision we had for use of storybook. So I know it's a vision of storybook. We love working with the storybook team that they had as well.

So all right, two stones down, we have one stone to go here. Infinity stone three, separation of concurrence, actually, we have two. How can we couple the front and back end development using mock data in state? And how we're going to do that is we're going to take that query from the team member cell. We have our data structure already. And now in our data model or in our data schema, we're going to create a model using that same structure. We're using prisma. Don't worry much about the attributes. Right. But you've got the same data model, ID, name, image, URL. And let me show you how quickly we can move once we start up the Redwood dev server.

So now we're in local dev. Right. We're not working the storybook anymore because we're going to work across. And this is that coupling piece. Right. So typically your front end or you would work up everything you need for the front end UI. And then now you've got to figure out what that's going to look like in the backend or if you're a backend developer, you're going to start in the backend and you're going to think through what tables and models you might need. And then you can try to work forward in the front end. And it's just like when you're building a tunnel under a mountain. Like if you miss, you miss by a mile. Right. So trying to bring those two things together, you really want to have alignment. And that's what we're using cells and mock data and mock state to do.

14. Optimizing Workflow for Performant Teams

Short description:

What happened there is with the Prisma Migrate command, we now have a local SQLite database with the same schema and table that's needed for the front end code. I want to talk about Thanos and the importance of performant teams building performant products. We need to optimize the process for the people to affect the whole.

What happened there is with the Prisma Migrate command, we now have a local SQLite database with the same schema and table that's needed for the front end code.

This will be quick. This is what I really wanted to talk to you about. I want to talk about Thanos. There's a lot of wonderful focus on tool performance. And rightfully so. Web performance, web performance. That's important. We need to do that. But Thanos, I'm talking about Thanos to a group of adults. Thanos, how do you beat Thanos, again? With a team. The Avengers. So, if you want to beat Thanos, it's gonna do it. You need a team. I love this. This was so great. It's a little bit ridiculous. Performant teams build performant products. There's a massive body of research talking about this, right? We can focus on technology, and we need to, but we also need to affect the whole, and we need to optimize the process for the people in order to affect the whole, alright? So, let me show you what that looks like in this scenario when you optimize a workflow for the people that we'll be working on the application, what that might look like.

15. Creating a Full Stack Application with CRUD Demo

Short description:

In one command, we run scaffold for the UI and API, creating a full stack application. The generated files include SDL and service files for logic, as well as different cells for data handling. We showcase the admin UI with a quick CRUD demo, starting with an empty team page and adding a team member. We seamlessly transition from front end to back end. Lastly, we touch on the importance of security.

So, in one command, we're gonna run scaffold for the UI, and this will create everything we need in the API, all of our endpoints based on that data model that we have, and this will create everything we need in the UI so that we can run CRUD. And at this point, we now have a full stack application.

There was a lot of files that were generated, but again, it's the SDL files, it's the service files where our logic takes place, and the front end, it's the different cells, they're doing the data work for us so that we can do CRUD. And really quickly, this is the actual admin UI, quick CRUD demo. You'll see that there's a...there's nothing on the team page. We don't have any team members created yet. We're now inside of a dynamic application. Falcon, apparently, is who I chose to start with. Right? And boom, we have Falcon. If we go back, team members edit, we can edit that. That's pretty cool, right? All right. We just went from front end to back end in one flow. Oh, by the way, empty state, right? It's there for you. And I kind of...yeah, a little bit but if I made it too simple, then your mind might not be blown but it should be blown just a little bit. Just a little bit.

There's one last infinity stone and I'm going to make this really quick. What was the last infinity stone that we needed? I skipped that real fast, right? Security. So how can we do end security which I promise that would be our bonus that we get to. Oh, man. Spoiler. And I'll show this really quickly. But first, did we do it? Main display. It won't work if my displays don't work. Am I up? No. It's my thing, it's not going to go. I know. You know, it's a bummer when the grand finale doesn't go the way you want it to. But that's quite all right. I'm going to skip that part and go back to my slides.

16. Redwood Authentication and Workflow

Short description:

Redwood has authentication by default and in one command. SDL files have directives that make them secure by default. You can easily change an SDL file from authenticated to skip off to create a public API. Adding private to a route in the routes file hides it and redirects to the homepage. These features were designed to create a user-friendly workflow.

I'm going to skip that part and go back to my slides. Redwood has authentication by default and in one command, and I'll just talk you through this really quickly. When you set up Redwood authentication, those SDL files that I showed you, it has directives on them and they're all secure by default. So that public page that you saw, for the team members, all of that would no longer be accessible, although the page itself would be, but your endpoint would be secure by default and then with one change of a directive on an SDL file, you would change it from authenticated to skip off. You would have a public API. And then inside of our routes file, if you add private to any route, that route now becomes hidden. You can redirect them to the homepage. And again, why did we do those kind of things with Redwood? We did those kind of things because we wanted to build a workflow for people.

17. Final Remarks and Redwood Community

Short description:

If you are interested in Redwood, the best way to learn Redwood is to do the Redwood tutorial and join our community of over 400 contributors. Follow me on Twitter for more information. Thank you for your generosity.

All right, I have one final slide. Can we get it back up by a chance? I wanted this was, I was excited about this one too. Is it going to come? No. All right. I had Tony Stark at the end. You've got to end a presentation with Tony Stark if you're going to talk about Thanos, right? All right, the slides aren't coming. Okay. No, we get it. I mean, come on. Right? All right. Thank you. You were very gracious. That is not the way I wanted to end.

If you are interested in Redwood, the best way to learn Redwood is to do the Redwood tutorial, and the best way to be successful with the tutorial is to join our community. We have a wonderful community of contributors, over 400, and we love our contributors. We have a helpful dynamic on our forums and our Discord, and lastly, I promise I'll get this demo up online and you can take a look at it there. Follow me on Twitter if you want to find out more. Thank you. You're very generous. Thank you, David. Reminder, David, nobody moves. We'll be at the speaker's booth outside where maybe he'll do the demo for you. That's your time, not my time. All right, David, what about server side rendering with Redwood and TypeScript? Yeah. What about server side rendering and TypeScript? I meant submission, and I omitted. Reminder to leave quietly out of respect so we can all hear. Thank you. No, that's great. Yeah, fully typed. I meant to mention that when we started the project, but you can pass TypeScript.

18. JavaScript Project and Redwood Features

Short description:

I just started with a JavaScript project because it makes the demos a little bit easier when you're working through code. We don't do server side rendering right now. Can Redwood generate TypeScript contracts based on the mocked API? Redwood supports other frameworks besides React. It's an open-source project. The importance of community and team in my life.

I just started with a JavaScript project because it makes the demos a little bit easier when you're working through code. Server side rendering means a lot of things in today with marketing speak. We don't do server side rendering right now. We do a pre-render, which is basically a static site generation. We have dynamic pre-rendering coming up soon and you will... don't owe me too much, but you'll see a server-side rendering before the end of the year.

Is that a promise or a threat? It'll be great. All right. Can Redwood generate TypeScript contracts based on the mocked API? Probably, Orda. It's not a problem you want, because you would need to support some forms of RLs. Yeah, so see, that's Orda, TypeScript guy. So what Orda said, and this is helpful, that's probably the right question. But in the context of Redwood, that's not something you would need. Cool.

Does it support other frameworks besides React? That's a fantastic question. Redwood, because of that workspaces that I mentioned, you can run Redwood as a standalone API, and why would we use GraphQL if we didn't intend it to be multi-client? Because today, what products are not multi-client? I mean, there's a lot of great sites that stay there, but we intend it to be multi-client from the start. So yes, there's a lot of great startups right now, using Redwood's API with Next, running multi-client across Electron, CLI, using different websites that they're deploying. So yes, is the answer. And is it free, or how is it monetized? Yeah, Redwood's an open-source project. It's sponsored, but it's open-source. If I didn't hit that grade at the beginning, that's my bad. Open-source and will-be open-source. Before I let you all go, you had something you wanted to share, I believe. Yeah, I did. Thank you, Ellie, for the time. So the last few years have been a little crazy for everybody, and what I wanted to leave you with is how important community and team is in my life. There's a really good friend here that I've never met before, and... Sorry, it's been a long week. Toby, I just wanted to say hi to you, because none of this was done by me alone. It was done with a wonderful community of people, and it's a shame that I'm the only person up here telling you about it. So I wanted to say Toby, come up here. I just wanted to meet you for the first time. Hey, man. That's a great hug. Thanks, buddy. I flubbed it at the end. Nice to meet you. It's really good to meet you. That was it.

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

Don't Solve Problems, Eliminate Them
React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
From GraphQL Zero to GraphQL Hero with RedwoodJS
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!
Full Stack Components
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.
Jotai Atoms Are Just Functions
React Day Berlin 2022React Day Berlin 2022
22 min
Jotai Atoms Are Just Functions
Top Content
Jotai is a state management library. We have been developing it primarily for React, but it's conceptually not tied to React. It this talk, we will see how Jotai atoms work and learn about the mental model we should have. Atoms are framework-agnostic abstraction to represent states, and they are basically just functions. Understanding the atom abstraction will help designing and implementing states in your applications with Jotai
Debugging JS
React Summit 2023React Summit 2023
24 min
Debugging JS
Top Content
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
RedwoodJS: The Full-Stack React App Framework of Your Dreams
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.

Workshops on related topic

React, TypeScript, and TDD
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
Web3 Workshop - Building Your First Dapp
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
Nader Dabit
Nader Dabit
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
Remix Fundamentals
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Kent C. Dodds
Kent C. Dodds
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
Vue3: Modern Frontend App Development
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
Mikhail Kuznetcov
Mikhail Kuznetcov
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Top Content
Featured WorkshopFree
Alba Silvente Fuentes
Roberto Butti
2 authors
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.
Back to the Roots With Remix
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
Alex Korzhikov
Pavlik Kiselev
2 authors
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)