I’ve written previously about my quest for an Isomorphic Typescript NERP (Node, Express, React, Postgres) framework. What I’ve wanted for years is Rails for Typescript. Redwood.js offers all the features I want, and some I’m not sure about. It recently reached its version 1.0 release, so I took the opportunity to try it out on two new projects.
In addition to NERP, Redwood bundles Prisma and GraphQL with the ability to generate data migrations and generate full stack CRUD (create, read, update, delete) scaffolding. Also, the documentation is sufficient enough that I could hand off a Redwood project to another engineer with confidence.
Given the complexity of all the supported libraries, it will be interesting to see how the Redwood maintainers are able to keep up with rapidly changing dependencies. In other words, there’s a yarn rw upgrade command, it will be fun to see how that works a year from now.
Some observations so far…
1/ It was simple enough to implement Google oAuth (via Firebase). Or, to implement old-fashioned sign-in with a username and password against my own database. What I haven’t figured out yet is how to combine the two (à la Passport) to offer both. I’d like to support both simple email authentication against my database and any oAuth provider. So far, I’ve just hooked up firebase authentication.
2/ While aware of GraphQL, I haven’t actually worked on a GraphQL project – so I’ve got a learning curve. It’s baked into Redwood’s “cells” (full stack data-aware scaffolding) and used to generate shared Typescript types. I hope that I become more comfortable with GraphQL and appreciate why it would be “best practice” to use it. Right now, it feels like an unnecessarily complicated add-on.
My first inclination was to go around GraphQL and just call my nifty new Redwood serverless functions. However, it wasn’t easy to support user authentication unless going through GraphQL.
3/ Lastly, the end-to-end experience isn’t complete unless you can continuously test and deploy (quickly and easily). It’s great to see Redwood generating and incorporating tests (and even Storybook) for both client and server. My first inclination was to deploy to AWS using the included Serverless support. Unfortunately, I ran into a packaging problem and balked at having to do my own RDS setup for Postgres.
Of the other supported hosting providers, only Render included Postgres hosting. Getting set up on Render was quick and easy. The only hitch was a free Render instance isn’t beefy enough to run Redwood. You have to pay for at least 1GB of memory out of the gate to be able to build your project. To be fair, the same is true with my usual NERP setup on Heroku.
The reason I need a powerful full-stack platform like Redwood (that is easy to set up) is that I create a lot of prototype SAAS projects. I hand off the successful ones to other engineering teams, so using common and well-documented technologies is important. For the last few years, we’ve used our own propriety boilerplate project to get started.
I’m optimistic that if Redwood continues to work well, we can replace that boilerplate with a manual Redwood setup script. To that end, I’ve included the script I followed for my first two Redwood projects below. Please leave me a comment and let me know your impressions below.