Forem: Paul McBride

My SaaS Tech Stack

Paul McBride — Mon, 29 Jun 2020 17:09:58 +0000

Building software involves a lot of compromise. Everything has pros and cons. In this article I’d like to share what I used to build WeCode NI and weCode Remote. Both job boards are essentially the same and use very similar tech.

Hosting

When picking a hosting provider, I have a few requirements. Basically I want it to be affordable and convenient. I do not want to be managing a server or worrying about uptime. For most of the work I do these days, a serverless solution works best.

That's why for hosting, I use Vercel. Vercel is a serverless hosting platform with a generous free tier. I can push my code to Github and a few minutes later, it’s live. My pull requests get deployed to staging urls for me to test and I can have multiple environments each with different configurations.
The whole platform is backed by a smart CDN which helps static sites perform even better and ensures that my sites are always snappy and reliable.

Framework

When building a job board, server rendered HTML is very important for SEO. It puts you in control of how search engines see your pages.

My framework of choice is Next.js. Next.js is a fullstack JavaScript framework from the same folks that make Vercel. It can be used to build dynamic sites, static sites, APIs and projects that mix them all together.

One of the reasons I use Next.js is for its static regeneration feature. I can create a static page at build time but ensure it is always up-to-date by rebuilding in the background. Next.js makes this really easy to do. Check out the homepage or any job page on weCode Remote or WeCode NI to see it in action.

I use the Next.js API routes to power a GraphQL endpoint. This endpoint is what powers the admin interface and is consumed by all the job pages too.

Data

Firebase is where all of my data lives. I use Firestore via the Firebase Admin SDK. I don’t use Firestore in the traditional way from the front end, it’s all handled from the server. Firebase has been a really great choice for the database as it’s quick and cheap to get started.

Authentication

When picking an auth provider I wanted a turnkey solution. There are a lot of moving parts, from account creation to password resets.

As I am already using Firebase for my data and meets all my requirements, it handles my auth too. It is a really great tool that supports social login from the likes of Google, Apple or Twitter and requires very little code to get started. I have intentionally not provided a login method that requires a password as that would be more for me to maintain. Instead, users can log in with a social provider, or by using their email to get a magic login link.

Payments

You’ll not be surprised to hear that my payments are handled by Stripe. I use Stripe Checkout. This is a prebuilt UI for taking card payments. When a user is ready to pay, I redirect them to a checkout page on Stripe where the transaction is handled. This way, a user never enters payment details on my site. Ensuring a website meets the legal requirements to process payments is hard, so I’ve left that liability in Stripe’s capable hands. When Stripe successfully charges the user, they send me a webhook and the user’s draft job goes live.

Regrets

While I love all the tools I’ve used for building weCode Remote and WeCode NI, there are some things that aren’t perfect. For me, the biggest pain point when working on these projects always come from Firebase. The client side auth library is 54kB gzipped, which is a lot of code for the relatively few users who need it. If I was to start over, I’d probably use Auth0.

Firestore is the other part of this tech stack that I would swap out of starting over. It is a noSQL type database which charges you per document read. This means pulling together reports based on the data can be expensive. It’s also difficult to export data from Firestore. I would like to move to a Postgres database sitting behind Prisma. I’d looked into this when I was first getting started, but Prisma was still in beta and the API was changing too regularly.

What do you think? What tools would you use to build a job board like this?

A Short Horror Story

Paul McBride — Wed, 05 Jun 2019 16:54:25 +0000

Everyone that works in tech has a horror story or two. Making mistakes and doing stupid things is all part of being human. With that in mind, let me tell you about something dumb I did recently!

On Monday, when I got into work, I took my laptop out of my backpack, placed it on my desk and at the same time, opened the lid and plugged in an external display. This is where things started to go wrong.

When I plug a display into my laptop, both screens go blank for a few seconds. This is perfectly normal as the laptop tries to work out the best resolution to display everything at.

Now, on Monday, I had a busy morning planned so to save a tiny bit of time, while the screens were still blank, I typed in my password and hit return. Unfortunately, while the screens were blank, my laptop had detected that I was wearing my Apple Watch, automatically unlocked and re-opened Slack.

I had just typed my password into Slack and sent it into a channel with of 2000 members.

Yikes!

Do you any short horror stories like this? I'd love to hear them!

Don't Trust the Cascade - Why I write CSS in JavaScript

Paul McBride — Sat, 01 Jun 2019 17:08:01 +0000

If you've been on the internet recently, you've probably heard of CSS-in-JS.

The technology has been growing in popularity recently but not everyone is a fan. Today, I'd like to demystify what it is and why I think you should be using it.

CSS-in-JS can mean a few things, but primarily it is used to describe the technique of authoring styling logic in JavaScript. This can be done in the form of inline styles attached to a react component or by leveraging a tool like Styled Components.

Now, if you're anything like me, when you first heard the term CSS-in-JS you probably thought:

Oh no... not another thing I have to learn!

I have good news though if you already know CSS, you don't really have to learn anything new. But wait, if you already know CSS, then why bother writing CSS-in-JS, doesn't that just add complexity?

Why I Write CSS-in-JS 🎨

CSS stands for Cascading Style Sheets. Back when CSS was created, we were building websites which were typically pretty simple by today's standards. At the time, the cascading part of CSS was super useful. Today, however, I think it ends up being a foot-gun more often that it is helpful. Think about it, can you remember every class name you used on your last project?

Now imagine working on a project with several other people. Writing CSS that conflicts with or overwrites someone else's styles is essentially inevitable. Techniques like BEM and SMCSS can help but you have to rely on all developers following the rules and as a project grows so do the chances that someone will slip up.

For me, CSS-in-JS and Styled Components in particular help save me from myself. I'm protected from my own mistakes by an API instead of by convention. CSS-in-JS allows me to focus on styling my UI without having to be mindful of overwriting CSS somewhere else.

The cascade can still be useful, however. With Styled Components, you can still take advantage of the cascade but it is limited to the scope of the component you're working on. You can have your cake and eat it.

Performance 🚀

Okay, let's say you never make mistakes. Are there any benefits to CSS-in-JS besides controlling the cascade. As it turns out, there are. CSS-in-JS libraries are responsible for how styles are injected into the DOM. They can track which components are rendered and only inject the styles required.

This means the user ends up downloading fewer bytes of code and will have a quicker time to first paint. Great success.

Maintenance 🔧

Have you ever wanted to remove some CSS from a project but you had no way to be sure it wasn't being used somewhere. With CSS-in-JS, this usually isn't a problem as styles are typically co-located with the component that relies on them. You'll never have to go hunting for the CSS that is affecting the component your working on again.

Dynamic Styles

Another benefit of using CSS-in-JS is that you can take advantage of the power of JavaScript. You can use functions to create mixins and reusable style modules, props can be used to create variations of components and variables can be used for theming.

Most CSS-in-JS tools give you all the benefits of traditional CSS preprocessors too, including nested rules and auto-vendor prefixing.

What are the disadvantages of CSS-in-JS

All tech choices involve some sort of compromise and using CSS-in-JS is no different. The primary drawback of using something like Styled Components is the added complexity. First of all, it needs to be installed from npm. Not a big deal, but it is one extra step.

If you are sever rendering your code, you're going to need to install and configure a babel plugin to make sure your styles work on the first load too.

The other drawback of CSS-in-JS is that it just might not work for your particular application. If you're not using a front end framework like React or Vue, CSS-in-JS is probably not the right choice.

If you're in a situation where CSS-in-JS isn't a great fit, I highly recommend you check out Tailwind CSS. It is a utility first CSS framework that helps you build UI's rapidly. You don't get any of the benefits of CSS-in-JS but it may help you avoid some of the pitfalls of CSS.

Closing thoughts

As developers, our job is to solve problems using code. CSS-in-JS is a tool that helps us solve problems more efficiently and write code that should be easier to maintain.

If you've tried a CSS-in-JS solution and it didn't work out, that's cool too. Do what works best for you and your team.

Let me know if you have used CSS-in-JS and what problems it solved/caused for you!