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:
Baked into the static generated HTML files for client sided components.
Baked into server components / routes if they are not configured as force-dynamic
At runtime, environment variables are:
Not available to client-sided components - only build time env variables are exposed since they are baked in
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.