Dev Environment

Create a .env file in project root, and add the following entries:

DYFF_API_BASE_URL=http://api.dyff.io # Base Route
DYFF_API_AUTH_URL=http://api.dyff.io/auth # Auth Route
DYFF_API_FULL_URL=http://api.dyff.io/dyff/v0 # Actual API Route
FORCE_DYFF_API_KEY=###### # 0 or 1 (as string)
DYFF_API_KEY=###### # (string)

If NEXT_PUBLIC_FORCE_DYFF_API_KEY is set to 1, the AuthProvider token will be defaulted to NEXT_PUBLIC_DYFF_API_KEY to allow overriding the api key during development and testing.

Manual Deployment

Install node dependencies

npm i

Run dev server

npm run dev

Docker Deployment

Build docker image with make build

Run with make run

Styling / Linting

For local JS/TS linting, we use prettier, ESLint and a pre-commit hook run with

For Gitlab CI linting, the same is performed via saferatday0 pipelines specified in .gitlab-ci.yml

Next.JS Environment Variables

Environment variables provide the foundation for the “build once deploy anywhere” principle, especially when building and running docker containers. However, Next.JS dislikes cool things and make it hard on us devs to have runtime environment variables.

Build time environment variables are:

  1. Baked into the static generated HTML files for client sided components.

  2. Baked into server components / routes if they are not configured as force-dynamic

At runtime, environment variables are:

  1. Not available to client-sided components - only build time env variables are exposed since they are baked in

  2. Available to server components if they are force-dynamic

There’s no officially supported workaround for this except to expose an API route that client sided components can hit and fetch the server-side environment variable. While this is okay, it stinks.

See several discussions of this issue on vercel github issues,

There is a third party package that leverages server component layouts and a React Provider to expose env variables at runtime. It implements a manual solution to the problem for us.