Getting started with RedwoodJS
Tags: graphql, jamstack, react, tutorial
Published: 2020-07-16 17:17:44

---
title: Getting started with RedwoodJS
published: true
date: 2020-07-08 17:30:04 UTC
tags: graphql,jamstack,react,tutorial
canonical_url: https://blog.logrocket.com/getting-started-with-redwoodjs/
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/4pw0jvus8trttfhpsbuj.png
---
**Written by [Blessing Krofegha](https://blog.logrocket.com/author/blessingkrofegha/)**✏️

Setting up and configuring a full-stack application can be a pain in the neck. Imagine how easy it would be to develop a JAMstack app if you didn’t have to deal with SSG or headless CMS?

In this guide, I’ll introduce you to RedwoodJS, a full-stack JAMstack framework built on React, GraphQL, and Prisma, and demonstrate how to use some of its key features.

## What is RedwoodJS?

Many prominent tools and frameworks aim to simplify the development workflow. Some of them come with predefined setup for webpack, Babel, etc., which makes the process cumbersome. Redwood is a framework that makes decisions for you under the hood.

According to the [documentation](https://redwoodjs.com/docs/introduction), Redwood is “an opinionated, full-stack, serverless web application framework that will allow you to build and deploy JAMstack applications with ease.”

Redwood is a React-like frontend that’s statically delivered by CDN. It talks via GraphQL to your backend running on AWS Lambdas, and it’s deployable by a simple `git push`.

[![LogRocket Free Trial Banner](https://i0.wp.com/blog.logrocket.com/wp-content/uploads/2017/03/f760c-1gpjapknnuyhu8esa3z0jga.png?resize=1200%2C280&ssl=1)](https://logrocket.com/signup/)

## **Features**

Before we get started, let’s break down the key frontend and backend features we’ll highlight throughout this tutorial.

### Frontend features

- Unique file structure and formatting
- Simple but powerful routing (all routes defined in one file) with dynamic (typed) parameters, constraints, and named route functions to generate correct URLs
- Cells — a declarative way to fetch data from the backend API
- Generators that use CLIs ** ** to generate pages, layouts, and cells
- Predefined helpers and conventions for form validation and error handling for both the client and server side

### Backend features

- Boilerplateless GraphQL API construction
- Generators that produce SDL and services on the fly
- Easy CRUD, which makes a scaffolding generator for CRUD operations around a specific DB table
- Database migrations via Prisma 2

### Deployment features

For deployment, RedwoodJS features first-class JAMstack-style deployment to [Netlify](https://www.netlify.com/).

## Prerequisites

To get started with RedwoodJS, you need some basic knowledge of React, GraphQL, and Prisma. That said, you don’t need to be an expert to pick up the Redwood framework.

You also need to have either Node version 12 or higher or yarn version 1.22 or higher installed in your machine. Otherwise, you might encounter issues along the way.

## Installation

Redwood uses yarn to scaffold your app.

```jsx
#Run the command and specify your folder name
yarn create redwood-app ./redwoodapp
```

After successful installation, you’ll have a new directory, `redwoodapp`, containing several directories and files. Change to that directory by running:

```jsx
cd redwoodapp
```

To start the development server, run:

```jsx
yarn redwood dev
```

A browser should automatically pop up to [`http://localhost:8910`](http://localhost:8910/) and you’ll see the Redwood welcome page.

![Redwood Welcome Page](https://i1.wp.com/blog.logrocket.com/wp-content/uploads/2020/07/redwood-starter-page.png?resize=720%2C297&ssl=1)

## File structure

Redwood’s file structure has two parts: the `api` folder and the `web` folder. These are commonly referred to as workspaces.

Here’s what Redwood’s file structure looks like:

![Redwood File Structure](https://i2.wp.com/blog.logrocket.com/wp-content/uploads/2020/07/redwood-file-structure.png?resize=720%2C656&ssl=1)

### Web workspace

The web workspace comprises all component- and static-related files.

The `public` folder contains all the static assets, such as `favicon`, `README`, etc.

`src` holds other subdirectories, including:

- `components`, which contains your usual React components along with other Redwood cells
- `layouts`, which contains reusable components that wrap your content and are shared across other pages in your application
- `pages`, which contains components and is optionally wrapped inside `layouts`
- `Routes.js`, which defines all the routes in your app

### API workspace

The API directory contains two folders: `prisma` and `src`.

`prisma` determines how data is delivered to the frontend and is ascribed to the term as plumbing the database. It has two files:

- `schema.prisma` contains the tables and columns, better known as the database schema
- `seeds.js` is responsible for populating your database with any data that needs to exist for your app

`src` contains all other backend code and four more directories:

- `functions` contains any Lambda functions your app needs, in addition to the `graphql.js` file autogenerated by Redwood
- `graphql` contains your GraphQL schema written in a schema definition language (SDL).
- `lib` contains one file, `db.js`, which instantiates the Prisma database client. You can use this directory for other codes related to the API side that doesn’t fit in functions or services
- `services` contains business logic related to your data. When querying or mutating data for GraphQL, the resolvers are taken care of in a format that’s reusable elsewhere in your app

To learn more about the file structure, check out the [Redwood docs](https://redwoodjs.com/tutorial/redwood-file-structure).

## Routing

Redwood Router is unique compared to React Router. It’s a combination of [React Router, Reach Router](https://dev.to/bnevilleoneill/the-future-of-reach-router-and-react-router-40n2), and its own router.

Redwood Router (RR) is designed to list all routes in a single file, eliminating the need for nesting routes (which is not the case with React).

To use Redwood Router, import the `Router` and `Route` components from the `@redwoodjs/router` package. Creating a `Route` in Redwood requires `path`, `name`, and `page` to be passed as `props` into the `Route` component.

```jsx
<Route path="/contact" page={ContactPage} name="contact" />
```

- `path` specifies which URL path to match
- `page` specifies which component to render when the path is matched
- `name` calls the `Route` component from the `Link` component. For example:

```jsx
const AboutPage = () =>
```

RR makes it possible to include parameters in your `path` prop.

```jsx
<Route path="/user/{id}" page={UserPage} name="user" />
```

It has a cool hook called `useParam` that enables you to extract the parameters.

```jsx
import { useParams } from '@redwoodjs/router'
const MainComponent= () => {
  const { id } = useParams()
  // ...
}
```

By default, JavaScript specifies parameters as strings. But with Redwood routing, it offers a suitable pattern to convert your parameters to any data type of your choice.

You can specify route parameter types right in the `path` props.

```jsx
<Route path="/admin/{id:Int}" page={AdminPage} name="admin" />
```

By using `:Int` annotation on the code above, the `Route` parameter will only match digits by using regex `(/\d+/)` and then use `Number()` to convert the parameter into a number.

### **Code splitting**

By default, RR (when used in a Redwood app) will code-split on every page, creating a separate, lazy-loaded webpack bundle for each. When navigating from page to page, RR waits until the new page module is loaded before rerendering, thus preventing the “white flash” effect.

Check out the [Redwood Router documentation](https://redwoodjs.com/docs/redwood-router) to learn more about this feature.

## Fetching data with cells

Data fetching in Redwood is different from the traditional asynchronous convention. The frontend and backend process data independently from each other. Usually, the frontend loads first while it waits for the data. In most cases, a loading indicator or spinner shows that data is fetched.

Redwood uses a pattern that adopts a declarative approach for fetching data from the server side (GraphQL).  A cell is a higher-order component that provides a dynamic sequence whereby it retrieves data from an API showing a loading state using a placeholder and then displays the result as a reusable pattern.

The cell contains the GraphQL query and `loading`, `empty`, `error`, and `success` states, each one rendering itself automatically depending on the state of your cell. All you need to do is specify the query; Redwood does all the magic for you under the hood.

A typical cell file looks like this:

```jsx
export const QUERY = gql`

  query {
    posts {
      id
      title
      body
    }
  }
`
export const Loading = () => <div>Loading...</div>

export const Empty = () => <div>No posts yet!</div>

export const Failure = ({ error }) => (
  <div>Error loading posts: {error.message}</div>
)

export const Success = ({ posts }) => {
  return posts.map((post) => (
    <article>
      <h2>{post.title}</h2>
      <div>{post.body}</div>
    </article>
  ))
}
```

To see a cell, you must import it into your `page` component.

```jsx
import BlogLayout from 'src/layouts/BlogLayout'
import BlogPostsCell from 'src/components/BlogPostsCell'

const HomePage = () => {
  return (
    <BlogLayout>
      <BlogPostsCell />
    </BlogLayout>
  )
}

export default HomePage
```

In the code above, we imported a `BlogPostCell` and wrapped it inside the `BlogLayout` component.

Head to the [Redwood cells documentation](https://redwoodjs.com/tutorial/cells) for more details.

## **Forms**

[Redwood forms](https://redwoodjs.com/tutorial/everyone-s-favorite-thing-to-build-forms) have a lot of helper methods that make form handling and validations much easier to implement in web applications. It uses [React Hook Form](https://react-hook-form.com/) to make the form experience unique.

## **Command line generators**

Redwood generates files using is own unique CLI inspired by [Rails command line tools](https://guides.rubyonrails.org/command_line.html). This way, you can create any file inside the exact directory specified by you.

The Redwood CLI has one major entry point command, `redwood` (alias: `rw`), for developing an application.

You might use `generate` or `g flag` — either works fine.

![Redwood CLI](https://i0.wp.com/blog.logrocket.com/wp-content/uploads/2020/07/redwood-cli.png?resize=720%2C503&ssl=1)

The [Redwood CLI](https://redwoodjs.com/docs/cli-commands) tool automates repetitive tasks, such as generating files (pages, components, cells, etc.) and migrating the database, so you can work on what makes your application special.

## Pros and cons of using RedwoodJS

Below are some reasons you might want to try Redwood in your next application.

- Redwood accommodates any full-stack application because it’s integrated with services, databases, and testing. It has a deployment paradigm that scales efficiently and requires almost no intervention. Plus, it uses the React frontend architecture and GraphQL, Prisma, and Apollo as its backend
- Redwood adopts the [JAMstack approach](https://dev.to/bnevilleoneill/why-you-should-be-using-jamstack-2id9) to building web applications
- The tools and conventions in Redwood make building web applications a breeze compared to other frameworks. You can develop a CRUD application in Redwood in two minutes without any configuration

There also are a few bottlenecks to consider when using Redwood.

- Redwood is in its alpha stage, so it wouldn’t be advisable to develop a production-based app just yet. I believe the team is working hard to make a stable release soon
- There are limitations related to Lambda function length and issues with connecting serverless to relational databases

[Predict COVID-19](https://predictcovid.com/) is one of the first sites to use Redwood in production.

## Conclusion

When RedwoodJS becomes stable, it’s not hard to see it evolving into a standard for building full-stack web applications. Developers will benefit from the continued performance and feature upgrades over time and with minimum effort.

Redwood makes your work easier by making logical decisions under the hood for you, enabling you to develop robust apps with less setup.

To learn more about Redwood, check out the following resources.

- [Redwood documentation](https://redwoodjs.com/docs/introduction)
- [RedwoodJS video tutorial](https://www.youtube.com/watch?v=tiF9SdM1i7M&list=PLKZBbhGUj_17Fgx7oArjk9T7yOkueEdWq) by Rob Cameron

* * * 
## Full visibility into production React apps 

Debugging React applications can be difficult, especially when users experience issues that are difficult to reproduce. If you’re interested in monitoring and tracking Redux state, automatically surfacing JavaScript errors, and tracking slow network requests and component load time, [try LogRocket.](https://www2.logrocket.com/react-performance-monitoring)

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/eq752g8qhbffxt3hp9t4.png)

[LogRocket](https://logrocket.com/devto) is like a DVR for web apps, recording literally everything that happens on your React app. Instead of guessing why problems happen, you can aggregate and report on what state your application was in when an issue occurred. LogRocket also monitors your app's performance, reporting with metrics like client CPU load, client memory usage, and more.

The LogRocket Redux middleware package adds an extra layer of visibility into your user sessions. LogRocket logs all actions and state from your Redux stores.

Modernize how you debug your React apps — [start monitoring for free.](https://www2.logrocket.com/react-performance-monitoring)
* * *

The post [Getting started with RedwoodJS](https://blog.logrocket.com/getting-started-with-redwoodjs/) appeared first on [LogRocket Blog](https://blog.logrocket.com).