Behind the technology choices 🧪

As you’ve probably heard, CRA and Firebase aren’t the only kids on the block. There’s an abundance of popular alternatives — so why not use them instead?

This question isn’t an easy one to answer. In truth, a lot of it comes down to personal preference. But given that you’re studying React and Firebase (and Bacon!) — in fact, especially because you’re in this course — it’s worth learning the story behind the why. You’re now going to be the local expert on this stack, and people will want to know!

#General Principles

Let’s start by crafting some general principles for picking technologies. These will come in handy once we start discussing how to solve individual requirements for the project.

#Get Quick Results

If you’re just starting out, then keeping motivated is just as important as writing code. In my experience, nothing keeps you motivated like actually seeing results. That’s why it’s important to start with something simple, and add more features through iteration.

#Do As Little As Possible

#Manage Risks

There’s no such thing as risk-free software development. No matter how popular the products and services that you depend on, you can never escape the possibility of them being discontinued, being deprecated in favor of a new version, or just plain old going out of fashion.

To illustrate this point, consider the story of Firebase itself. It used to have a solid competitor called Parse… which was bought up by Facebook and promptly shut down. Luckily, Google seems to be far more committed to Firebase — but it goes to show that the risk is always there.

But if using 3rd party products and services is so dangerous, why not just do everything yourself? The big reason is simple: reinventing wheels takes a lot of time. And that brings me to another risk: if development takes too long, it makes it that much harder to get traction at all!

Here’s the thing: you can’t avoid risks. By removing exposure to 3rd party software, you’re simultaneously increasing the risk of delays. That’s why it’s important to manage risks as opposed to avoiding them: it lets you optimize your stack for the best chance of success — as opposed to the lowest chance of failure.

#Technical Requirements

Now that we have some general principles for picking which technologies to use, let’s see if we can’t hammer out a few specifics.

#Compilation

#Bundling

One of the best things about JavaScript is its enormous ecosystem. In particular, npm provides a ginormous selection of packages that can make your life easier. There’s just one catch: they’re not designed to be loaded directly with <script> tags.

Lucky for you, it turns out that many of those packages can be made to work in the browser surprisingly well. The trick? You just combine the thousands of source files from node_modules into one or two JavaScript files that can be loaded by <script> tags. And while you could probably do this manually, there are bunch of wonderful tools that can do it all for you. Amongst React developers, Webpack is the clear winner in terms of community support, so let’s stick with that.

Requirement #2: Your source should be bundled with Webpack.

#Server(less)

Modern browsers have become ridiculously powerful. They can do basically everything, from displaying hyperlinks to running neural nets on your GPU that tell you whether your camera is pointing at a hotdog or not. But while browsers continue to expose more and more interesting APIs, there are still plenty of things that you’ll need to handle on the backend, including:

• Storing data and sharing it between users
• Authentication
• Securely communicating with APIs (for payment processing and sending emails)
• Actually serving the app’s source

So you’re going to need a backend. And given that you’re planning on makin' bacon, you’ll want to prioritize development speed over everything else — at least until you have customers telling you otherwise. Ideally, you’ll avoid needing to learn dev ops and an entirely new language in the process.

#Eventual SSR

Chances are, if you’re selling things, then you’ll want Google to index what you’re selling. And while Google does have limited support for indexing Single Page Apps, you’ll still need Server Side Rendering (SSR) if you want to add <meta> tags for control over how your pages appear on social networks. And this presents a bit of a problem.

Traditionally, SSR is ridiculously complicated. It requires vast changes to your client-side build configuration, it requires servers to run on, and it can completely change the design around your routing and state management.

Here’s the thing though: you probably don’t even need SSR at the start. And while you certainly don’t want to make any architectural decisions that’ll make SSR impossible, Create Universal React App makes SSR an easy enough upgrade that you can add down the track.

Requirement #4: It should be possible to add SSR… eventually.

#Backend Products

Okay, so now that we have some solid technical requirements and some principles to judge the contenders by, let’s take a look at a few options — starting with the 800 pound gorilla.

#AWS

AWS does everything you’d ever need on a backend — if you can figure out how to use it.

One way to think of AWS (and the other cloud providers) is that it gives you the parts you need to build your own platform. If you have the time and resources, then it lets you build the perfect backend for your app. But if you’re just starting out on a small team, it’s probably not the right choice.

One interesting factoid about AWS: it’s actually used under the hood in a number of other serverless offerings. So if you ever use products like ZEIT Now or Netlify Functions, then there’s a chance that you’ll be using AWS without realizing it.

#ZEIT Now

ZEIT has a pretty big following within the React community — thanks to their work on Next.js — but they also have a serverless product called “Now” that does two things pretty well:

• It’s lambdas can handle SSR, along with private communication with 3rd Party APIs.
• It’s CDN is first-class, and integrates with lambdas to allow caching of server-rendered pages.

If lambdas and a CDN are all you need, then ZEIT Now is basically perfect. For example, it’s a great choice if you’ve already got a working app and you just want cached server-rendering. If you’re just starting out though, then you’ll still need a way to store data and handle authentication.

#Netlify

Netlify runs a similar platform that provides almost everything that your backend needs:

• A CDN to host your app’s distributables
• Cloud functions built on AWS
• An authentication API built around JSON Web Tokens
• A storage service for large files

There’s still one piece of the puzzle missing though: Netlify doesn’t provide a database. This means you’d need to find another service to store data. Something like a hosted GraphQL service — or Firebase.

#Firebase

The key feature of Firebase is that it gives you a serverless database — and a pretty remarkable one at that. Unlike an old-style JSON API, Firebase allows you to subscribe to queries. It keeps the latest result synced up, even over many different devices. And you get access to all of this through a simple client-side library.

Of course, Firebase isn’t the only serverless database. There are alternatives like hosted GraphQL or Parse Server, but at least at the time of writing, nothing comes close to Firebase in terms of ease of getting started or integration between the different modules.

Okay, so Firebase will get you quick results with very little work. But let’s talk about risk.

Did you notice that link to Parse Server above? That’s the open source version of the same Parse that Facebook bought up and shut down. Which raises the question: could Firebase be shut down too? Given that it’s already owned by Google, I’d say it unlikely — but you never know. Of course, the same risk applies to any serverless product.

In the worst case, Firebase does provide tools to export your data and user information. But is the risk that you’ll need them worth it? Or to ask another question, which is the greater risk: running out of runway before you get enough customers? Or your backend being shut down once you have those customers?

Only you can answer these questions, but one thing’s for sure: there’s no faster, simpler way to set up a backend for your new bacon-makin' React app than with Firebase.

#Frontend Tools

Given that you’ve decided on Firebase for the backend, let’s take a look at the options on the Frontend.

#Gatsby

Gatsby is a framework for building websites and apps with React. It’s designed to make static rendering easy — which can be a great way to improve performance and SEO. But as a result, Gatsby makes a lot of decisions for you, including:

• It encourages you to access all data through a GraphQL layer — even if using Firebase.
• It requires you to use its own custom routing system.
• Configuring Webpack requires the use of a Gatsby-specific plugin system.

Basically, you’re no longer building a React app — you’re building a Gatsby site. This is great if you just want a static website, but if you’re planning on makin' bacon then it’s not the right fit.

#Next.js

Next.js is another framework for React — this time with a focus on server rendering (as opposed to static rendering). Like Gatsby, Next.js makes a lot of decisions for you:

• You must use the Next.js router.
• Links and dynamic imports must be done the Next.js way.
• To fetch data, you use custom lifecycle methods (not hooks!)

If you’ve used a framework like Rails before, then Next.js will feel familiar. It makes it super easy to throw together apps that fit a particular pattern, and as long as your app follows the rules to a tee, you’ll be fine. But what if you want to do something different?

That brings me to the main reason that I don’t recommend Next.js: there’s no escape hatch. It’s like Hotel California; you can never leave. And sure, if you have a huge team then you can always “fork Next.js and use as you like” — as one of the maintainers suggests. But at that point? It’d be easier to just roll your own.

#Rolling your own

If you create your own build system from scratch, then it goes without saying but… you can certainly meet any technical requirement. Another advantage is that you can omit a lot of the unnecessary features that are bundled into other options — that’s why it can be simpler to roll your own than to say… fork Next.js. Of course, there’s a catch: it’ll take quite some time before getting any results, and then you’ll be solely responsible for maintenance of the entire thing.

Often times you’ll have a specific feature that requires custom configuration, and you’ll have no choice but to roll your own build system. But even then, it can make a lot of sense to stick with Create React App until you’ve built everything except that specific requirement.

#Create React App

Here’s the stand-out feature of Create React App (CRA):

Now in an ideal world, you’d never actually need to use eject. Indeed, in many projects you never actually will. Here’s why:

• Support for babel-plugin-macros means that you can configure the compiler without writing config files.
• Under the hood, it’s just using Webpack, so you can use standard Webpack loader syntax if necessary.
• CRA holds no opinion on project structure; you can use whatever router and database you like.