My View on RedwoodJS
Playing with RedwoodJS, an opinionated, full-stack, serverless web application framework
When I listened to the React Podcast episode about RedwoodJS two weeks ago, it sparked a lot of excitement in me. I wanted to try it out immediately. After working with it a bit, I’m still impressed but also see where this framework needs to be polished.
In this article, I want to share my thoughts about it.
What Is RedwoodJS?
Redwood is an opinionated, full-stack, serverless web application framework. It works with the JAMstack and aims to make full-stack web application development and deployment easier. It is initiated and led by Tom Preston-Werner, the co-founder and former CEO of GitHub.
Redwood is based on the JAMstack. That means your front end should be pre-rendered during build time and deployed to a CDN to achieve faster loading times and better scalability. These static sites are enhanced by JavaScript executed in the client to serve additional assets or to connect to your APIs or third-party services.
For the back end, Redwood standardises the way of creating and writing your back-end APIs. With Redwood, all of these APIs are serverless functions and can be, in a lot of cases, automatically generated. With that architectural choice, Redwood embraces a lot of functionality of current JAMstack hosting providers like Netlify and takes work from you regarding scalability.
How Does RedwoodJS Work?
Redwood splits your application into two parts, front end (web) and back end (API). It uses yarn workspaces to enable both parts in a single monorepo.
The web front end is (currently) written in React with a component architecture inspired by Gatsby.js or Next.js. Individual pages belong to a page’s folders. Components used within these pages go into a component folder. Components and pages can be individually examined via Storybook and unit or integration tested via Jest. The React application is pre-rendered during build time and deployed to a CDN as a static site.
The back end uses a GraphQL API based on Apollo. Your API’s business logic is organised into services. These services and your GraphQL API are deployed as serverless lambda functions on AWS. They can connect and access a database via Prisma. Prisma provides an abstraction layer between your actual database technology and your database schema. The database is not included with Redwood and needs to be configured by yourself. As Prisma is used as an abstraction, you can currently use any relational database that Prisma supports.
What Are the Promises of RedwoodJS?
Redwood provides a lot of generator functionality that aims to make the creation of code in your application easier. For that, it relies heavily on standards in terms of folder structure and naming conventions.
For example, one aspect is the generator CLI. Redwood provides you with generator CLI commands to create your front-end pages, layouts, and components but also your back-end services based on your provided Prisma database schemas. And it does not end there. Redwood uses a technique inspired by Ruby on Rails called scaffolding that does not only generate your back-end services based on your database schema, but it also generates your front-end components and pages based on that schema. That makes the creation of CRUD operations and accessing them on the front end effortless.
Redwood introduces a concept called Cells too. Cells are abstractions for your front-end data fetching. A Cell provides you with automatically generated React components that represent the current state of your data fetching. These can be Loading, Empty, Failure, and Success. Based on these states, you can act in your front end and provide feedback to your user.
There are other things to make your life as a developer easier, such as providing components to build and manage forms in your front end or to handle authentication. With all those “little helpers,” Redwood speeds up the application development and can quickly create a prototype of your application.
What Are the Open Fields on RedwoodJS?
As with many opinionated frameworks, it breaks when you step outside the lines. You pay with flexibility and gain speed. Redwood is not different in that case. Yet depending on your individual development needs, that can be a benefit. That flexibility isn’t necessarily always needed, especially in a team development effort. Then conventions can be a charm to create a code base that is maintained and enhanced in the same way by every team member. However, in my opinion, there are still a few things that should be addressed for a production-ready framework.
Currently, Redwood only supports lambda serverless functions. Functions from other cloud providers, such as Azure or Google, are currently not supported. And also, in the case of Netlify, these functions are only deployed to a U.S. region. With that said, this is a problem with Netlify and not necessarily Redwood.
By using Prisma as an abstraction layer, Redwood limits itself to databases that Prisma supports. Those are currently only relational databases. Prisma is working on non-relational database support. So hopefully, we see non-relational database support in Redwood in the future.
Scaffolding looks promising to free you from the nasty boilerplate code you need to write in the front end and back end to access your data. However, when using Prisma relations between different data models, these cannot be automatically generated. That is known, and the Redwood team is working on a solution.
What is also currently limited is TypeScript support when creating your project. There is no automatic option and you need to configure it manually via a babel. However, I noticed that some imports then need to be manually added to your Routes and other components to use TypeScript without errors.
Conclusion
Redwood.js looks promising and I’m looking forward to seeing version 1.0. I can see it making the creation of web applications based on the JAMstack combined with serverless a lot easier. It takes away and enforces the creation of a good folder and module structure. For that, it is opinionated and takes a bit of your freedom. However, I see how that can be a benefit to enforce a good application architecture.
For me, a few improvements still need to be made to use it for a production application. The Redwood team knows about them and is working on fixing them. Once that’s done, I’m looking forward to a great framework that combines a very good tech stack and speeds up our development of scalable serverless web applications.
Update: I want to give an update on the fact I made that Redwood is limited to Prisma and the database that Prisma supports. Redwood does not necessarily need Prisma as a database client and you can import any database client you like. For example, there are projects that have used FaunaDB, Neo4J, an S3 bucket. @anthonyCampolo Thank you very much for the hint!
References
I have acquired my knowledge for this article from Redwood's documentation and by trying it out.
