-
Notifications
You must be signed in to change notification settings - Fork 15
Handover notes Yannick Meine 2020 06 24
Kassette is a proxy and handles HTTP messages and other pieces of content between different parties.
As a proxy, some data needs to be inspected, but some also needs to be changed. For now, the inspection is full (reading input request, backend response, mock content, etc.), but the alteration is limited and/or not handy in some cases.
The idea would be to have a common, consistent way of changing a piece of data for a given target.
It would be good to still be able to inspect both the original data and the new one, and just use the new one for the target.
Here are the various pieces of data/paths I identified without elaborated specifications:
- request from client to proxy
- request from proxy to backend:
- response from backend to proxy
- response from proxy to client
- client request to file system (debug)
- proxy request to file system (debug)
- backend response to file system (mock)
- mock to response for client
Note that it might not make sense sometimes to be able to change any data, like for instance the request forwarded to a backend: the application is supposed to work as is without Kassette, so only the base URL should have to be changed (that's why only that can be changed for now).
I don't know to which extent it is feasible without making any assumption on a specific usage of Kassette.
One thing I could be thinking of is for instance: hide basic authentification header which comes from the client. The client request (and forwarded request) gets dumped on the file system for debug purposes.
For now the configuration hook catches all requests, any method, and that means it's possible to support CORS by adding proper headers when needed, and by "manually" handling pre-flight requests.
But that is cumbersome and a built-in option could be nice as well. Otherwise, at least a good piece of documentation would be good.
Maybe use winstonjs/winston instead for logging, and redefine the strategy:
- all in one files or still in separate files?
- what metadata to add? (process name, timestamp, etc.)
- how to visualize the logs in a nice way? (a log viewer differentiating the processes would be perfect)
For now, I test using Playwright's Chromium browser as the client, to be as close as possible to real situations. However, that is maybe not so valuable and getting rid of it could simplify testing a lot.
On the other hand, maybe some HTTP clients have specific things which we don't think about, and it could be nice to be able to test any client (cURL, Node.js, request, node-fetch, etc.)
If keeping the browser client, adding a CLI option to be able to run the tests with a non-headless browser and to keep it open at the end for inspection of the network activity could be nice.
For no e2e testing is based on inversion of control and is not intuitive (compared to a classic test authoring). It is mainly due to historical reasons.
What would be very nice is to change that and instead give to the testing code an API to be able to launch Kassette with a specific configuration, and any number of backends with custom implementations.
Since I am concerned about performance issues then, I would suggest to make it in a way that makes it possible to swap configurations/implementations on the fly:
- for a backend, just implement a way to override the callback to customize fully the backend, and keep its instance running across tests. Additional backends could still be created on the fly when exceptionally needed, at an extra cost in performances (but it is not happening often)
- for Kassette, maybe implement a way to reload a full configuration. That way, using the API, it would be possible to customize it fully for each test, which would be similar to what's done for the backend
Below are draw.io diagrams with data embedded in the URLs. You can open them and also choose to create a new diagram based on them.
- data workflow: incomplete
- e2e