A small, heavily commented backend that demonstrates good practice when building with the Causa framework. It is a teaching example: the point is not the business logic (a tiny online bookshop) but the patterns: event-driven and architecture principles, infrastructure, coding (TypeScript) guidelines around the Causa runtime, etc.
What is Causa? A convention-driven framework and CLI (cs) for event-driven backends. A workspace is a monorepo of projects, each configured through causa.*.yaml files that merge from the root down. Causa reads that configuration plus a shared data model (entities, events, DTOs, and storage schemas written as JSON Schema) to generate code, wire cloud infrastructure, and drive the build / test / deploy lifecycle. Its capabilities are extended by workspace modules (npm packages) for a given technology stack.
Stack demonstrated here. TypeScript NestJS service containers on Cloud Run, Cloud Spanner and Firestore for storage, Pub/Sub for events, and Terraform for infrastructure — all on Google Cloud.
- Install the Causa CLI so that you can run Causa commands against this project or yours.
- Browse the patterns to see what this repository demonstrates. Each pattern has a dedicated page under
patterns/. - Look at other Causa repositories to check what technology stacks are supported.
- 🌐 domains/: The code and infrastructure for each domain.
- 🧱 infrastructure/: The base infrastructure for the each backend environment, and the infrastructure for the
commonproject, which stores build artefacts for instance. - 📝 patterns/: The patterns this repository demonstrates, each with a dedicated page.
- The business model is incomplete. The point is to define just enough to demonstrate the patterns.
- Even within the defined model, the implementation is not complete. The ordering service is guaranteed to build and pass tests. The catalog domain is modelled but not implemented.
- Only the architecture documented within a pattern should be used as reference. Some parts of the modelling may only serve a specific demonstration purpose and should not be considered as a guideline for architecture (for example, they may disregard eventual consistency constraints, expose an inconvenient API, etc).
- Most comments are written to explain the patterns and the reasoning. When applying the patterns to your own codebase, you may not need to repeat the same comments. Focus on your own business logic and non-obvious technical aspects.