quii/mockingjay-server-two

mockingjay-server-two's Issues

Add endpoint to config server to show requests received

Web UI to manage mockingjay

Try using HTMLX

https://htmx.org/docs/#introduction

Acceptance criteria

HTML equivalents for all endpoints

• View Configuration
• View match reports
• View specific report
• Form to add endpoint (the driver should use this in Configure rather than the HTTP API)
• Form to delete endpoint
• Form to edit endpoint

## TODOS

• Verify data in the table is correct
• Details/Summary for large bodies
• Sort by path

Consumer driven contracts: Exact matching

https://jsonplaceholder.typicode.com/todos/1

In MJ1, one passed the URL into the server and it would run it against all paths. Instead, I think this should be an "extra" configuration the consumer provides. If they wish to run in different environments, they can provide different configurations, all managed through CUE. I should show an example of this.

Also, let's give the format some scope for other configurations, so something like

CDCs: [
 URL: "https://example.com"
 Retries: 5
 TimeoutMS: 5000
 other-things-i-havent-thought-of
]

And if I think of other stuff, then it can be added.

Use case

Given an endpoint
**When a server at a URL responds to the same endpoint.request with endpoint.response
Then it passes the CDC

Further permutations basically vary the responses (e.g, body matching, regex stuff, etc)

I think a happy path test at the acceptance level can spin up an ad-hoc httptest.Server to let it pass, but all the other permutations I think will be much easier locally. Or maybe MJ itself can be used as a fake server... for the CDC...

cdc_fixtures: [
    local_endpoint: endpoint
    downstream_endpoint: endpoint ]

Match on incoming request JSON structure, rather than exact body

Spike CUE as a config tool

ADR here: https://github.com/quii/mockingjay-server-two/blob/main/doc/architecture/decisions/0002-use-cue-and-define-mj-config-format.md

Consumer driven contracts: JSON structural matching

Create custom flags parser so we can have a server config defined in cue

See https://github.com/peterbourgon/ff

Launch MJ with endpoints defined from config file

Idea: Configure as a "generic in-memory crud"

Configuration could have a CRUD flag, along with an example payload and path

crud: true
path: /people
payload: """
{"name":"Chris", etc
"""

And then MJ gives you an in-memory crud?

Do example mapping

Generate examples, rules and questions

Examples should feed in to acceptance criteria

HTTP API to configure fake server that returns canned responses

Try using https://docs.hofstadter.io/getting-started/code-generation/ for generating types from cue, for fun

Rules to implement

• Request path must match
• Method must match
• Header must include whatever was defined
• Regex path matching
• All incoming requests recorded