Switching website’s deployment from Angular (static site) to Angular Universal

Recently put my Los Angeles catering company’s website through the switch from an Angular 5 app hosted as a static site to Angular Universal. Wasn’t as bad as I thought, but there definitely were a few things I learned along the way.

1. Any reference to window or document will break your app in the server, so wrap it in a if(isBrowser(…)) and keep it off the server. Turns out, there are some very nice wrappers in @angular/platform-browser that you can use to write some if in browser, work this way, if in server, work this other way: https://github.com/angular/universal#universal-gotchas
2. Long running Observable loops break (i.e., a carousel using Observable.interval) so also wrap them on the server. You can do a simple if(inBrowser) { return loop } else { return first_item }. Hard-coded JSON arrays also tend to break… you need to change these to Array.from(json_array_of_objects)
3. Takes a while to get your server working (part a — locally). Sounds obvious, but I was running the whole ssr build to troubleshoot and every time I ran yarn. a) for heroku, set postinstall to heroku-postbuild so it doesn’t run every time. b) take a look at the different commands to build the browser, server, and break them up to focus on the part that you’re working on to reduce build time
4. Takes a while to get your server working (part b -in the cloud).This will vary by hosting provider. I tried heroku due to familiarity with it, so these steps are Heroku specific: a) package.json: Make sure all your devDependencies that you need to run on the server are moved to dependencies. Get your scripts to follow ssr or prerender instructions. b) Set your engines (npm/ yarn node) in tsconfig. c) Break up tsconfig into .app and .server. d) hunt through your app for all “window” and “document” references. It’s still (at least familiar to me from experience with ruby on rails) a git push heroku where you’re sending the whole git file to the server and it’s running npm start.
5. Random stuff breaks due to when functions execute relative to server render. I’ve set up my site with ngrx and some nested smart components. I was using things like my call to ObservableMedia to give me media breakpoints that I pushed into the store and then pulled into things like mat-grid-list. All my mat-grid-list columns broke (I had to set the initial values in the dumb component rather than assume they’d make it through from the smart component’s inital values…weird stuff like that due to race conditions with the server’s render time to publish the html.) Get ready to hack it to get it working and then note what you’re going to have to do to optimize it later (I’ll probably end up hard coding the grid column number on the server side and keeping my column calculating function on the browser side).
6. Optimize your server. Hadn’t done this in a while, since I’d been hosting the static site on s3 + cloudfront. Originally went the route of adding compression, etc to the express app. Realized the better route is to add a CDN in front of the app to take the load off the app, so went back to cloudfront in front of the heroku site.
7. Get your meta tags right. This is still a work in progress…would welcome any best practices on rel=canonical with Angular 5.
8. Eliminate build time and module size. Also still a to-do. Things like my tests are still running through webpack. Haven’t figured out ts-loader, webpack.server.config to the level of figuring out how to exclude. Would welcome any pointers. And still have an ongoing task of breaking up NgMaterial and RxJs.

Results:

1. Have a html website the search engines and social sites can read. Already see the GoogleBot slurping (and grabbing links to my .
2. HTML pages load FAST. Especially if they’re cached by the CDN. I’m seeing some of my core pages deploy html in ~20 ms (which starts my images downloading) to get initial paint with images in the <1s range.
3. Better benchmarks. Seeing scores on https://testmysite.withgoogle.com go from the 9–10 second range to 3–4 seconds. Expecting to see that translate into lower mobile bounce rate…
4. Pathway to AMP…here we go again…