Learning Two Frameworks by Bridging Them Together (Redwood + Clerk)

Edit: Sadly, after enjoying learning and contributing to Redwood, I learned about the Not Great circumstances around the framework's author's departure from Github. Because of that, I've stepped away from the framework.

There are many snarky truisms about full-stack development in the Node+js ecosystem, but headline number one has to be that every week there is some new framework you "just have to" learn.

Recently, that feeling has been creeping up on me again. I've felt like I should dive deeper into one of the competitors from my investigations into who will be the "Rails of React." I picked RedwoodJS, since Prisma had featured them so heavily in the last Prisma Day. At the same time, this month's Hashnode Hackathon means I have a strong incentive to learn Clerk, a new player in the auth-as-service landscape.

Luckily, there's an old trick I know for learning two frameworks at once: just duck-tape them together into one project. It might take you a bit longer than if you'd tried to learn just one or the other, but you it will take less than doing two projects back to back. A week later, my plan hit a few snags and I have no side project to show for it, but I did learn a lot about the ins and outs of both Redwood and Clerk and I gathered a little more open source clout along the way.

Operation Duck-Tape

First, an unrelated fun fact: duck tape wasn't misnomered "duct tape" until 50 years after it was invented.

So, the plan here was initially to learn RedwoodJS and Clerk at the same time by building a quick side project in a weekend. I figured this would be as easy as spinning up a Redwood project and then following Clerk's instructions for how to integrate their SDK into NextJS (since that's what Redwood uses under the hood). I hadn't counted on how fully-featured I would find Redwood to be, though, which turned out to be a blessing and a curse for this project.

You see, Redwood comes with its own auth system built in. The framework's whole purpose is, after all, to reduce the boilerplate that you have to write to get your app finished. Auth is a huge part of most apps but also the most dangerous thing a developer can try to "do themselves." You should do anything you can do to steer clear of writing your own auth system!

On the one hand, Redwood already having an auth layer was great! It meant that I could get set up with a simple yarn rw setup auth <provider> command. On the other hand, this was a huge wrench in my plans to learn Clerk because Redwood hadn't yet integrated Clerk.

Diving Deeper into the Open Source Sea

If I wanted Clerk and Redwood to really work together, I was going to need to figure out how other providers, like Firebase and Auth0, had become integrated with Redwood.

Luckily for me, Redwood is completely open source. So, I forked their repository and started digging in. I often find this is the best way to get features or fixes I want to see included in open source projects - especially the larger and more professional ones. Maintainers are bombarded by issues and complaints, but if you take the time to find a possible solution and make a PR with it I find most of them will take the time to help standardize and incorporate your work into the project.

Indeed, I was blown away by how welcoming the Redwood maintainers were. While working through their tutorial, I ran into tiny bug and one of the maintainers helped me take that bug from a new issue, to my first PR to their project, to being released on npm, all in under a week! That kind of assistance and quick turn-around really built my confidence that I would be able to create the Clerk integration for Redwood myself.

I started by searching the codebase for "auth0", absorbing the flow that the framework used for that integration. I then modeled the Clerk integration on that. Indeed, the hardest part of the process was figuring out how to run the raw source locally to test it. But in the end a PR resulted and, after a few touch-up comments, has now been merged into the codebase. So, Clerk should be supported in the next version of Redwood - 0.36.0.

What I Learned

More valuable than that sweet green squares on my Github grid, though, was the fact that this process completed my original goal: by the time my PR was merged I had a much better understanding of how both Redwood and Clerk worked inside and out. I also had some concrete lessons and takeaways that will help me work faster next time I try to tackle a project built on either of these tools:

• Don't try to fight Redwood. Redwood is very openly an opinionated framework - this was, indeed, one of the things I have dinged them for in the past. It applies here too - because of Redwood's strictness, it was honestly easier to add Clerk support at the framework level than it would have been to shoehorn it in at the application level.

• Clerk is different. It was all to easy to assume coming in that Clerk was going to be "yet another Auth0 clone." But I was pleasantly surprised by the new features Clerk brought to the table, even if they had some technical tradeoffs. For example, Clerk bucks the "one token controls everything" trend shared by Auth0 and others. Instead, Clerk uses two different tokens (both confusingly named "session") so that it can support multi-account sessions - the same feature that lets you be logged in to multiple Gmail accounts at once and pick which one to act as at any moment.

• Redwood generators are your friend. Once I got my basic outline for the integration in Redwood, I started trying to make a test-project for it. Going through this process really drove home how much Redwood (and its competitors) have simplified the process of making a rich React app. Being able to type yarn rw g page user-profile and have the framework handle the boilerplate templates and wiring helped me stay in a programming flow state. No more was I interrupted by the harsh vibe of having to cmd+c cmd+v the same lines of code for the 100th time!

• Clerk was suspiciously easy to use. Compared to its monstrously complicated competitors like Auth0 and Cognito, Clerk's blend of power, ease, and beauty is almost suspicious. Overall I think this is still a point in its favor - I had a beautiful and capable auth system set up in under 15 minutes. I don't think I could replicate that on Auth0 given an entire day. But, when things are this easy it leaves me suspicious of the trade-offs and limitations I am missing. Before I use Clerk in a situation where it would be guarding truly valuable data I would want to threat-model it a little to make sure I truly trust that auth can be both easy and secure.