This is a weekly newsletter on the Software as a Service world. Learning, building, and shipping. Written by Ethan Mick.
It's Labor Day weekend in the United States, the unofficial end of summer. I hope you all had a fantastic summer and are looking forward to the end of the year. Let's get it!
The Best Bits
- Vercel's Platform Demo Kit for multi-tenant Next.js projects.
- Learn more about SEO's interaction with core web vitals.
- A fun tale on why I highly recommend SaaS development over mobile app development.
- Minimal snippets for modern CSS layouts and components.
Security vs. Usability
This is, of course, one of those topics that is incredibly nuanced. And for almost any service, there will be tradeoffs that need to be thought through and the best path implemented. And once you've implemented it, measure the impact and adjust as needed.
There's often no shortcut.
Session length is just one of these debates. Banks tend to have very short sessions. GitHub has kept me logged in literally forever. Which one is more secure?
Personally, I lean toward convenience on this one (infinite sessions!) because the services I build myself don't have a lot of valuable information. Needing to log in frequently causes friction that doesn't help early-stage products that are still finding product market fit. For more enterprise customers, they'll often opt for shorter sessions.
Another good example of this debate is a password reset feature. When a user inputs their email, and that email does not exist, you can either:
- Inform the user this email does not exist. This often means the user mistyped their email or they used a different email, and they are happy to understand why they are not getting a password reset email.
- Informing the user if their email exists or not is leaking information about which emails are in your database, so you always return a success message no matter what. More secure but a worse experience.
This is one of those small things that I enjoy seeing how different services handle. I've generally seen most services do option 2, but lately, I've seen more services do it the first way. Other protections put in place, such as rate limiting, can decrease the attacker's ability to abuse the feature.
It's always a tradeoff, though.
What side do you fall on?
I've been... hacking on a side project lately. It's an online multiplayer implementation of Dominion. Yes, yes, I know, you can already play online. The point isn't to play; the point is to learn how to create a game server implementation that handles asynchronous client input.
Anyways, the server is a Socket.io web socket server, and the frontend is pure React. This is one of those moments in life where Next.js is just really bad and would not be a good option.
Of course, now that I'm outside the Next.js world, I need to rely on... other tooling. So I have
nodemon set it to hot restart the server and Vite for the frontend tooling. It's fine. The Nodemon setup was a little tricky since it has a different TypeScript configuration than the client. So when you're doing this, here's what you can do.
This is read by default, so your dev command can just be
nodemon. And then, to configure a backend server with TypeScript, your
tsconfig.server.json file should have the following:
That configuration is set up for a regular Node.js project! Now you can run your own server without interfering with Vite.
- YouTube Subscribers: 3,299 (+281 in the last 7 days)
- Newsletter Members: 589 (+31 in the last 7 days)
I need to figure out my YouTube schedule. Also, I should be starting a new freelance project soon (Hurray!) that will take up quite a bit of my time. Sooo, I really need to do some time management and ensure I have my priorities figured out.
That will probably mean less streaming, so I can break up the content process a little more. There are plenty of videos to be made, so no worries there. I just need to tighten up my process for making them.