Aurelia Firebase Server-side Rendering Skeleton Template

Last updated: March 26, 2018

As many of you know, I love working with Aurelia and I love working with Firebase. I have been combining both of these together to create personal projects for a while now.

Newly introduced server-side rendering also strengthens my toolbelt with the ability to quickly spin up new Aurelia applications without having to worry about configuration and tooling.

This is why I have open sourced my Aurelia Firebase SSR Skeleton on Github. A starter for creating Aurelia applications, think of it as being similar to the skeleton applications Aurelia currently offers, but more up-to-date and easier to work with.

This starter is more verbose than what you might be used to, and it assumes some ways of working with Aurelia. Keep in mind that this skeleton is not for everyone, you might not want to use TypeScript or work with Firebase. If so, then this is not for you.

Features

  • Setup to work with TypeScript
  • Authentication (email/password and social auth sign in via Google) using Firebase
  • Firebase’ FireStore for the database
  • Setup for routing by default
  • Server-side rendering (including initial state passed from server to client)
  • Setup for state management using Aurelia Store

The skeleton also makes for a great example application showing you how to work with the great Aurelia Store plugin, especially with remote data from Firebase. And although this skeleton assumes a few things, it is based on the Aurelia CLI and easy to change to work with say a REST API or other use cases.

Why?

This is very much to scratch my own itch. I seem to only work with Firebase and Aurelia these days, so an application setup with some defaults out-of-the-box works well for me and even if only as a learning exercise, this skeleton should serve as a prime example of how to work with some cool technologies and build an Aurelia application.

If you are also curious about server-side rendering in Aurelia, then this is a great showcase setup which not only shows you how to get it working but also how to use the Aurelia Store plugin and pass initial state from the server through to the client.

Go forth.

Purchase Aurelia for Real World Applications over at Leanpub now

 

Dwayne

 

5 thoughts on “Aurelia Firebase Server-side Rendering Skeleton Template

  1. Thanks for putting this together!
    I started my Aurelia project (https://isopro.solutions) with the 1.1.2 skeleton-esnext-webpack skeleton. I’m trying to look at your starter kit to see what I’ll need to add so that I can get SSR working for my project. The first thing I would like to do is get your skeleton deployed to my firebase project that I created just for your skeleton. After deploying I get a 404 b/c it can’t find index.html which makes sense b/c in the .dist folder there is not index.html only an index.ssr.html. How do I get this deployed successfully to firebase?

    Thanks! –Steve

  2. I was able to get the app to run. I just needed to run au build –env prod, then run firebase deploy and I was good.

  3. Weren’t you supposed to use firebase function to render in the server? I’m a little confused. Is this skeleton working hosting in firebase host or firebase functions?
    Thanks in advance

  4. @Luis you are right. The skeleton does not provide solution of SSR on firebase hosting. Dwayne intended to use only two services from firebase: authentication and storage (Cloud firestore). Please correct me if I am wrong Dwayne.

    I have found a bug/design error in file: home.ts -> function: canActivate :
    – why do you add observer there and never dispose it? Each time the user navigates to this page new observer will be added.
    – why do you rely on the firebase listener. Shouldn’t the code work solely on store.state in this file?

  5. @Exsilium

    Correct. This skeleton does not provide SSR on Firebase Hosting. However, it is possible to do this using Cloud Functions and Firebase Hosting aliases pointing to a function rendering the app.

    >why do you add observer there and never dispose it? Each time the user navigates to this page new observer will be added.

    To my knowledge, Firebase will pick up on this listener having already been created. I’ve never disposed of a Firebase `onAuthStateChanged` event before nor seen anyone else do the same.

    >why do you rely on the firebase listener. Shouldn’t the code work solely on store.state in this file?

    It can work this way, but I listen for the Firebase listener in the view-model so I can redirect to the login screen if the user is not logged into the application.

    You can wire it up to automatically use the store to handle the auth state changing, but in this case, I did not.

Leave a Reply

Your email address will not be published. Required fields are marked *