So far, we have seen how to create a DocumentDB database, collections and documents. Now that we have saved data in DocumentDB, we need means to interact with it from outside. May be through an application that integrates with DocumentDB to retrieve and create documents. Such integrations that happen on the client such as an application are called as Client-side integrations.
Document DB offers a couple of options to interact using REST/HTTP API or SDK. REST API can be used just like any other REST API by making a HTTP request to the resource and providing valid authentication in the header. SDK’s are available for most platforms, you can download the SDK for .Net from NuGet.
Integrate with DocumentDB using .Net and C# SDK
First step is to establish connection with DocumentDB, and for that we will need an endpoint and a key. The endpoint is the URL to the DocumentDB account, which has the form of https://accountname.documents.azure.com. The key contains your credentials to DocumentDB. There are two types of keys, master key and resource tokens. The master key grants total access to DocumentDB and you can do pretty much anything with it. You can think of it as the ‘sa’ account in the SQL Server world. It provides full access to the entire DocumentDB account and should not be distributed to end user machines. Resource tokens are based on user permissions and can only access specific resources.
Open Visual Studio 2017, create a project, install DocumentDB .Net SDK from NuGet. In your code,
Create an instance of DocumentClient by supplying an endpoint and a key. Once you have an instance, you can invoke methods to access DocumentDB resources. At this point, you can create, modify, and delete databases, collections, documents, and other resources.
To execute a Stored Procedure, click Script Explorer, pick the stored procedure and click ‘Save & Execute’.
User Defined Functions
In today’s digital world, we need enterprise level applications that work on web, mobile, Internet of Things (IoT), etc. And we need these applications to run faster and at greater scale. NoSQL fits the bill and is increasingly the preferred database to power up big enterprise level applications. Having said that, NoSQL is not as robust as SQL and does some compromise on ACID properties, so take it with a grain of salt. Also, it is very common for NoSQL and SQL to co-exists, making available the best of both worlds.
Hope you enjoyed reading my multi-series blog on NoSQL. Thanks all.