DEV Community: ellioseven

A Next.js + Firebase TDD Environment Example

ellioseven — Fri, 09 Apr 2021 05:30:04 +0000

Recently I've been working with a start-up that leverages Next.js and Firebase. This is a very interesting stack, as it lends itself to a very fast development lifecycle. As a result, it's been tempting to let testing take a back seat, especially when the initial development cost for a testing environment with a range of testing strategies is quite large.

I've spent some time creating a TDD environment for a Next.js and Firebase application, so I thought I'd share my results here to reduce that time cost and help avoid some of the confusion and traps.

The rest of the article outlines a basic overview, features, technologies used, architecture notes and strategies covered.

Check out the code, illustrating how I've created the environment.

Overview

The repo contains a simple application that allows a user to enter a score, which may appear on the top score board. The application attempts to include a surface area of functionality you'd find in a typical Next.js application. See the README for instructions how to install and run the application.

Features

Emulated Firebase: Firebase offers local emulated environments, including Firestore and Functions
Component Tests: Simple tests with RWT
API Integration Tests: API endpoint tests that verify Firestore data
Firestore Functions Unit Tests: Tests that consume and verify emulated Firestore Function logic
Application E2E Tests: End to end tests with Cypress.js
CircleCI Integration: A simple example showcasing how to set up tests suites into a CI pipeline

Technologies

Docker: Virtualised environments for application & Firebase runtimes
Next.js: Popular React application runtime
Firebase: Popular database and serverless function infrastructure
Cypress: Automated browser simulation for integration tests
Jest: Automated testing framework
React Testing Library: Automated React testing library
MSW: API mocking library
CircleCI: Continuous integration & delivery SaaS
Husky: Bootstrap local development with Git hooks to run tests on Git events

Structure

.circleci - CircleCI configuration
.docker - Docker configuration and storage for images
cypress - Cypress E2E configuration and assertions
packages/app - Next.js application
packages/firebase - Firebase services and Firestore data collections
packages/functions - Firebase Functions logic

Testing Architecture

The goal is to create an environment that solves complexities for test strategies, so that any area in the stack can be covered by a test, breadth over depth. This helps developers figure out "how" to create tests.

Docker is used to make it as easy as a simple command to build all the system dependencies, such as Node, Cypress, Java, Firebase CI and emulators, etc. This makes it extremely easy to pull down and configure the testing environment. The are two environments, dev and test, which provide the different services and configuration required.

During local development, seed data is injected to create a controllable and reliable test data for tests and local development. When the application boots, a history of scores and a leaderboard is already created. This provides consistent data across the development and testing team. This is done in a Docker service, which will wait for the Firebase emulators to become healthy before migration.

Firebase provides emulators that mimic some of their cloud services such as Firestore and Functions. This is extremely helpful, but getting the environment set up can be confusing and time confusing (system dependencies, environment variables, configuration, etc.). Grokking how to test assert Firestore data and test serverless functions can be difficult. This repository attempts to help solve that.

I've also included CircleCI integration to show how the test environment can be built in a CI process. I use the machine type executor which provides a VM with full network management and Docker utilities. This makes it easy to use Docker's "host network mode", which simplifies container networking.

Mono-repositories are a popular pattern, so I have implemented this approach with Lerna to show how the structure might look.

Testing Strategies

React Unit Tests

There is a huge amount of resources on how to run unit tests against React components, and so isn't the focus of this repository. I have included some basic Next.js/React tests that assert component and API interaction to depict how they can be structured.

API/Firebase Integration Tests

Examples include how to pre-populate and tear down the emulated Firebase environment for each API integration test. Be aware that Firestore interaction (eg: pre-populating data) will trigger built Firebase functions. If possible, it's best to keep interaction to a minimum to prevent a high frequency of triggers.

Firebase Functions Tests

Firebase comes with testing libraries which help interact with emulated environments. I've included some examples that pre-populate Firestore and run simulated snapshots. Testing functions can be tricky, as they run as synchronous background tasks, meaning they can't be simply changed and asserted. This can also cause potential race conditions. To overcome this problem, I've provided a simple solution that waits and retries for the assertion.

E2E Tests

End to end tests are managed with Cypress. Before Cypress can be launched, packages are built, the emulators are run, data is seeded, then the Next.js is booted in production mode. This prevents any problems with having to wait for pages to compile, which can cause timeout issues. The timing sequence is managed by Docker Compose, which will check for healthy services before running appropriate tasks.

A Next.js Application Retrospective

ellioseven — Sun, 18 Oct 2020 00:55:23 +0000

I've spent the last couple of years developing an SSR application with Next.js and Apollo. The project features a mixture of job boards, a large amount of content (from a CMS) and user profiles. I thought I'd share some of the challenges, mistakes and thing's I wish I knew before I started.

Some of these to you might be quite obvious, however what I listed here was really important to the success of our project. Hopefully it will be of use to some.

tldr;

Do you really need to SSR?
Monitor Performance Early
getInitialProps Optimisation is Vital
Apollo Cache Key Optimisation is Vital
Watch Out for Styled Component Nested Props
async/await in getInitialProps
Consider Building a Version Notification System Early On

Do you really need to SSR?

The first hurdle was determining if we really needed server side rendering. Obviously there are many pros and cons to analyse. It's really important to weigh these options and understand the trade-offs between a static, dynamic or server side build.

For us, SEO was a determining factor. We needed to display source HTML for search engines, as well as managing meta and redirects. Alternative methods, such as pre-generated content just wasn't viable, as we had huge amounts of multi-tenant content that's published and changed frequently.

You should ask yourself if the benefits of SSR (eg: SEO, request/response control) outweigh the cons (eg: time to first byte, complexity, server infrastructure).

As a general guideline, I try to favour static generated sites for performance reasons. Study getStaticPaths to see if it can work for you.

Monitor Performance Early

This aspect is not tied to SSR rendering, but an important fundamental. It's too easy to make a decision and be completely unaware that you've made a huge impact on performance.

For example, you've got a requirement that needs to support timezones. You use moment.js, build your feature, test it, deploy it. Boom. Easy. However, you didn't realise that you accidentally used all locales, which means 4MB of uncompressed JSON is now being distributed to your users.

This mistake may be obvious to you, but maybe not to a team member.

So many mistakes could of been prevented by implementing a fitness function that analyses performance as part of the CI pipeline. Automatic budgets on time to first byte, bundle size and HTML page size are really important to prevent performance blunders being deployed to production. Use something like Google Lighthouse to track those metrics.

This optimisation will help find many problems mentioned later in this article.

`getInitialProps` Optimisation is Vital

Everything that you pass from getInitialProps gets hydrated. It's printed directly to HTML, which means the user has to retrieve and parse it first before anything else can happen.

Always keep this is the back of your head. Do you need that data? It's very easy to pass a large amount of data that isn't used, forcing users to download and wait for a whole bunch of data they don't need.

This is something that should be tracked in the CI pipeline.

Apollo Cache Key Optimisation is Vital

When using Apollo, you should have a basic awareness on how normalisation works. Apollo will attempt to break up and normalise objects on a type and ID. Failing that, it will attempt to store the object based on how it's queried.

Apollo will try to pass the cache during the hydration process, by printing it to HTML. This is a huge optimisation opportunity for SSR. Without effectively normalised data, the HTML size can really grow quickly.

A lot of our content uses an entityId unique identifier, instead of the default _id or id identifier. The cache passed via HTML was huge in some cases. By implementing a cache key, large amounts of raw HTML was trimmed.

This is something that should be tracked in the CI pipeline.

Watch Out for Styled Component Nested Props

When using styled components, you can pass dynamic props to a component:

import styled from "styled-components"

const Style = styled.div`
  border: 1px solid blue;

  .title {
    color: ${props => props.color};
  }
`

const Card = props => (
  <Style>
    <h1 className="title" color="blue">Card</h1>
  </Style>
)

This feature is powerful, however because the prop is on a nested selector, this caused large amounts of duplicated styles to be printed directly to HTML, which again, forced users to download and wait for data they didn't need.

Be very vary of using props on nested styles.

This can be resolved by using an additional styled component:

<Title className="title" color="blue">Card</Title>

Or by using plain old CSS (my preferred approach):

.title {
  color: attr(data-color);
}

<h1 className="title" data-color="blue">Card</h1>

`async/await` in `getInitialProps`

Using async/await in getInitialProps will block the entire request until the response has been resolved.

Content.getInitialProps = async () => {
  const response = await fetch() // ...
  const meta = response.data.meta
  return { meta }
}

Avoid doing this as much as you can, be aware of the cost. Every millisecond waiting for that response will an extra millisecond on the time to first byte.

Consider Building a Version Notification System Early On

So any headaches were caused because a lot of user's leave tabs open and do not refresh the page. The Next.js application is cached in memory over client side navigation, and may not receive a new version until the page has been refreshed. If your application communicates with an API, this situation gets complicated.

Example

A new version of the CMS removes a data type from the content API, which the frontend relies on. The change gets deployed on both platforms. However, the user has the original version in the browser. They navigate to a page that relies on that now removed data type, theres an error.

Yes, there are many ways to handle this error and could be alleviated with API versioning. However, the problem is complex, you may easily find yourself fall into this trap accidentally.

It may not be immediately obvious to the user that they need to refresh, especially if the error is silent. The situation becomes worse if that request is critical, such as authentication.

Notifying users that a new version is available can really help improve the situation. This solution may not be for you, but a notification system is a simplistic implementation that can help drastically.

That's All

If you got this far, thanks for taking the time to read my first published article. Hopefully this helps some avoid the traps and pitfalls made.