Dev diary: Getting comfortable with changing directions

Why I decided to abandon my original vision to create a better product

I alluded to this in my introductory blog, but one of the biggest decisions I made early into this project was completely abandoning a few weeks of work to rebuild the CMS using Next.js.

The reason I did this was to create a better, faster and more secure product. But even if the benefits were there it was still a challenging decision to make because it forced me out of my comfort zone and brought me back to step one.

So, for the first developer diary on this project, I figured it would be a good idea to jump into that decision and explain how I overcame those challenges.

The issues with client-side React

This project originally started as a Vite app. Vite was my starting point because it's a fairly vanilla take on React, and I was able to get the basic features implemented fairly easily. There's also a lot of documentation that already exists for Vite and Supabase, so connecting the two was relatively straightforward.

It was also where my comfort was. When I started learning React many years ago, I learned within the context of JSX, Create React App and client-side interactions.

I started feeling the limitations of Vite early into my development. When I was building the editor pages I found that there was a lot of stuttering in the app. Items would load in after the initial page load, which caused things to move around and the UX felt really amateur.

But I pushed through because of the experience I had with client-side React for so long. Things feel like they move faster when they're familiar.

The biggest challenge I had was when I started to lock things down. My intention has always been to use Supabase for accessing my database and also use Supabase for authentication. I want to be able to build user experiences that change based on access permissions, but I want to back that up with Supabase's powerful Row Level Security policies.

Basically, I want the CMS to show specific items to the user based on who they are. On the flip side, however, if someone found a way to spoof their way into a space they weren't supposed to access, I want the database to be smart enough to see through that.

This started to fall apart when I started implementing my authentication. I was having a lot of inconsistencies around expectations and the reality of the product I was working with. Those stuttering moments that I noticed before were amplified as I tried to add in additional role-based access control (RBAC) logic.

I could have figured it out using the tools I was already building, but things started to get a bit too clunky and I didn't like the direction the project was going.

Moving to Next.js

Even though the journey felt daunting, it made sense for met to move to Next.js. Supabase's documentation gave me the confidence that moving to Next would solve a lot of the problems I was having because I could verify the user's identity before the page was finished loading.

This meant that there was an immediate end to the stuttering issue—because I could render all of the page elements on the server before the browser had finished loading—and also gave me a lot more control around access.

Next.js has a powerful middleware tool that enabled me to add in a number of checks to make sure the user was not only who they said they were, but also had the access I assumed they should have. By using middleware, I have been able to load the information about the user and cross reference their permissions across a number of databases and security checks before the page even loads for the user.

This gave me the confidence that I had found the right mix of security features to prevent the user from seeing things they were supposed to while simultaneously making sure the end-user experience was clean and concise.

Moving to Next.js also gave my codebase more "security" because I also opted to learn TypeScript and move everything to TypeScript. This provided even better benefits because I was able to make sure all of my code was packaged in a Type-safe format.

I no longer spend hours thinking about why something isn't working as intended, because TypeScript tells me that there's data mismatches before I finish saving my document.

But TypeScript is probably a story for another day!

Where do we go from here?

Now that my app is in Next and things are security, I'm feeling more confident in creating additional features. I was originally hesitant about adding regular reader user accounts because I wasn't super confident that I could provide a regular user with the right amount of security while also keeping my data safe.

Over the next few weeks I'm going to focus on adding more user types and documenting how those things are impacted by this initial decision to build in Next.js.

Until next time!