This change improves this area a bit by consolidating the matcher implementations between the benchmarks project and the conformance tests. Additionally I split the minimal matcher into a really trivial implementation for the simple tests and a more complex one for the larger tests. This allows us to keep the plaintext/techempower scenario in sight while also having a good baseline for the more sophisticated tests. Also starting to add tests that verify that matchers behave as expected. The matchers now successfully execute all of these benchmarks, which means that they support literals and parameters. Missing features: - complex segments - catchall - default values - optional parameters - constraints - complex segments with file extensions This is a good place to iterate a bit more of perf and try to make a decision about what we want to implement. |
||
|---|---|---|
| .. | ||
| Program.cs | ||
| README.md | ||
| RouteEntry.cs | ||
| Swaggatherer.csproj | ||
| SwaggathererApplication.cs | ||
| Template.cs | ||
README.md
Swaggatherer (Swagger + Gatherer)
This is a cli tool that can generate a routing benchmark using a Swagger 2.0 spec as an input.
Usage
Generate a benchmark from a swagger file:
dotnet run -- -i swagger.json -o MyGeneratedBenchark.generated.cs
Generate a benchmark from a directory of swagger files:
dotnet run -- -d /some/directory -o MyGeneratedBenchark.generated.cs
The directory mode will recursively search for .json files.
Resources
A big repository of swagger docs: https://github.com/APIs-guru/openapi-directory Swagger editor + yaml <-> json conversion tool: https://editor2.swagger.io Azure's official swagger docs: https://github.com/Azure/azure-rest-api-specs