-
The first task can be seen in tree.go and tree_test.go for the test.
-
The second task can be seen in sequence.go and sequence_test.go for the test.
-
The third task can be seen in schema
-
The fourth task is in this entire repository.
Read Assumptions
The API documentation can be seen in proto files (*.proto
) in directory proto.
The API is automatically generated in OpenAPIv2 format when generating gRPC codes.
The generated files are stored in directory openapiv2 in JSON format (*.json
).
To see the RESTful API documentation, do the following:
- Open the generated json file(s), such as spenmo.swagger.json
- Copy the content
- Open https://editor.swagger.io/
- Paste the content in https://editor.swagger.io/
- For complete prerequisites, read Prerequisites. Otherwise, for example, you prefer running the service using docker, then skip this step.
- Then, read How to Run.
- Read Code Map.
- Read Design Pattern.
$ make test.unit
godog is mandatory to perform integration test.
To run the integration test, make sure you already run the application successfully. Follow How to Run for the guideline, including performing database migration to setup and seed the database.
The integration test doesn't focus on testing the rate limit functionality. It only focuses on whether the API can perform the job well.
Therefore, please adjust the rate limit configuration to accept many requests.
RATE_LIMIT_PER_SECOND=100
and RATE_BURST_PER_SECOND=100
should suffice.
When application is running, then run command to execute integration test.
$ make test.integration
You can also set the server URL, in case your default server is not localhost.
$ SERVER_URL=http://spenmo:8081/v1/users/cards make test.integration
The application already emits necessary telemetry. If application's dependencies are run using docker compose, then monitoring is provided by default. Otherwise, you have to provide them.
The observability is implemented at the handler/controller level. So, every request will be observed. For example, there will be four golden signals (throughput, latency, error rate, and saturation), traces, and logs for each endpoint. If needed, we can implement custom monitoring on block of code we need to observe.
These are stacks used as monitoring system.
Observability | Stack | Address |
---|---|---|
Metrics | Prometheus | http://localhost:9090 |
Visualization | Grafana | http://localhost:3000 |
Tracing | Jaeger | http://localhost:16686 |
Log | Zap | Stdout |
Visit OBSERVABILITY for observability result example.