Know before you deploy.
Integration testing for microservices, without the test environment. Each service declares, in a YAML file, what it provides and what it reads. Bidirekt compares the files and tells you which service your deploy breaks and how to fix it. No running services, no end-to-end suite.
$ curl -sL bidirekt.com/demo | shRuns the petstore example locally with Docker. Self-hosted broker, single Go binary.
Live contract check
$ bidirekt can-i-deploy petstore_web --version 2.3.1 --environment production petstore_web 2.3.1 cannot be deployed to production petstore_api (1.4.0, deployed): Pet.status — petstore_web reads it, but petstore_api doesn't provide it → petstore_web: stop reading it, or handle its absence in the code and mark it optional → petstore_api: provide it · GET /pets/* response 200 at "$.status" Pet.weight — petstore_web reads it as string, but petstore_api provides integer → petstore_web: read it as integer → petstore_api: provide it as string there · GET /pets/* response 200 at "$.weight" (petstore_api: Pet.weight)
Drop the end-to-end environment
End-to-end integration tests need every service up, in the right versions, with the right data, and when they fail they tell you only that something broke. Bidirekt checks the same integrations from the files alone. This is contract testing, in both directions: the consumer can't read what the provider doesn't send, and the provider can't drop what a consumer still reads.
| End-to-end integration tests | Bidirekt | |
|---|---|---|
| What has to run | Every service, a database, seed data | Nothing: one YAML file per service |
| How long | Minutes, often flaky | Seconds, same answer every time |
| When it fails | A timeout or a 500 somewhere | The field, the side and the fix for each side |
| When you find out | After deploying to a shared environment | Before the deploy, as a CI gate |
Both sides write the same file
Other bi-directional setups compare two different artefacts: an OpenAPI document on the provider side and contract files generated from mocks on the consumer side. In Bidirekt the provider and the consumer write the same YAML format, so there is one thing to learn, review and keep honest.
Three commands in your pipeline
Publish the contract, ask before you deploy, record what shipped. The exit code of can-i-deploy is the gate in CI.
$ bidirekt publish ./contracts/*.yaml --participant petstore_web --version 2.3.1 Broker: http://localhost:18090 (profile: default) petstore_web contract publish successful
The same three lines in any CI
- run: bidirekt publish ./contracts/*.yaml --participant petstore_web --version $SHA - run: bidirekt can-i-deploy petstore_web --version $SHA --environment production - run: ./deploy.sh - run: bidirekt record-deployment petstore_web --version $SHA --environment production
See it catch a break on your machine
One command runs the petstore example with Docker: a breaking change, can-i-deploy catching it, and the fix, step by step.
$ curl -sL bidirekt.com/demo | shPrefer not to pipe to sh? Read the script, or:
$ git clone https://github.com/bidirekt/petstore-example $ cd petstore-example && ./demo.sh
Questions
- Do I have to rewrite my OpenAPI spec?
- No. Your OpenAPI document stays as it is. The Bidirekt contract is a separate, smaller YAML file: only the endpoints and fields each side actually uses, in the same format on both sides. It is not generated from OpenAPI today.
- How do I keep the YAML honest with the real code?
- Generate it from the code instead of writing it by hand. The Bidirekt agent skill reads your service and writes its contract files, and fixes them from a can-i-deploy report.
- Do I need to host the broker?
- Yes, it is self-hosted: one Docker image and a Postgres database. It has no authentication yet, so keep it on a private network or behind a proxy that controls who gets in.