CosmosDB REPL console app

There are a few ways you can explore your data in CosmosDB, either via the Azure Portal or with the Azure CosmosDB Graph Explorer - here. However, I wanted a quicker way that I can run queries and check results and performance locally so I created a console app that allows you to do just that.

Read More

Share Comments

CosmosDB Query with Partition

ComsosDB is the first database system that promises <10ms latency on reads at the 99 percentile, and backs it up by an SLA. The way to achieve that performance though is though smart partitioning of your data. Here are a couple of notes that you can use when designing your queries that will definitely help improve performance - especially in an unlimited collection (one with multiple physical partitions)

Read More

Share Comments

CosmosDB with Gremlin.NET - part 2

On top of being faster than the original client, the Gremlin.NET native driver comes with a couple more features that make it really appealing to use: Fluent API and Query Bindings

Read More

Share Comments

CosmosDB Graph using Gremlin.NET

Up until recently, the only way to communicate with the CosmosDB Graph API was though the DocDB Graph Client - Microsoft.Azure.Graph . Like I mentioned in some of my older posts that was not the most optimal implementation.
Luckily we can now use a native Gremlin driver to communicate with the CosmosDB graph database. Gremlin.NET is an open source generic Gremlin driver that can be used to communicate to a CosmosDB Graph account.

Read More

Share Comments

Protecting a web-app with AzureAD

Deploying a web application on azure is incredibly easy these days. You can handle everything, including creating a whole new web app and app service directly from Visual Studio. A lot of times we deploy these small web apps as internal tools for our team or company but we must not forget about securing those behind a log-in so that they are not accessible to anyone trying out domains at azurewebsites.net

Read More

Share Comments

Azure CosmosDB Graph Explorer

Azure CosmosDB Graph Explorer is a great opensource tool that allows you to easily and quickly visualize the data you have in your Azure CosmosDB Graph (yes, just graph at the moment).

Read More

Share Comments

ServiceFabric RemotingTransport settings in ASPNET Core project

When wirting a Service Fabric Service that uses the Remoting Transport layer, you sometimes need to update the default settings to allow for a greater message size or operation timeout.

According to the documentation, this is achieved by overriding the default settings in the Assembly manifest file that you find under Properties/AssemblyInfo.cs

1
2
3
using Microsoft.ServiceFabric.Services.Remoting.FabricTransport;
// Allow messages up to 100 MB, operation timeout to 10m
[assembly: FabricTransportServiceRemotingProvider(MaxMessageSize = 100000000, OperationTimeoutInSeconds = 6000)]

However, you might notice that if you created an ASPNET Core service (to use as a gateway perhaps), the new project type does not have the AssemblyInfo.cs file anymore. Even more, if you create it yourself, it will be ignored.

This is happening because in the new ASPNET CORE project type, the AssemblyInfo file is auto-generated during build. Since there’s no other way (as far as I could find) to update our remoting settings, we need to get rid of the auto-generated file and write our own.

First, create your own AssemblyInfo.cs file under the Properties folder.
Next, find the auto-generated file in the obj folder. Copy its contents over into your newly created file.
Lastly, we need to instruct the build system to not generate the file automatically any more.
We do this by updating the project file:

1
2
3
<PropertyGroup>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>

That’s it, with these changes, you now have the new remoting settings available for your ASPNET CORE project.

Share Comments

CosmosDB graph formats

When working with CosmosDB GraphAPI it helps to understand how the engine stores or manipulates the inputs, so I will try to explain the data formats.

Read More

Share Comments

Mixing Gremlin with DocDB API in CosmosDB

One of the best things about CosomosDB is the ability to mix and match APIs and models based on what makes sense for your use case.

Sometimes it just makes sense that your database is built as a graph, and in that case you can use the (familiar) Gremlin language to write your queries. However, for some things it might be easier or more optimal to use familiar DocDB APIs.

Read More

Share Comments

CosmosDB Graph Read optimization with ReadDocument

One of the interesting things that caught my eye in the newly released 0.3.0-preview SDK was the .limit() step optimization.
Like we saw in one of my older posts, limit() was executed client side, so you’d get the entire result set from the server and the client side sdk would filter and return it back to caller.

Read More

Share Comments