Anthony Chu

The default user accounts in Azure API Management don't store a lot of data about the user; they mostly just store a name and an email address. But what if we want to store more information about each user and pass it along to the backend API?

In this article, we'll store additional information about our API Management users in a Cosmos DB collection. When our API is called, we'll query Cosmos DB for the user data using an API Management policy and pass this information to the backend via an HTTP header.

In addition, we'll leverage the API Management value cache to prevent calling Cosmos DB on every request.

When I was working on a Logic App to save email attachments to Blob Storage, I ran into an error:

InvalidTemplate. Unable to process template language expressions in action 'Create_blob' inputs at line '1' and column '2656': 'The template language function 'base64ToBinary' expects its parameter to be a string. The provided value is of type 'Null'. Please see https://aka.ms/logicexpressions#base64ToBinary for usage details.'.

Visual Studio Team Services does not currently render external CSS files for coverage results. Code coverage reports generated by tools such as Cobertura do not have styles visible when viewed in VSTS.

According to this GitHub issue, the styles and scripts are removed because of potential security issues. We can partially get around this by inlining styles into our reports.

When transitioning to Cosmos DB (formerly DocumentDB), a common misconception is that collections are equivalent to tables in relational databases.

The guidance for Cosmos DB is actually to store multiple types of entities with different schemas in the same collection. The main reason for this is that documents in the same DocumentDB collection can participate in transactions (via stored procedures).

While applications using Cosmos DB's MongoDB API don't really take advantage of transactions, there's still a huge reason for using a single collection for multiple entity types... to save money. Cosmos DB charges per collection.

In this article, we'll take a look at using discriminators in Mongoose (a popular MongoDB library for Node.js) to store multiple entities in a single Cosmos DB collection.

Kubernetes and Visual Studio Team Services are my two favorite things to hack on these days. Today we'll look at how to run VSTS private build agents in Kubernetes.

Why run VSTS agents in Kubernetes?

Save money

One reason we might want to run VSTS agents in Kubernetes is to save costs. Each VSTS account comes with 240 build minutes per month. After they're used up, we have to pay $40. That isn't a lot. But if we're running a Kubernetes cluster anyway, it might be advantageous to run our own VSTS agents on there.

In the past, it was difficult to set up and maintain agent machines. But now VSTS agents can run as Docker containers; this makes it really simple to run them in Kubernetes.

Run tests on services not accessible by VSTS hosted agents

Another reason to run VSTS agents in Kubernetes is to make it possible to run integration and functional tests on services in the cluster that do not have a public endpoint. This is the scenario we'll talk about today.

Services in Kubernetes can be exposed directly through a load balancer or via an ingress. But other services such as those of type ClusterIP are not reachable from the public internet and are difficult to test from a cloud service like VSTS.