Yet another (opinionated) typescript service starter template.
- Limits the non-pure code to infrastructure layer
Extends the ones from typescript-service-starter
- Tries to follow Domain Driven Development and 3 Layers architecture
- As little of externalities requirements as possible (outputs to stdout/stderr, no auth management, etc.)
- No dependency on node_modules folder and filesystem at runtime, to allow bundling & small Docker image
- Config should not default to either development or production (link)
And extends the ones from typescript-library-starter
- Relies as much as possible on each included library's defaults
- Only rely on GitHub Actions
- Do not include documentation generation
npx degit gjuchault/typescript-functional-service-starter my-project
or click onUse this template
button on GitHub!cd my-project
npm install
git init
(if you used degit)npm run setup
To enable deployment, you will need to:
- Setup
NPM_TOKEN
secret in GitHub actions (Settings > Secrets > Actions) - Give
GITHUB_TOKEN
write permissions for GitHub releases (Settings > Actions > General > Workflow permissions)
This template is based on Fastify with some nice defaults (circuit breaker, redis rate limit, etc.). It leverages PostgreSQL as a storage (through slonik), Redis as a cache through ioredis).
For the logging & telemetry part, it uses pino and OpenTelemetry (for both prometheus-like metrics & tracing). To handle distributed tracing, it expects W3C's traceparent header to carry trace id & parent span id.
This template also tries to be easy to deploy through esbuild's bundling. This means you can not leverage node_modules and file system at runtime: reading static files from node_modules, hooking require
, etc. ill not be possible. This implies to be mindful on libraries (that would read static files from there older), or automatic instrumentation (that hook require
). Yet it comes with super small Docker images hat are fast to deploy.
For the functional programming side, this project leverages fp-ts
, as well as strict eslint rules from eslint-plugin-functional. While this is alright for the service's code, anything into infrastructure (and interaction with non functional libraries) will be less enforced. Anything that comes out is wrapped into functional.
client # generated fetch wrappers for your application
migrations # database migrations (.sql files, no rollback)
src/
├── application # service code
├── domain # pure functions & typescript models of your entities
├── presentation # communication layer (http)
├── repository # storage of your entities
├── infrastructure # technical components (cache, database connection, etc.)
├── helpers # utilities functions & non-domain code
└── test-helpers # test utilities (starting default port, resetting database, etc.)
This package can generate a type-safe client package when building (with npm run build:client
).
It can be used the following way:
import {
createClient as createMyAppClient,
createTraceHeader as createMyAppTraceHeader,
} from "my-app/client";
const myApp = createMyAppClient({
baseUrl: "http://sometarget/",
globalFetchOverrides: {
headers: {
"X-Custom-Token": "foo",
},
},
});
// GET /healthcheck
const data = await myApp.getHealthcheck({
headers: {
...createMyAppTraceHeader({
traceId: "some-trace-id",
parentSpanId: "some-span-id",
}),
},
});
// POST /foo/bar?query=param { body: "json" }
const data2 = await myApp.postFooBar({ query: "param" }, { body: "json" });
The client will validate the server's response through zod.
Typescript Service Starter relies on volta to ensure node version to be consistent across developers. It's also used in the GitHub workflow file.
Leverages esbuild for blazing fast builds, but keeps tsc
to generate .d.ts
files.
Generates two builds to support both ESM and CJS.
Commands:
build
: runs typechecking then generates CJS, ESM andd.ts
files in thebuild/
directoryclean
: removes thebuild/
directorytype:dts
: only generatesd.ts
type:check
: only run typecheckingtype:build
: only generates CJS and ESM
typescript-functional-service-starter uses vitest. The coverage is done through vitest, using c8.
Commands:
test
: runs vitest test runnertest:watch
: runs vitest test runner in watch modetest:coverage
: runs vitest test runner and generates coverage reports
This template relies on the combination of eslint — through typescript-eslint for linting and prettier for formatting. It also uses cspell to ensure spelling
Commands:
format
: runs prettier with automatic fixingformat:check
: runs prettier without automatic fixing (used in CI)lint
: runs eslint with automatic fixinglint:check
: runs eslint without automatic fixing (used in CI)spell:check
: runs spellchecking
Under the hood, this service uses semantic-release and commitizen.
The goal is to avoid manual release process. Using semantic-release
will automatically create a github release (hence tags) as well as an npm release.
Based on your commit history, semantic-release
will automatically create a patch, feature or breaking release.
Commands:
cz
: interactive CLI that helps you generate a proper git commit message, using commitizensemantic-release
: triggers a release (used in CI)