5 ms·

Beware of the REST API of Cosmos. We fell into the trap of using it.. 1) it is not covered by the latency SLA. This is buried pretty deep... 2) suddenly you g

by dagss 8y ago

Beware of the REST API of Cosmos. We fell into the trap of using it.. 1) it is not covered by the latency SLA. This is buried pretty deep... 2) suddenly you get magical responses that are supposed to trigger the client to do something (e.g. sql qyeries with order by requires some algorithm client side). These things are not docoumented anywhere, you have to read the Node or Python client libs.. Using Cosmos mainly requires being on .NET and using the official driver that communicates over a closed undocumented binary protocol. (even the Java driver having the full SLAs and using the binary protocol was launched just weeks ago). IMO it would have been less misleading if MS had just removed the docs for their REST API. Or at least put up a big warning about it being an undocumented afterthought.

Vulkum 7y ago
In general I have issues with the Azure documentation. I can't put my finger on it as to why, but for some reason the information doesn't seem to be presented in coherent ways, it's often disconnected and gets outdated very quickly. I can't speak as to the performance of the drivers (in general using the database drivers or a gRPC/thrift equivalent should be better than REST), but I agree with the lack of SLAs. The lack of SLAs in the documentation is one of the major issues we've had when assessing the suitability of Azure managed services (e.g. Postgres, Cosmos DB, Bus, Event Hubs, etc.). To Azure's defence (not sure I should be doing this), a lot of these services are new and they are made available before they are operationally ready. For example, I was looking at the SQL warehouse offering a few months back [0] and if you want to use it you'd have manually maintain the statistics of the DB to keep the query plans optimised. It just seems like more overhead than necessary. [0] https://docs.microsoft.com/en-us/azure/sql-data-warehouse/sql-data-warehouse-best-practices?fbclid=IwAR1lWHSodX1vsX1-wioZUeV2R7yUmlBWQ6Br8-XVXWYBmgwYEKYdt-kRZ6g https://docs.microsoft.com/en-us/azure/sql-data-warehouse/sq...
kirillg_hn 8y ago
Hi, I am from Cosmos DB engineering team, Cosmos DB offers Java, Javascript, Python, and .NET drivers. Just like with most databases, it is recommended for applications to use drivers to work with Cosmos DB. Cosmos DB offers REST API to work with data, documented at [1]. The primary focus of the REST API is SDK developers for platforms where we do not provide drivers yet. Just like most databases, we recommend to use provided drivers where available. This REST API is not intended for broad consumption by the apps. Your point about being more explicit about scenario the REST API is intended for and supported for is well taken. We will improve the documentation. [1] https://docs.microsoft.com/en-us/rest/api/cosmos-db/ https://docs.microsoft.com/en-us/rest/api/cosmos-db/ thanks for feedback!
- dagss 7y ago
  Even in this reply, you fail to mention that JavaScript and Python (and the old Java) drivers uses another protocol for which the latency SLA does not hold! That information is vital. And it looks as though you are correcting me, when you are not. This kind of attitude (throughout documentation) is my exact issue -- MS is always about selling, always hiding critical info, at the expense of helping engineers take the right choices.

by dagss 8y ago

Vulkum 7y ago

In general I have issues with the Azure documentation. I can't put my finger on it as to why, but for some reason the information doesn't seem to be presented in coherent ways, it's often disconnected and gets outdated very quickly. I can't speak as to the performance of the drivers (in general using the database drivers or a gRPC/thrift equivalent should be better than REST), but I agree with the lack of SLAs. The lack of SLAs in the documentation is one of the major issues we've had when assessing the suitability of Azure managed services (e.g. Postgres, Cosmos DB, Bus, Event Hubs, etc.). To Azure's defence (not sure I should be doing this), a lot of these services are new and they are made available before they are operationally ready. For example, I was looking at the SQL warehouse offering a few months back [0] and if you want to use it you'd have manually maintain the statistics of the DB to keep the query plans optimised. It just seems like more overhead than necessary. [0] https://docs.microsoft.com/en-us/azure/sql-data-warehouse/sql-data-warehouse-best-practices?fbclid=IwAR1lWHSodX1vsX1-wioZUeV2R7yUmlBWQ6Br8-XVXWYBmgwYEKYdt-kRZ6g https://docs.microsoft.com/en-us/azure/sql-data-warehouse/sq...

kirillg_hn 8y ago

Hi, I am from Cosmos DB engineering team, Cosmos DB offers Java, Javascript, Python, and .NET drivers. Just like with most databases, it is recommended for applications to use drivers to work with Cosmos DB. Cosmos DB offers REST API to work with data, documented at [1]. The primary focus of the REST API is SDK developers for platforms where we do not provide drivers yet. Just like most databases, we recommend to use provided drivers where available. This REST API is not intended for broad consumption by the apps. Your point about being more explicit about scenario the REST API is intended for and supported for is well taken. We will improve the documentation. [1] https://docs.microsoft.com/en-us/rest/api/cosmos-db/ https://docs.microsoft.com/en-us/rest/api/cosmos-db/ thanks for feedback!

dagss 7y ago
Even in this reply, you fail to mention that JavaScript and Python (and the old Java) drivers uses another protocol for which the latency SLA does not hold! That information is vital. And it looks as though you are correcting me, when you are not. This kind of attitude (throughout documentation) is my exact issue -- MS is always about selling, always hiding critical info, at the expense of helping engineers take the right choices.