Skip to content

Features

This chapter describes features build into the Remix stack. The features are added to the stack since we believe that around 80 percent of apps will need these features. On the other hands it's a showcase how to integrate with Remix.

Please revisit the features you need and remove the others

Statista integrates applications on a path inside of the statista.com domain (e.g. /outlook is the path into the market insides application). The Remix router assumes that all relative links are inside the same application and could be purely done by client-side navigation/rendering. This is not true at Statista, because of the upper mentioned integration.

To mitigate this, the Link Component of the stack does handle application internal links different from application external links.

The link component in the stack is combined with link styling of atlas and should not be used as is. Instead use the Link component from the Atlas Component Library!

Mocking 3rd-party services

The Remix stack does contain a whole system to provide mocks for all backend and 3rd-party services.

This mock system should be used to allow local development without additional setup of any backend or 3rd-party service access.

In addition it enables the team build stable and reliable tests for the application without extra infrastructure.

Testing

Testing Remix applications should be an essential part of the development process. It ensures functionality and safe rollout of the application to production.

Additional CI/CD workflows for automating updates and increase developer productivity is tied to a good test base of each application.

Unit tests

Unit test in the Remix stack are done using vitest.

All files in the app folder ending with .test.ts or .test.tsx are run by vitest in a JSDOM environment. This does simulate a browser environment and allows to test React components and Remix navigation behavior.

All files ending with .server.test.ts are run by vitest in a node.js environment. This allows testing all server-side code.

Integration / End-to-end tests

Integration tests in the Remix stack are done using Playwright. It's a browser automation tool developed and maintained by Microsoft.

It does support executing test in Chrome, FireFox and Webkit (Safari).

All files in the tests/e2e folder ending with .test.ts are run by Playwright.

Atlas

The Remix stack has our Atlas Component Library already build in. All the components are ready to be used.

The setup includes (See the root.tsx file in your created app):

  • Icon integration (Statista brand book icons)
  • Link styling

Global Components

Global Components is a set of React components which are cross-cutting concerns for almost all pages at Statista. For example the main navigation in the page header, or the footer and contact elements on all pages.

All setup for the global components is done in the root.tsx of your application. It contains the navigation (desktop and mobile), user menu, top-level search, the contact module and the footer.

I18n

Translations are managed through *.xliff files in configfrontend and provided from this npm package.

When you add or change translations in configfrontend, an update to this npm package will be automatically released. The Remix runtime package provides the actual translation functions and provider components. Checkout the docs for that package for usage examples..

A script is provided to statically analyse usages of the translation function and extract all the used translations for your app. Note: You should never have to run this manually, it is run automatically in the background when starting the dev server or building the application.

pnpm run generate-i18n

Single Sign On

Single Sign On is a major requirement to integrate your application into the Statista landscape for user-facing applications.

Analytics

MTAM

The MarTech Agents Manager is responsible for loading various marketing and tracking scripts on the platform, e.g. the script responsible for the cookie banner. To enable MTAM in your application, please read the Integration Documentation of MTAM.

The integration happens in the root.tsx file.

GTM

The Google Tag Manager and the gtm library is responsible for user tracking as well pushing data to the data-layer. To enable the GTM library in your application, please set the environment variable APP_ENABLE_GTM=true and optionally pass the GTM ID APP_GTM_ID=GTM-XXX.

For further library documentation please take a look at: Tracking gtm library.

OpenAPI Integration

The stack contains a tool to combine an OpenAPI definition with typechecking by TypeScript. The tools used do need an OpenAPI YAML or JSON file to create type declaration from it.

It's recommended to use TypeSpec to create this OpenAPI definition, since it's easier to read and maintain.

To use the openapi-fetch tool built into the stack, these environment variables have to be set appropriately for your environment:

  • APP_API_ENDPOINT This variable should contain the URL of the backend API server to talk to while running the application. This should be set for all environments (e.g. local development, staging, production).
  • APP_API_KEY (optional) This variable could contain an API key to authenticate the application towards the backend API server. The backend API server will receive the key in the header field x-api-key.
  • APP_API_VERSION (optional) If the used API is versioned, the selected API version has to be set into this variable. The backend API server will receive the version in the header field x-api-version

Datadog

To integrate with Datadog, you have to configure your setup with some additional values.

Setup these environment variables in GitHub:

  • APP_DD_API_KEY For the environments dev, stage and prod

These values can be get from any Datadog administrator. Your team should have received them during the AWS account creation.

Deployment

Deployment of your application is done with CDK. To create a deployment setup, you have to enable CDK setup during the application creation (the script asks to enable CDK).

By default the deployment has four different target environments:

  • local which is not deployed but used for local development on your machine.
  • dev which is deployed on every change to a pull-request. It could be used to support reviews and testing of your application.
  • stage which is integrated with Statista Stage and could be used to review the integration with other systems or applications.
  • prod which is integrated with Statista Prod

All environments could have a different configuration and have different requirements on the deployment.

Environment Configuration

The environment configuration for all environments is done through GitHub environments and secrets. In your repository you can set variables and secrets per environment, per repository and per organization. With these layers you can configure your application for each environment.

All environment variables and secrets which are prefixed with APP_ are handed from GitHub to your application during deployment.

Secret values are stored in your AWS ParameterStore. They are read back into node.js process.env object during application start and could be used as regular environment variables.

Local Environment

For local, the application is started with the integrated mock setup and does not need any backend integration to be active and available.

This keeps the local environment stable and reliable for development and testing.

Environment variables for local development could be set in a .env file. This file should not be committed but resides for local and personal configuration per developer.

Dev Environment

For dev, the setup takes care of creating a lightweight installation which does work with the mock setup by default. It does not require any backend setup available to run.

The dev environment is being deployed with the intended changes in a pull request. It uses lambda to be cheap and easy to create and destroy.

When the branch for that pull request is deleted, the deployment is destroyed. It's advised to configure your GitHub repository to delete branches when a pull request is merged.

Note: If the pull request is closed but the branch is not deleted, the deployment is not destroyed.

The dev deployment is guarded by GitHub authentication. This means only visitors who also have access to the PIT-Shared organization can visit the deployed application.

Dev Environment Variables and Secrets

  • AWS_REGION (optional) This should be a variable in the dev environment. It has to be to the AWS region the application should be deployed to. It defaults to 'eu-central-1'.

Stage Environment

For stage, the setup is integrated with the stage CDN of Statista. The whole environment is close to our production setup. The application needs the full configuration and all backend systems in place. No mocking is enabled.

All commits into the main branch of your application are deployed to the stage environment.

The main difference between stage and prod environments is, that stage does require an authentication step. For users this is visible when you open Statista Stage and see the AWS Cognito page. Only employees of Statista have access to stage.

Stage Environment Variables and Secrets

  • AWS_REGION (optional) This should be a variable in the stage environment. It has to be to the AWS region the application should be deployed to. It defaults to 'eu-central-1'.

Prod Environment

For prod, there is integration into the prod CDN of Statista. All backends have to be in place, the application is not running with any mocking setup.

No authentication is required to access the prod environment.

By default all commits pushed to a production branch are deployed to the prod environment.

Prod Environment Variables and Secrets

  • AWS_REGION (optional) This should be a variable in the prod environment. It has to be to the AWS region the application should be deployed to. It defaults to 'eu-central-1'.
Last updated: March 24, 2026 at 16:43
By: Maikel Lammers