The problem of storing draft state and auditing is not limited to noSQL databases, and as previously, below patterns can be applied to SQL modeling. But because noSQL databases are, in most cases, lacking transactionality over multiple partitions, the problem is harder there. Making it more interesting :) Additionally, smart use of neet features of noSQL databases allows for a novel solution.

The problem(s):

Problem 1: Storing temporary state

Most developers cringe when they hear about storing temporary state, but can’t imagine living without Save as draft in Gmail, or git stash :) Give the users what You expect. A different few use-cases :

  • The user can edit a document and save it as a draft. That draft can be later on committed or discarded.
  • UI flow requires a page reload when working on a single object. I know that we have SPA applications now, but not everywhere and we might be switching between different systems, or refactoring a legacy system.
  • Our document validation logic is quite complex, requires external HTTP calls, takes a long time to execute, and sometimes requires retries. Since we are good developers, we don’t run that logic during saving but save as draft, schedule a background task to do the validation. If something fails, we notify the user - a good UX.
Continue reading...

Querying hierarchical data is always where the big boys of SQL shined. And I really mean the big boys part since only Oracle, and Microsoft SQL Server have support for CTE [As Thomas Levesque pointed out in the comments, not only those have support for CTE. Full list on wikipedia] (Common Table Expressions) that allow for executing one SQL statement what will fetch a subtree. There are data modeling approaches that allow for doing hierarchical data reads with noSQL databases and databases without support for CTE.

Continue reading...

So, Yes. I hit a pause button on writing because many things were happening, and as it turns out, you can only squeeze 24 hours in one day. Who knew? However (hopefully) my blog will come back to life. One of the things that kept me busy during this time was realizing one of my goals:

Make a video course for Pluralsight.

And I made it:

Continue reading...

As I wrote in the previous post there are two ways to run precompiled .NET code in Azure Functions - .NET 4.6.x or .NET Core. Why did I decide to go with the old .NET runtime? For the current moment, F# on .NET Core does not support type providers (there is a workaround, but I didn’t want to go with it for the current moment). I went to work thinking that it will be a breeze. Just attach the repo and keep on coding. It turned out that I learned more Azure Functions troubleshooting and below is the shortened version.

Continue reading...

Trying to understand how to run code in Azure Functions is not an easy task since this product has evolved on its own and thanks to the rise of .NET Core. This post will give You a history background necessary to understand the documentation and, most of all, all the blog posts talking about Azure Functions.

Continue reading...