We want to apply query parameters for collections returned by OpenApi:
limit, offset, page filter, fields, sort
As a return, we'll get response with data, meta where meta consists of limit, skipped, total.
During our investigation we referred another ADR: #39
Decision
We focused on a database where we had to find the one that will suite our use cases. After an endpoint receive query parameters we can easily pass it further to a service communicating with a database. It won't require as to build a custom translator to prepare a query to a database.
Because of cost efficiency (serverless) and speed of development we've chosen Document DB - Azure Cosmos DB API for MongoDB. It looks like it has everything we need with a good back up plan. The implementation is quite straightforward and doesn't require a deep knowledge to read and understand the code.
Consequences
A training needed for building proper document databases.
Alternatives
Relational DB - Azure SQL Server with EntityFramework with IQueryable
For EF will it be quite straight forward where you can build a query in .NET.
good capability for querying and filtering
expensive for a little microservice
Consequences: we're forced to use EntityFramework with all its advantages and tradeoffs.
Dapper with Linq extensions
Pure Dapper is invented for those who loves their sql. That's why there won't be any support for Linq or Querable. But there can be found extensions that could translate it to query.
Remember that ADRs are publicly available hence do not include any confidential information in the issue description!
To read more about ADR please refer to documentation.
Context
We want to apply query parameters for collections returned by OpenApi:
limit, offset, page filter, fields, sort
As a return, we'll get response with
data, meta
wheremeta
consists oflimit, skipped, total
.During our investigation we referred another ADR: #39
Decision
We focused on a database where we had to find the one that will suite our use cases. After an endpoint receive query parameters we can easily pass it further to a service communicating with a database. It won't require as to build a custom translator to prepare a query to a database.
Because of cost efficiency (serverless) and speed of development we've chosen Document DB - Azure Cosmos DB API for MongoDB. It looks like it has everything we need with a good back up plan. The implementation is quite straightforward and doesn't require a deep knowledge to read and understand the code.
Consequences
A training needed for building proper document databases.
Alternatives
Relational DB - Azure SQL Server with EntityFramework with IQueryable
For EF will it be quite straight forward where you can build a query in .NET.
Consequences: we're forced to use EntityFramework with all its advantages and tradeoffs.
Dapper with Linq extensions
Pure Dapper is invented for those who loves their sql. That's why there won't be any support for Linq or Querable. But there can be found extensions that could translate it to query.
Document DB - Azure Cosmos DB API for MongoDB