This article is somewhat of a memoir where I share my experience getting dynamic routing to work with Firebase. To understand what’s going on, you should be familiar with their Hosting and Functions products. I’ve condensed all the essential technical stuff into the mini tutorial. Feel free to skip this section if you’re willing to read the whole article.

tl;dr Mini Tutorial

Firebase Hosting serves static files from your custom domain. Firebase Functions are executed by calling them via ugly cloudfunctions.net URLs. As of Google IO 2017, they now play nicely together. In your firebase.json’s hosting configuration, you can rewrite any specific route on your custom domain to call a function instead of serve a static page. Check out the docs.

To simulate dynamic routes like example.com/posts/123, I did the following: Create a function called post. Set up firebase.json to have all requests for /posts/** call the post function. The function fetches data and returns pre-rendered HTML containing all the proper social and SEO meta tags for the requested post, to make crawlers happy and support unfurling.

The page also includes a JavaScript window.location redirect snippet, so a real user is redirected to example.com/?post=123. This static index page reads the query parameter, displays the correct screen with the post content, and leverages HTML5’s replaceState() to put example.com/posts/123 back into the browser’s address bar. Serverless dynamic routing for all!

❤ Firebase

Firebase has single-handedly reignited my relationship with web development. Instead of building a frontend and backend for every project, I now only ever have to worry about the frontend. As broad as Firebase’s offering is, it still lacks many sought after features (like search, complex database querying, insight into usage, etc). But I’m so invested at this point that I’d rather jump through a couple hoops to make something work with Firebase than go back to setting up a foundational backend myself as if we were still living in a pre-Parse era. (Yes, us developers are lazy.)

A couple weeks ago I was working on a Product Hunt clone that had a pretty simple requirement: dynamic routing. Each post needed its own URL to share around the web, like example.com/posts/123. These links had to return pre-rendered social and SEO meta tags to support unfurling.

Up until this point I had everything happily hosted on Firebase as a notorious single page app, connecting directly to the database from the client. But with this new pre-rendering requirement, which was not yet supported by Firebase, it looked as though I’d have to point our domain to a custom VPS and host the site myself.

So I spent a weekend learning about Dokku (a great option BTW), getting our site up and running, doing some load testing, watching the site crash, scouring the internet to try and figure out why, convincing myself the app had memory leaks, then realizing I just needed a machine with more memory, bla bla bla all the while wishing I could just get back to building features and stop dealing with this dev ops nonsense.

A couple days later, someone in the Firebase Slack group posted a Google IO livestream. I tuned in just for fun and right there, the exact feature was announced that I needed: Hosting + Functions! With this new integration developers can run some backend code behind a custom domain before sending HTTP responses to the client. Within a couple hours I had dynamic routing working in production and could put Dokku back on the shelf.

Hosting + Functions

Firebase Hosting now has a new configuration option. In firebase.json, where you specify all your hosting behavior like caching, rewrites, redirects, etc, you can rewrite any path to point to a function instead of a static file. Here’s an example:

// firebase.json

{
  "hosting": {
    "public": "public",
    "rewrites": [
      { "source": "/posts/**", "function": "post" }
    ]
  }
}

With this config, any requests to example.com/posts/postidorhashorwhatever will ignore whatever static files you might have hosted there and call your post function instead. The function is called with Express Request and Response objects through which you can send an arbitrary HTTP response.

This lets us perform any logic we want before returning to the client! (As long as it runs within Firebase’s cloud function Node environment…) Great, you might think: We can return anything, but how do we return an entire page of our website showing the proper post content, when the website is built to be served as static pages?

The truth is, I don’t know. Maybe some day the Webpack gurus will create super fancy plugins that separate dynamic routes into functions with their own deployment configurations. Who knows what they’ll come up with next. Meanwhile, I’ve got a hacky solution that isn’t too complex and achieves the same result.

Redirects

Because our function can return anything, it’s pretty easy to have it return valid HTML with whatever content-specific social and SEO meta tags we need. This is the only part of our page that really needs to be pre-rendered to support unfurling. And if we can make it return an HTML string, we can certainly include a snippet of JavaScript in there to help get the rest of the page displayed asynchronously.

Here’s a shortened version of what my post function looks like:

As you can see, the HTML response to be sent includes '<script>window.location="https://example.com/?post=' + post.id + '";</script>'. A crawler just looking for your meta tags will be happy to receive them and won’t bother to execute this script. But a real user who loads this page in a browser will be immediately redirected to example.com/?post=123.

Now what exactly happens on example.com/?post=123 is out of the scope of this article, because it completely depends on the frontend framework you’re using. You just want to show the post content without redirecting the browser back to /posts/123. (My website was built with Vue.js, so in my index page’s beforeMount() function I check this.$route.query.post. If it exists, I show the requested post within the index page, without touching the route.) The important thing to know is that you can manipulate what’s displayed in the browser’s address bar to look nice again. To replace the ugly ?post=123 with /posts/123, you can call window.history.replaceState({}, ‘Title’, ‘/posts/’ + postId);.

Voila! Unless the user paid attention compulsively to their address bar, all they know is that they clicked on a link and ended up on the proper page of our website.

Honestly, as a design freak, this double-redirection does irk me a bit. It’s not sparkling clean. But it only ever happens to users who navigate to our site via a standalone link like example.com/posts/123 from another source. The jarring experience of jumping from the referring website to our site overshadows the quick redirects happening in the background.

And you know what’s dirtier than a little redirect hack? Spinning up a new virtual machine, installing Ubuntu, adding your SSH keys, creating a new sudo user, sudo apt-get update, etc etc you get the picture…

Firebase FTW.

Made it to the end and learned something? Leave some love 💚

Peter LoBue is a freelance UX designer, web developer and iOS developer living between Philadelphia and San Francisco. Reach out for availability: @pejalo

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!

Firebase to the Rescue: Dynamic Routing via Hosting + Functions Integration was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Beginner’s Guide to Web Development: Supercharge your Productivity with a Bundler

Back in the simpler days of web development, you would create an .html file in any text editor and open it in your browser to see it formatted nicely. To make changes, you’d update the file and refresh the browser. That was it. Contrast that with the following popular rant:

How it feels to learn JavaScript in 2016

Thousands of web development helper tools are improved upon every day. If used properly, incorporating them into your development environment will make you infinitely more productive. But unfortunately, using all these tools means that proportionally more time is spent managing and configuring them than writing code.

Enter: The Bundler.

A bundler helps web developers manage a group of tools that solve related problems. You can think of it as a “meta-tool,” where each sub-tool is managed by a plugin. Although bundlers can be used to do all kinds of fancy stuff, we will focus on three sets of problems here that apply to any web development project:

• Transpiling higher-level languages into HTML, CSS and JavaScript
• Serving files on an ad-hoc HTTP server with live-reloading
• Preparing the application for production: minify, concatenate, uglify

Transpiling languages into HTML, CSS and JavaScript

The Problem

Web browsers can natively only interpret three languages that work together to form what we know as a “web site” or “web application.”

• HTML is primarily used to structure content.
• CSS defines how that content is styled.
• JavaScript allows us to dynamically change content and styling, based on user interactions and other events.

These languages are defined by standards created by various non-profit technology organizations (W3C and ECMA). Naturally, the standards themselves evolve faster than stable and secure browsers can support them. But us developers want to write code in the new standards, because they make us more productive.

Additionally, developers have invented more succinct/easier/readable languages on top of these three basic ones that are preferable to code in. Here are a couple examples with sample code snippets for comparison:

• HTML: Pug, Haml

<!-- HTML -->
<div class="mycontainer">
  ...
</div>

// Pug
div.mycontainer
  ...

// Haml
%div.mycontainer
  ...

• CSS: Sass, Less

/* CSS */
div.mycontainer {
  background-color: gray;
}

// Sass
div.mycontainer
  background-color: gray

• JavaScript: ES6 aka ECMAScript 2015, TypeScript, CoffeeScript

// JavaScript
var addOne = function(a) {
  return a + 1;
}

// TypeScript
let addOne = (a) => a + 1;

The examples shown here may look trivial, but each language really does offer some substantial improvements over their basic counterparts.

If you are still writing plain HTML, CSS, or vanilla ES5 JavaScript, it’s time to power up your dev game!

So how can we use these new languages and standards, without direct browser support?

The Solution: Transpiling

Our development environment needs to transpile the languages into the three understood by browsers: HTML, CSS and JS. This should happen quickly and unobtrusively (without any extra steps, after we get everything set up) so we can make changes to our application and see the results instantly. Bundlers can be set up to do this for us automatically, so we can code in whatever languages we please.

Serving files on an ad-hoc HTTP server with live-reloading

Problems

• When you create an .html file on your computer, you can simply double-click it to open it in your browser. It even loads images, .css and .js files. However, the browser reads files directly from your hard drive via the file: protocol. This has some restrictions and differences to the http: protocol, which your application will be served over once it’s hosted on the web. For example, files hosted with file: cannot perform AJAX requests, and the relative file paths referenced in your .html files are handled differently.
• If you’ve ever made an HTML page before, you know how annoying it is to view the changes that you make. You must save your file, switch to the browser, and reload the page. Switching back and forth between windows and pressing “reload” (or cmd + r) becomes tedious very quickly. It would be a huge help to have the browser reload itself automatically when changes are saved to our source files.
• Sometimes we would like to see our changes in the browser without reloading the entire page. Consider a scenario where loading the page involves downloading and displaying data. When we are editing CSS and want to view a simple change, reloading the entire page every time is overkill. Wouldn’t it be nice if any change to our CSS (or Sass or Less) files would cause the browser to instantly re-render the page with the new styles instead of completely reloading it?
• Consider another scenario: We have a web application that relies upon various JavaScript modules. Not every screen needs every module, so only modules needed by a screen are loaded when that screen is loaded. For example, the “settings” screen might require a “settings” JavaScript module. As we make changes to the settings module, we don’t want to reload the page every time, because that would require us to navigate to the settings screen again to see the result of our changes. Wouldn’t it be nice if, upon saving the settings module, only that specific module could be reloaded under the hood, so we could test it instantly?

The Solution: HTTP Server

Running a simple HTTP server on our own local machine allows us to access our files via the http: protocol, mimicking the environment that the files will be hosted in when the site is published. Popular bundlers include an HTTP server plugin.

When set up properly, the bundler can watch your source files for changes. When you save a file in your editor, the bundler can tell your browser to either reload the entire page, re-render the page, or reload the specific JavaScript module.

When editing a file written in a higher-level language like Sass or TypeScript, the code must be transpiled into CSS or JavaScript before the browser is told to refresh. A properly configured bundler ensures that its plugins are executed in the right order.

Preparing the Application for Production

The Problem

While we are developing, even though we are writing our code in fancy languages that get transpiled into HTML/CSS/JS, we want those resulting files to look as close as possible to our original source files for debugging purposes. So when you get an error in your browser’s developer console like this one:

…you can click on test.html to see what code caused the error, or easily find the relevant line of code in your text editor.

However, when publishing your code, you typically don’t care about debugging it. (It should work perfectly, right?) Instead, priorities lie in maximizing performance, minimizing bandwidth and possibly purposefully obscuring your code. These are achieved via three processes: Minify, concatenate, and uglify.

• Minify — When we write code, we use lots of spaces or tabs and relatively long, comprehensive variable/function names to keep things clean and easy to understand. The extra characters needed for this nice formatting are completely unnecessary when interpreted by the browser. So to keep our file sizes down, we want to automatically remove whitespace, and replace JavaScript variable and function names with the shortest ones possible.
• Concatenate — Again, to help structure our code, we often split it into as many files and folders as we want. This allows us to stay sane with complicated projects. But when serving all this data in a production environment, it’s faster for the browser to download and parse a few large files than many separate smaller ones. Many developers prefer their web applications to consist of three files: one index.html, one .css file and one .js file. So we need a process that will combine lots of code from related file-types into a few files.
• Uglify — When writing code in compiled programming languages like C++ and Swift, you typically publish your application in compiled machine code instead of source code. Machine code cannot be read by humans, and is difficult to reverse-compile back into the source. This deters competitors and hackers from misusing your application. Conversely, HTML is a markup language, CSS is a stylesheet, and JavaScript is an interpreted scripting language. That means that the code you write is the same code sent to your users’/customers’ browser, which can be easily read and copied by humans. To combat this, many developers “uglify” their code before publishing it. This deforms the code to make it harder to decipher, for example by renaming variables and functions to be relatively incomprehensible.

Setting up each of these processes to run in the proper order and for the right situation is no small feat.

The Solution: Bundling!

Again, bundlers can do all of this for us. They allow us to set up various series of tasks for different purposes, like developing, testing, and production. Each series can be configured and tweaked to your heart’s desire.

When active, whenever a change to a source file is detected, the bundler can re-process and bundle your app appropriately.

Conclusion

Bundlers can solve an infinite number of problems, but the ones mentioned here are useful for any serious web developer.

Popular Bundlers

The most common bundlers for web development today are webpack and Grunt. They each have their own configuration syntax that, while very powerful, come with a steep learning curve. Gulp is another popular choice that many developers find easier to understand. And Brunch is yet another contender that strives to need even less configuration to set up.

New kid on the block: FuseBox

FuseBox is an open-source bundler project started in October 2016. It attempts to solve all problems mentioned here out-of-the-box, and more, with less configuration than any existing bundler tools.

Version 2.0 was released in May 2017. The following in-depth tutorial will walk you through how to set up FuseBox to handle all the issues mentioned above. Spoiler alert: It’s pretty easy. Try it out!

Introduction to FuseBox - a Faster, Simpler Webpack Alternative - SitePoint

Made it to the end and learned something? Leave some love 💚

Peter LoBue is a freelance UX designer, web developer and iOS developer living between Philadelphia and San Francisco. Reach out for availability: @pejalo

Beginner Web Developers: Supercharge your Productivity with a Bundler was originally published in fusebox on Medium, where people are continuing the conversation by highlighting and responding to this story.