RedwoodJS: A Framework Built for the Full-Stack Jamstack

On this episode of the Smashing Podcast, we're joined by Anthony Campolo, a community champion for RedwoodJS. We're exploring what RedwoodJS is, what distinguishes it from other frameworks, and what it means for a Jamstack framework to be truly full-stack.

RedwoodJS is an ambitious project that aims to bring the full power of a modern web application framework to the Jamstack architecture. Campolo explains that while the Jamstack is often associated with static site generators and serverless functions, RedwoodJS is designed to handle everything from the database to the user interface, providing a cohesive developer experience that you might otherwise have to piece together from multiple libraries.

Beyond the Static Site

Campolo clarifies that Redwood isn't just for building simple marketing pages or blogs. Its goal is to make the entire process of building a dynamic web app more approachable. The framework combines several key technologies into a single, integrated toolset, so that developers don't need to spend time on the complex plumbing that typically connects the frontend and the backend.

This is where the "full-stack" label comes in. Instead of using separate tools for the React frontend and the GraphQL API, Redwood structures the whole project from the start with a clear separation between the web side and the api side. The framework then generates a lot of the boilerplate code required to get those two sides communicating, letting you focus your attention on building the actual features of your application.

Integrating the Data Layer

A distinctive part of the Redwood design is its opinionated approach to data. Campolo highlights that Redwood is designed to work seamlessly with the data model, using a declarative setup that helps keep the database schema in sync with the application's code. For developers coming from the traditional server-side world, this integrated experience feels familiar, while still providing the deployment and scaling benefits of a serverless setup.

A major part of making that data layer powerful and easy to use is the framework's adoption of GraphQL. By pairing Redwood's structure with the query language's ability to request exactly the data you need, it helps avoid the common pitfalls of over-fetching on the client. The system also handles things like authentication and authorization, so that integrating secure user interactions is less of a chore and more of a standardized process that comes included with the box.

The Developer Experience

One of the most interesting takeaways from the conversation is the focus on lowering the barrier to entry for developers who are used to building full-stack apps. Since Redwood is integrated end-to-end, there is less time spent on configuration. Newcomers can quickly scaffold out their database structure, generate pages, and build out GraphQL resolvers without having to fiddle with separate configuration files for different services.

Campolo is particularly active in the Redwood community and has published a series entitled "A First Look at RedwoodJS." He discusses the philosophy of the framework, comparing the "monolithic" nature of a framework like this favourably to stitching many different solutions together. The project aims to give you back the structure of traditional web frameworks, but built in JavaScript and optimized for the modern, serverless era.

Episode Takeaways

The episode closes with a clear picture of Redwood's potential. It doesn't view the Jamstack as just a way to serve static pages, but as a robust architecture capable of hosting the most interactive and content-driven web applications. It offers a unique balance, handling the frontend rendering, the backend logic, and the data persistence in a streamlined workflow.

If you'd like to learn more, you can check out the main website at redwoodjs.com, or follow Anthony on Twitter.

Show Notes and Weekly Update

We also took a moment to review the latest articles from around the web, touching on a few topics relevant to modern web development and frontend engineering.

RedwoodJS: A Full-Stack Framework for the Jamstack

RedwoodJS describes itself as a full-stack serverless framework for the Jamstack. It aims to push the boundaries of what a Jamstack application can be by extending the familiar "push to deploy" paradigm beyond the front end to the back end as well. The framework wants to give developers the same ease of deployment for their entire codebase, keeping everything connected.

The project is the creation of Tom Preston-Werner, known for founding Jekyll, creating the TOML configuration language, and serving as GitHub's original CEO. His work on Jekyll and GitHub Pages laid groundwork for the modern Jamstack movement. RedwoodJS applies those older ideas about static site generation to a modern stack that incorporates GraphQL and serverless functions, treating them as glue code to make applications work.

Monorepo Structure and Conventions

A Redwood project is a monorepo. It contains a web folder for the React front end, which closely resembles what you'd get from a Create React App setup. The api folder holds the back end. The framework is very much a "convention over configuration" system, in the spirit of Ruby on Rails, but implemented with modern web technology rather than a server-rendered stack.

The React integration goes beyond just using the library. Redwood does not require developers to bring in a state management library or even a router. The framework provides its own router and includes a lot of GraphQL tooling out of the box. This means React is pre-configured to talk to a GraphQL API, which the creators felt was still a major hurdle in development. As Anthony Campolo puts it, the framework's tagline is "We do your webpack config for you."

Redwood's philosophy stems from the idea that best-of-breed solutions are hard to leverage due to high start-up costs and complex integration. By handling those pieces, it is intended to remove a major pain point for developers getting started.

Data Fetching and Cells

A core pattern in Redwood is the "cell," which is a declarative way to handle data fetching. A cell is a default way to write a GraphQL query and have the page automatically render based on the state of that request—whether it is loading, errored, or has returned data successfully. This setup comes with Apollo as the GraphQL client under the hood.

With a cell, developers don't need to write any Apollo boilerplate or if/then logic to check the request status. This declarative interaction lets developers just write GraphQL queries and define what to show for each state. This recognizes that React itself avoids imposing an architecture for data fetching. Redwood picks up where React leaves off by introducing a structure that handles this common, complex problem in a consistent way.

The Back End: Prisma and GraphQL

GraphQL serves as the mechanism for the front end to communicate with the back end. This API is intended to be an alternative to a RESTful design, sending queries that specify the exact hierarchical data structure the client expects. This reduces the need for back-end developers to create numerous API endpoints.

By default, the database layer is handled through Prisma, which is described as a query builder or an ORM that manages migrations and SQL. Developers define a schema.prisma file with models and types. A default db.js file in the API folder comes preconfigured with a Prisma client. The framework functions with relational databases by default, a choice that comes from the team's background with Rails' Active Record. While Prisma can handle switching from SQLite for development to Postgres for production, developers aren't strictly required to use it. It is possible to bypass Prisma entirely and connect directly to a database that provides its own GraphQL API, such as FaunaDB, though you would then lose the convenience of Prisma's CLI.

Serverless Deployment

Redwood tends to favor a specific approach to back-end deployment. The API consists of SDL (schema definition language) and "services" (methods for talking to the database). These are stitched together into a single GraphQL handler optimized for an AWS Lambda function.

The deployment targets are not permanently fixed. The framework is currently optimized for Netlify and AWS Lambda, but there is work in progress to support other providers. If you follow the official tutorial, you'll deploy the front end to Netlify and the back end to a Heroku Postgres instance, connecting the two via environment variables.

The framework is distinct from a self-hosted model where server-rendered code runs alongside your user code. It's a deployment tool that takes all the written code, bundles it into a function, and pushes it directly to the cloud, so a relational database like MySQL isn't running on Netlify—it's deployed to a service like Heroku to handle that part of the architecture.

Scaffolding, Generators, and Authentication

Redwood strongly emphasizes code generators. This is perhaps its biggest key feature: you can generate pages, layouts, cells, and even run a scaffold command to create an entire CRUD interface. The intent is to give you a working start very quickly, similar to the effect DHH's original Ruby on Rails demo had decades ago. Alongside that are tools for generating code and a Tailwind configuration generator, as well as generators for pages and layouts.

Authentication is also a key integrated feature. Redwood offers a few built-in options, such as Netlify Identity, Auth0, and Magic Link. Developers can secure routes using a private route component. The login form itself is handled by the authentication service, which helps avoid a common source of bugs and security issues. There is also support for role-based access controls and authorization in progress. The framework advises using these external services and a dedicated auth tool instead of writing your own because authentication is a complex area to do securely.

Maturity and Ecosystem

While announced in roughly March, RedwoodJS had been in development for about a year prior by its core team. These contributors have backgrounds in scaling Rails applications. As of the podcast recording, the project was not yet at version 1.0, but it already had a handful of applications in production, including a real-time data visualization app called Predict COVID and repeater.dev, a cron-job-like tool for the Jamstack.

The framework benefits from substantial community focus. While development is driven by four full-time core team members, the project is designed to attract contributions from the wider community, welcoming even non-code contributions like documentation fixes and blog series from newcomers. There is also a public "Roadmap to 1.0" which outlines what the team plans to achieve, with a target of releasing a 1.0 by year's end.

The architecture is chosen to make Redwood a good fit when a multi-client application is the goal. If you anticipate building a mobile client or multiple view layers for a single API, its GraphQL centralization and the resulting design are pointed out as a major initial advantage.

The project's trajectory suggests it is not monolithic in a way that breaks when pieces change, because it is built largely from existing, popular tools. This makes it quite modular, allowing developers to swap out parts even though it aims to be highly integrated.