Building with Supabase

For the last decade of my software career, I’ve focused a lot on frontend build, design, and user experience. This last year I’ve started building a full application for my wife’s business. When choosing the technology to use, I started weighing familiar tech with the long term goals of the project.

In the beginning, I wasn’t sure if this project would become a viable SAAS we would try to monetize or if it would just become another portfolio piece for me. As I started building it out, it became clear that our customers would be very interested in this type of product and a worthy endeavor so I needed to chose something with rigor and the potential to scale.

Background

In order to understand the project, I need to provide some context to my wife’s business. She has been a writing coach for the last couple of years and recently started hosting live courses and a community membership product. Along with these courses, she gives her customers a writing tracker in the form of an excel sheet. This tracker has had a great response and we quickly realized it could easily be a web application.

Next.js

I’ve had the pleasure of working on both greenfield and large Next.js projects throughout my career thus far. While it’s not the only option when starting a new project (there are plenty of frontend frameworks at the time of this writing), Next.js would be a great choice for a few different reasons:

1. Talent pool

So if you’re at all familiar with building for the web right now, you’ve heard of React. Personally, It’s been my bread and butter for the last seven years. By choosing Next.js, I’ve opening up the possibility of a larger talent pool, if and when we need additional developers. Developers with React experience can quickly and easily understand Next.js and it’s opinionated patterns and api.

1. tRPC

This is the second project I’ve chosen to use tRpc and I love it. The dev experience is so nice by creating a type-safe function definitions between server and client. When used alongside Next.js, you can easily jump between server and client without losing context which greatly improves the cognitive overhead. Plus it uses react-query under the hood, which will manage stateful cache by only firing server requests if the specific data is stale. Plus the nice things such as built in loading and error states and more control with query dependencies (only fetching one piece of state if a dependent state is not stale).

Supabase

A newer product to the javascript party, Supabase has an impressive list of features and already gaining a good reputation. While being a Firebase alternative, there is similarly a degree of vendor lock. Though I consider the trade-offs to be justified for the scale of this project. For one, it’s built on postgress, a feature rich and open source database option, which is widely accepted and utilized. Secondly, Supabase’s documentation is thorough and well written, which has made the adoptions process very smooth. Thirdly, there is a built in user management, making it easy to jump start authentication and user profiles. The migration tools and cli are quite lovely to work with as well.

Shadcn/ui and Tailwind

Shadcn has seen a massive amount of adoption this last year. I starting building a previous side project with Radix then heard about shadcn and how it’s built on top of radix but does not require you to download any npm packages (other than tailwind) but uses a command line tool to essentially copy the code for UI components directly into a specified directory. Utilizing shadcn along with the powerful and intuitive class utility modal of Tailwind, I’ve been able to quickly and reliably build a beautiful UI.

Vitest

During my time at a large company, the long javascript test run times had become an unacceptable bottleneck in the CI pipeline. With this in mind, I wanted to choose a test runner for this project that has a reputation of speed and a similar api to Jest. Now, I understand that some test performance is ultimately up to how the test code is written, but the natural evolution of technology [something something supporting the adoption because it’s faster] I found the process of integrating this test runner quite easy and the similar api makes writing tests very familiar.

Cloudflare

My decision on Cloudflare for hosting is somewhat of a gamble. I had recently read a blog on the benefits of their R2 product, which is an S2 competitor, and how much more cost effective it is for data storage. While this project isn’t hosted on S2 (due to the need for edge functions), so far I have found working with it easy and intuitive.

Conclusion

Starting new projects has become a common past time for me. Maybe it’s my agency background or just pure curiosity but I do like trying the new stuff. Of course there is a place for using plain vanilla javascript, but in my experience of working on many very large codebases, you need to have a scaling strategy or your javascript becomes unwieldy (typescript can help with this but that is for another day). I’m currently on the fence to whether I will give my all to this project or not. Oh, and here’s the github repo: https://github.com/jonwalz/toolkit