add monorepo structure

.editorconfig

@@ -0,0 +1,14 @@
+# Editor configuration, see http://editorconfig.org
+root = true
+
+[*]
+charset = utf-8
+max_line_length = 80
+indent_size = 2
+indent_style = space
+insert_final_newline = true
+trim_trailing_whitespace = true
+quote_type = double
+
+[*.md]
+trim_trailing_whitespace = false

.env.example

@@ -0,0 +1,4 @@
+# Environment variables
+
+# Allows environment-specific monorepo behavior (e.g. only execute commands for certain packages)
+LERNA_FLAGS=""

.gitignore

@@ -1 +1,214 @@
-#
+# Created by https://www.toptal.com/developers/gitignore/api/node,windows,linux,macos
+# Edit at https://www.toptal.com/developers/gitignore?templates=node,windows,linux,macos
+
+### Linux ###
+*~
+
+# temporary files which can be created if a process still has a handle open of a deleted file
+.fuse_hidden*
+
+# KDE directory preferences
+.directory
+
+# Linux trash folder which might appear on any partition or disk
+.Trash-*
+
+# .nfs files are created when an open file is removed but is still being accessed
+.nfs*
+
+### macOS ###
+# General
+.DS_Store
+.AppleDouble
+.LSOverride
+
+# Icon must end with two \r
+Icon
+
+
+# Thumbnails
+._*
+
+# Files that might appear in the root of a volume
+.DocumentRevisions-V100
+.fseventsd
+.Spotlight-V100
+.TemporaryItems
+.Trashes
+.VolumeIcon.icns
+.com.apple.timemachine.donotpresent
+
+# Directories potentially created on remote AFP share
+.AppleDB
+.AppleDesktop
+Network Trash Folder
+Temporary Items
+.apdisk
+
+### Node ###
+# Logs
+logs
+*.log
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+lerna-debug.log*
+.pnpm-debug.log*
+
+# Diagnostic reports (https://nodejs.org/api/report.html)
+report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json
+
+# Runtime data
+pids
+*.pid
+*.seed
+*.pid.lock
+
+# Directory for instrumented libs generated by jscoverage/JSCover
+lib-cov
+
+# Coverage directory used by tools like istanbul
+coverage
+*.lcov
+
+# nyc test coverage
+.nyc_output
+
+# Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files)
+.grunt
+
+# Bower dependency directory (https://bower.io/)
+bower_components
+
+# node-waf configuration
+.lock-wscript
+
+# Compiled binary addons (https://nodejs.org/api/addons.html)
+build/Release
+
+# Dependency directories
+node_modules/
+jspm_packages/
+
+# Snowpack dependency directory (https://snowpack.dev/)
+web_modules/
+
+# TypeScript cache
+*.tsbuildinfo
+
+# Optional npm cache directory
+.npm
+
+# Optional eslint cache
+.eslintcache
+
+# Optional stylelint cache
+.stylelintcache
+
+# Microbundle cache
+.rpt2_cache/
+.rts2_cache_cjs/
+.rts2_cache_es/
+.rts2_cache_umd/
+
+# Optional REPL history
+.node_repl_history
+
+# Output of 'npm pack'
+*.tgz
+
+# Yarn Integrity file
+.yarn-integrity
+
+# dotenv environment variable files
+.env
+.env.development.local
+.env.test.local
+.env.production.local
+.env.local
+
+# parcel-bundler cache (https://parceljs.org/)
+.cache
+.parcel-cache
+
+# Next.js build output
+.next
+out
+
+# Nuxt.js build / generate output
+.nuxt
+dist
+
+# Gatsby files
+.cache/
+# Comment in the public line in if your project uses Gatsby and not Next.js
+# https://nextjs.org/blog/next-9-1#public-directory-support
+# public
+
+# vuepress build output
+.vuepress/dist
+
+# vuepress v2.x temp and cache directory
+.temp
+
+# Docusaurus cache and generated files
+.docusaurus
+
+# Serverless directories
+.serverless/
+
+# FuseBox cache
+.fusebox/
+
+# DynamoDB Local files
+.dynamodb/
+
+# TernJS port file
+.tern-port
+
+# Stores VSCode versions used for testing VSCode extensions
+.vscode-test
+
+# yarn v2
+.yarn/cache
+.yarn/unplugged
+.yarn/build-state.yml
+.yarn/install-state.gz
+.pnp.*
+
+### Node Patch ###
+# Serverless Webpack directories
+.webpack/
+
+# Optional stylelint cache
+
+# SvelteKit build / generate output
+.svelte-kit
+
+### Windows ###
+# Windows thumbnail cache files
+Thumbs.db
+Thumbs.db:encryptable
+ehthumbs.db
+ehthumbs_vista.db
+
+# Dump file
+*.stackdump
+
+# Folder config file
+[Dd]esktop.ini
+
+# Recycle Bin used on file shares
+$RECYCLE.BIN/
+
+# Windows Installer files
+*.cab
+*.msi
+*.msix
+*.msm
+*.msp
+
+# Windows shortcuts
+*.lnk
+
+# End of https://www.toptal.com/developers/gitignore/api/node,windows,linux,macos

.prettierrc

@@ -0,0 +1,7 @@
+{
+  "endOfLine": "lf",
+  "semi": true,
+  "singleQuote": false,
+  "tabWidth": 2,
+  "trailingComma": "es5"
+}

README.md

@@ -0,0 +1,153 @@
+<div align="center">
+  <h1>
+    <div>🗺️</div>
+    Blueprint
+  </h1>
+</div>
+
+This readme gives developers an overview over the system architecture and the development and operations workflows. It documents a full circle DevOps approach that encourages cross-functional collaboration and fast flow of change.
+
+# 🧬 Structure
+
+## Principles
+
+- The tech stack is centered around full stack JavaScript solutions.
+- This Monorepo is based on [npm workspaces](https://docs.npmjs.com/cli/v7/using-npm/workspaces) which means it contains an npm root package and multiple child packages.
+- Child packages are kept in different directories (infrastructure, apps, libs) based on their architectural role (inspired by [Nx's approach](https://nx.dev/structure/applications-and-libraries)).
+- A child package can reference other child packages within the Monorepo as a code dependency to access its code.
+- [Lerna](https://github.com/lerna/lerna) is used to run npm scripts across all packages. It determines the execution order of scripts (e.g. deployment scripts) based on the dependency topology.
+- Configuration values are [stored in environment variables](https://12factor.net/config) and are not versioned. They are passed in via a local `.env` file or by specifying environment variables in the CI/CD runtime.
+- Staging and production infrastructure environments are [kept similar](https://12factor.net/dev-prod-parity).
+
+## Overview
+
+```mermaid
+graph LR
+
+```
+
+## infrastructure/
+
+Infrastructure contains the setup for cloud-based environments and services and is required to deploy and operate applications. The setup is described through documentation or through infrastructure as code solutions.
+
+## apps/
+
+Applications are executables that are deployed to and operated on infrastructure. They use internal and external libraries as code dependencies. Applications are configured through environment variables that are passed in at runtime or compiled into the application at compile time.
+
+## libs/
+
+Libraries are used as code dependencies by applications or other libraries. They typically implement specific functionality (e.g. utility functions, user interface components) or the network interaction between applications on the client side as a "client library" or the server side as an "api library". Libraries can be published to make them available for external applications outside the Monorepo. Libraries can define their own build process or just provide source files that are compiled by the build process of the consuming application. Libraries should not read environment variables but receive their configuration from the application through some kind of initialization.
+
+# 🚀 Development
+
+## Principles
+
+- [Trunk Based Development](https://trunkbaseddevelopment.com) is used.
+- The `main` branch is the trunk and contains the latest version of the software that should be deployable to production at all times.
+- Changes to `main` automatically trigger a deployment to the staging environment.
+- Production deployments are triggered by merging the `main` branch into the `production` branch.
+- Changes are developed in short-living feature branches that are based on and merged back into `main`.
+- Both `main` and `production` should only contain commits with deployable versions of the software so that each commit actually represents a past deployment and rollbacks can be done by deploying any previous commit. Therefore, commits should always be squashed when merged to keep intermediate states out of the history.
+- `production` should never be changed manually and never backmerged into `main`. Emergency hotfixing can be done by cherry-picking changes from `main` into `production`.
+- Feature branches should be short-living to accelerate lead time and to receive early feedback. It is better to integrate even unfinished changes in a disabled state (e.g. commented out) than to delay integration and risk complex merge conflicts.
+
+## Setup
+
+How to set up a local development environment:
+
+- Install [Node.js](https://nodejs.org)
+- Install dependencies:
+  ```sh
+  npm install
+  ```
+- Copy [`.env.example`](./.env.example) to `.env` and set up local environment variables:
+  ```sh
+  cp .env.example .env
+  ```
+
+## Develop
+
+How to develop and debug changes locally:
+
+- Start local development servers:
+  ```sh
+  npm run dev
+  ```
+
+## Build
+
+How to create a local production build:
+
+- To create a production build, run:
+  ```sh
+  npm run build
+  ```
+- To start the production build locally using `.env` environment variables:
+  ```sh
+  npm start
+  ```
+
+## Test
+
+How to run automated tests locally:
+
+- Run tests:
+  ```sh
+  npm run test
+  ```
+- Run linting:
+  ```sh
+  npm run lint
+  ```
+
+## Integrate into staging
+
+How to develop changes and integrate them:
+
+- Create a feature branch `feature/...` based on `main`
+- Commit changes
+- Rebase onto `main` to receive latest changes
+- Create a pull/merge request `feature/... -> main`
+- Ask for a review and await approval
+- Squash, merge and close the request
+- Check `staging` environment deployment pipeline
+
+## Release to production
+
+How to create a production release:
+
+- Create a pull/merge request `main -> production`
+  - For emergency hotfixes: Create the pull/merge request by cherry-picking just the specific commit with the emergency changes from `main`
+- Ask for a review and await approval
+- Squash, merge and close the request
+- Check `production` environment deployment pipeline
+
+## Recurring maintenance
+
+Things to do on a regular basis:
+
+- Upgrade vulnerable package dependencies to receive latest security updates:
+  ```sh
+  npm audit
+  npm audit fix
+  ```
+
+# 🛰️ Operations
+
+## Principles
+
+- Establish observability by collecting and processing [telemetry data](https://opentelemetry.io/docs/concepts/observability-primer).
+- Define alerting conditions that require human intervention.
+- Schedule on-call shifts for responders and set up a notification system to alert them.
+- Document diagnosis and mitigation procedures in runbooks.
+- Learn from failures by doing [postmortems](https://sre.google/workbook/postmortem-culture).
+
+## Monitoring
+
+## Alerting
+
+## Incident Response
+
+- Assess and document the impact and severity of the incident.
+- Use [runbooks/](runbooks/) to diagnose and resolve the incident.
+- Identify follow-up improvements (e.g. development tasks, runbook improvements).