For this monthly suggestion, we are going with a small load testing tool. We will need to create and consume APIs. A repository layer is a must and we have to use the concurrency provided by our chosen language.
As with most applications, the initial scope will probably increase. Regardless of how far you want to take this implementation, the mandatory must-have are:
- To have a repository layer. It can be whatever you feel comfortable with. Any relational database, NoSQL solution or even plain files will do the trick.
- To build REST APIs for CRUD operations for endpoint configurations and to retrieve load tests results.
- To handle a load test up to 200 requests/minute. While this limit is not very high, it will serve as a solid base for your load testing needs. I highly recommend using mock endpoints for your tests.
- To work with HTTP GET and HTTP POST endpoints. Most APIs are of those two flavours and we are trying to limit our application and focus on delivering.
Having the basics covered, there are many more nice-to-have improvements we can add to make this usable outside of a onetime experiment. Out of all the optional features you can add, some suitable next steps are:
- Keep a maximum number of 10 load test results per endpoint configuration. This will add some business logic and it will also help us keep our repository small.
- Find a way to snapshot the initial configuration for each endpoint. We want to make it clear what configuration we associate with which results.
- Provide a REST API to run a comparison between runs. How do the latest load test results compare to the previous run?
- Add a REST API to compare results between endpoints. Is the QA version of an endpoint faster than the Live version?