Angular SSR: The Browser Is Not The Server

blazing fast performance with Angular Universal

One of the great things about SSR is that we get to use 

the same code on our frontend and our backend

When we use the same code, right off the bat we have a problem: 

 and there are differences between what we can do in each environment.

The benefit of rendering our Angular app on the 

we can fetch data privately and efficiently

Our server is (in this case) Node.js, and so on the server we can use:

But the browser is not the server. And if we try to call browser-only APIs, then we'll break SSR.

Well, three things come to mind that are exclusive to the browser:

While it's awesome that our Angular application can share code between the server and the browser, if we want to use any of these objects, 

we need to execute a different logic path

 based on the current runtime: Node.js or the browser window. 

Below, I'm going to show you one of the techniques for doing that.

Let's add internationalization to your application. Let's display product prices in three currencies: US dollars, British pounds, and Polish zloty. The application should pick a currency based on browser settings, and if a given language is not supported, it should fall back to Polish zloty.

Now let's detect user language and implement the 

 method that returns one of the three available currency codes:

@Injectable({
  providedIn: 'root'
})
export class I18nService {

  private userLang;

  constructor() { 
      this.userLang = window.navigator.language;
  }

  public getCurrencyCode(): string {
    switch(this.userLang) {
      default: 
      case 'pl-PL': return 'PLN';
      case 'en-US': return 'USD';
      case 'en-EN': return 'GBP';
    }
  }
}

, we can use this service to get the user's currency:

public userCurrency: string = this.i18n.getCurrencyCode();

constructor(
  private route: ActivatedRoute, 
  private ps: ProductsService, 
  private us: UserService, 
  private i18n: I18nService
) { }

<small class="text-muted">{{p.price | currency: userCurrency}}</small>

From now on, prices should display in a currency defined by the user's localization settings. This is great, right?

ERROR: ReferenceError: window is not defined

It would help if we had a mechanism to detect whether the current runtime is the browser or the server - and thankfully that's why we have 

isPlatformBrowser() and isPlatformServer()

 package. Each of these methods accepts one parameter: the platform ID. It can be retrieved via the Dependency Injection mechanism using the injection token 

So to change our internationalization service 

import { 
  Injectable, 
  Inject, 
  PLATFORM_ID 
  } from '@angular/core';
import { 
  isPlatformBrowser 
  } from '@angular/common';

Modify the service constructor to only use the 

 object if an instance of the service executes in the browser:

export class I18nService {
  constructor(
    @Inject(PLATFORM_ID)
    private platformId: any
  ) {
    if (isPlatformBrowser(this.platformId)) {
      this.userLang =
        window.navigator.language;
    } else {
      // server specific logic
    }
  }
  // ...
}

This should be enough for SSR to start working again 

 get internationalization pre-rendered on our server-side render -- internationalization won't appear until after the app loads. 

So what we need is a way to know what language to render 

from the origin HTTP request to the server

The question now is how to retrieve information about user language on the server. 

When you're performing a request from the browser, the browser adds a bunch of HTTP headers that you might not usually think about. 

which tells us what language the user wants!

For example, the header might come through like this: 

Angular Universal allows you to get an object that represents an HTTP request. It's available via Dependency Injection under the 

import { Injectable, Inject, PLATFORM_ID, Optional } from '@angular/core';
import { isPlatformBrowser } from '@angular/common';
import { REQUEST } from '@nguniversal/express-engine/tokens';
import { Request } from 'express';

 object and retrieve user language from the 

export class I18nService {
  constructor(
    @Inject(PLATFORM_ID) private platformId: any,
    @Optional()
    @Inject(REQUEST) private request: Request
  ) {
    if (isPlatformBrowser(this.platformId)) {
      this.userLang =
        window.navigator.language;
    } else {
      this.userLang = (
        this.request.headers[
          "accept-language"
        ] || ""
      ).substring(0, 5);
    }
  }
  // ...
}

 decorator. Whenever your code executes in the browser where the 

 object is not available, this decorator enables the 

 or Postman, we can verify that language settings are working within the pre-render (or fall back to Polish zloty when the 

Angular Universal is a super-powerful tool in your Angular toolbox -- but if you're just used to writing 

 Angular, you might find it a bit tricky. But with a little guidance, you'll find you can get blazing-fast Angular apps. Check out the course 

Mastering Angular Universal: Build Blazing-fast Server-Side-Rendered Angular App

<h1 data-node-type="titlePlaceholder" class="titlePlaceholder">Angular SSR: The Browser Is Not The Server</h1><p>In this article, we're talking about <strong>blazing fast performance with Angular Universal</strong> with server-side-rendering (SSR).</p><p>One of the great things about SSR is that we get to use <strong>the same code on our frontend and our backend</strong> to render our app. Well, sort of.</p><p>When we use the same code, right off the bat we have a problem: <strong>the browser is not the server</strong> and there are differences between what we can do in each environment.</p><p>The benefit of rendering our Angular app on the <em>server</em> is that <strong>we can fetch data privately and efficiently</strong> <em>before</em> we send anything to the browser.</p><p>Our server is (in this case) Node.js, and so on the server we can use:</p><ul><li><p><code>request</code> to make HTTP requests retrieved by the server (and these can be private, authenticated requests)</p></li><li><p><code>fs</code> to access the filesystem (if we need to)</p></li><li><p>access to anything else you'd want on the server: Redis, AWS services, the database etc.</p></li></ul><p>But the browser is not the server. And if we try to call browser-only APIs, then we'll break SSR.</p><h2><a name="what-can-break-ssr?" id="what-can-break-ssr?">What can break SSR?</a></h2><p>Well, three things come to mind that are exclusive to the browser:</p><ul><li><p><code>window</code> can be used to e.g. display alerts to the user</p></li><li><p><code>document</code> belongs to the <code>window</code> namespace and is used to manipulate DOM elements</p></li><li><p><code>navigator</code> belongs to the <code>window</code> namespace and enables service workers that are used extensively with Progressive Web Applications</p></li></ul><p>While it's awesome that our Angular application can share code between the server and the browser, if we want to use any of these objects, <strong>we need to execute a different logic path</strong> based on the current runtime: Node.js or the browser window. </p><p>Below, I'm going to show you one of the techniques for doing that.</p><h2><a name="adding-internationalization" id="adding-internationalization">Adding internationalization</a></h2><p>Let's add internationalization to your application. Let's display product prices in three currencies: US dollars, British pounds, and Polish zloty. The application should pick a currency based on browser settings, and if a given language is not supported, it should fall back to Polish zloty.</p><p>Let's generate a new service:</p><textarea data-iscodemirror="true" data-mode="text/jsx" data-uniqueid="cm-eqdmWamNrD1Ry5SxDxNf3" id="cm-eqdmWamNrD1Ry5SxDxNf3">ng g s i18n</textarea><p>Now let's detect user language and implement the <code>getCurrencyCode()</code> method that returns one of the three available currency codes:</p><textarea data-iscodemirror="true" data-mode="text/jsx" data-uniqueid="cm-VEMCt8rxhdpZRR2xrx2Ca" id="cm-VEMCt8rxhdpZRR2xrx2Ca">@Injectable({
  providedIn: 'root'
})
export class I18nService {

  private userLang;

  constructor() { 
      this.userLang = window.navigator.language;
  }

  public getCurrencyCode(): string {
    switch(this.userLang) {
      default: 
      case 'pl-PL': return 'PLN';
      case 'en-US': return 'USD';
      case 'en-EN': return 'GBP';
    }
  }
}</textarea><p>Now in one of our components, say <code>ProductDetailsComponent</code>, we can use this service to get the user's currency:</p><textarea data-iscodemirror="true" data-mode="text/jsx" data-uniqueid="cm-3dlBBwC7lA-AhDXnbA72w" id="cm-3dlBBwC7lA-AhDXnbA72w">public userCurrency: string = this.i18n.getCurrencyCode();

constructor(
  private route: ActivatedRoute, 
  private ps: ProductsService, 
  private us: UserService, 
  private i18n: I18nService
) { }</textarea><p>Then we could use the <code>userCurrency</code> in a view with the <code>currency</code> pipe:</p><textarea data-iscodemirror="true" data-mode="text/jsx" data-uniqueid="cm-ur_YLDWVzETkfJFtfFrDX" id="cm-ur_YLDWVzETkfJFtfFrDX">&lt;small class="text-muted"&gt;{{p.price | currency: userCurrency}}&lt;/small&gt;</textarea><p>From now on, prices should display in a currency defined by the user's localization settings. This is great, right?</p><p><strong>Well, no.</strong> Unfortunately, this logic breaks SSR:</p><textarea data-iscodemirror="true" data-mode="text/jsx" data-uniqueid="cm-eobybIrN3ZYNzSYNff3wR" id="cm-eobybIrN3ZYNzSYNff3wR">ERROR: ReferenceError: window is not defined</textarea><figure class="photo figure-position-inline"><img src="https://s3.amazonaws.com/assets.fullstack.io/n/20201203023541458_error.jpg" attachmentid="28daa10e-0660-4dd1-8562-0a85a9f534d5" contenteditable="false" data-width="1474" data-height="883"><div></div></figure><p>It would help if we had a mechanism to detect whether the current runtime is the browser or the server - and thankfully that's why we have <code>isPlatformBrowser()</code> and <code>isPlatformServer()</code>:</p><h2><a name="isplatformbrowser-and-isplatformserver" id="isplatformbrowser-and-isplatformserver">isPlatformBrowser() and isPlatformServer()</a></h2><p>Angular ships with the <code>isPlatformBrowser()</code> and <code>isPlatformServer()</code> methods in the <code>@angular/common</code> package. Each of these methods accepts one parameter: the platform ID. It can be retrieved via the Dependency Injection mechanism using the injection token <code>PLATFORM_ID</code> available in the <code>@angular/core</code> package.</p><p>So to change our internationalization service <code>I18nService</code> above, Add these new imports:</p><textarea data-iscodemirror="true" data-mode="text/jsx" data-uniqueid="cm-QRv1HWlQE3IEYRsiu-e3w" id="cm-QRv1HWlQE3IEYRsiu-e3w">import { 
  Injectable, 
  Inject, 
  PLATFORM_ID 
  } from '@angular/core';
import { 
  isPlatformBrowser 
  } from '@angular/common';</textarea><p>Modify the service constructor to only use the <code>window</code> object if an instance of the service executes in the browser:</p><textarea data-iscodemirror="true" data-mode="text/jsx" data-uniqueid="cm-GSrDv_SxvRmIlzLcCIrWl" id="cm-GSrDv_SxvRmIlzLcCIrWl">export class I18nService {
  constructor(
    @Inject(PLATFORM_ID)
    private platformId: any
  ) {
    if (isPlatformBrowser(this.platformId)) {
      this.userLang =
        window.navigator.language;
    } else {
      // server specific logic
    }
  }
  // ...
}</textarea><p>This should be enough for SSR to start working again <strong>but</strong> we <em>don't</em> get internationalization pre-rendered on our server-side render -- internationalization won't appear until after the app loads. </p><p>So what we need is a way to know what language to render <strong>from the origin HTTP request to the server</strong>.</p><h2><a name="the-request-object" id="the-request-object">The Request object</a></h2><p>The question now is how to retrieve information about user language on the server. <strong>Is it even possible?</strong> </p><p>Yes, it is. </p><p>When you're performing a request from the browser, the browser adds a bunch of HTTP headers that you might not usually think about. </p><p>One of these headers is <code>Accept-Language</code> <strong>which tells us what language the user wants!</strong></p><p>For example, the header might come through like this: <code>Accept-Language: en-US,en;q=0.5</code>. </p><h3><a name="getting-headers-from-the-request" id="getting-headers-from-the-request">Getting Headers from the Request</a></h3><p>Angular Universal allows you to get an object that represents an HTTP request. It's available via Dependency Injection under the <code>REQUEST</code> token from the <code>@nguniversal/express-engine/tokens</code> package. The <code>Request</code> object contains the following fields:</p><ul><li><p><code>body</code></p></li><li><p><code>params</code></p></li><li><p><code>headers</code></p></li><li><p><code>cookies</code></p></li></ul><p>So we update our imports by adding the <code>Request</code> object, the <code>REQUEST</code> injection token, and the <code>Optional</code> decorator:</p><textarea data-iscodemirror="true" data-mode="text/jsx" data-uniqueid="cm-s6OtzAbGf6nq02oigCgLh" id="cm-s6OtzAbGf6nq02oigCgLh">import { Injectable, Inject, PLATFORM_ID, Optional } from '@angular/core';
import { isPlatformBrowser } from '@angular/common';
import { REQUEST } from '@nguniversal/express-engine/tokens';
import { Request } from 'express';</textarea><p>Change the constructor to inject the <code>Request</code> object and retrieve user language from the <code>Accept-Language</code> header:</p><textarea data-iscodemirror="true" data-mode="text/jsx" data-uniqueid="cm-oOjcVKjUdjdPh3ER6Dqdh" id="cm-oOjcVKjUdjdPh3ER6Dqdh">export class I18nService {
  constructor(
    @Inject(PLATFORM_ID) private platformId: any,
    @Optional()
    @Inject(REQUEST) private request: Request
  ) {
    if (isPlatformBrowser(this.platformId)) {
      this.userLang =
        window.navigator.language;
    } else {
      this.userLang = (
        this.request.headers[
          "accept-language"
        ] || ""
      ).substring(0, 5);
    }
  }
  // ...
}</textarea><blockquote data-block-type="information" class="information annotated"><p>Notice the usage of the <code>@Optional()</code> decorator. Whenever your code executes in the browser where the <code>Request</code> object is not available, this decorator enables the <code>request</code> variable to contain <code>null</code>. </p></blockquote><p>If we use a tool like <code>curl</code> or Postman, we can verify that language settings are working within the pre-render (or fall back to Polish zloty when the <code>Accept-Language</code> header is missing):</p><figure class="photo figure-position-inline"><img src="https://s3.amazonaws.com/assets.fullstack.io/n/20201203023708736_postman.jpg" attachmentid="b47ddf35-e24a-4ccc-813b-8fad57b6893f" contenteditable="false" data-width="1421" data-height="1139"><div></div></figure><p>Angular Universal is a super-powerful tool in your Angular toolbox -- but if you're just used to writing <em>frontend</em> Angular, you might find it a bit tricky. But with a little guidance, you'll find you can get blazing-fast Angular apps. Check out the course <em><a href="https://www.newline.co/courses/newline-guide-to-angular-universal" rel="noopener noreferrer nofollow">Mastering Angular Universal: Build Blazing-fast Server-Side-Rendered Angular App</a></em></p><figure class="photo figure-position-inline"><img src="https://s3.amazonaws.com/assets.fullstack.io/n/20201203024200345_angular-universal-hero.jpg" attachmentid="fd0407fa-0f67-4085-8369-565d72bd9eb7" contenteditable="false" data-width="600" data-height="338"><div></div></figure><p><em><a href="https://www.newline.co/courses/newline-guide-to-angular-universal" rel="noopener noreferrer nofollow">s</a></em></p><p></p>

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Angular SSR: The Browser Is Not The Server

Responses (0)

Masterclasses

Tutorials

Fullstack React with TypeScript