Tweek Core Services
- Gateway - front facing endpoint serves web and api calls. Responsible for enforcing API Policies and forwarding requests to relevant microservices
- API - Tweek core engine, calculate values and read/write to context
- Editor - Client web app for editing Tweek keys, context, policies, etc…
- Authoring - REST API for editing Tweek keys definition, policies.
- Publishing - Git proxy, validates key/policies definition, create and upload keys/policies bundles to Minio and update Git upstream.
- Git - Storage for all keys data and policies
- Context DB - Store all identities’ context and key overrides (can be Redis/Couchbase/Mongodb)
- Minio/S3 - Object storage for policies/keys bundles
- Nats - pub/sub for sending updates on bundle updates
- OIDC provider/s - used to validate JWT tokens
- All blue components are Tweek services
Typical update key flow
- User browse the editor (via gateway url)
- User select a key, update and save it
- Editor send update request to gateway
- Gateway validate request and forward to authoring
- Authoring update the relevant key files and push to publishing
- Publishing run partial validation (complication, circular dependencies, etc…)
- Publishing update the git upstream
- Publishing create a new bundle of all keys and upload to object storage (Minio/s3)
- Publishing send nats update
- Api get notified by nats update
- Api download the latest bundle
- Api can now calculate values based on the new key definition.
We think on update a key as typical “code update flow”. we start by updating the key (which is represented by manifest and rules files), push to git. Publishing does validation and deployment of the new “code” and serve as the “CI/CD” pipeline. After the code was validated and the bundle was uploaded, the api service fetch the latest version.