Backend for Frontend (BFF) is a pattern that creates a dedicated backend service for each frontend (e.g., web, mobile) to better optimize API responses, enhance security, and streamline communication between frontends and backend services. In this context, using YARP (Yet Another Reverse Proxy) and Docker can significantly improve routing, scalability, and service orchestration.

Benefits of Combining YARP and Docker in BFF Architecture

1. Optimized API for Frontends: Each frontend gets a tailored API with BFF, ensuring optimized data delivery, reduced over-fetching, and under-fetching.
2. Separation of Concerns: BFF handles frontend-specific logic, while YARP manages request routing between multiple services.
3. Scalability and Flexibility: Docker enables each BFF or backend service to be containerized, making scaling easier.
4. Service Isolation and Deployment: Docker provides isolation of services, which can then be deployed consistently across various environments.
5. Routing and Load Balancing: YARP simplifies routing and load balancing between backend services, managed centrally through the BFF.

YARP for BFF

YARP is a customizable reverse proxy that helps in routing frontend requests to backend services. In a BFF architecture, YARP can route frontend requests to appropriate backend services while abstracting complex service interactions from the frontend.

YARP Configuration in BFF

1. Install YARP NuGet package:

   dotnet add package Microsoft.ReverseProxy --version 1.0.0
   

2. Set up YARP routing in appsettings.json:

   {
     "ReverseProxy": {
       "Routes": {
         "route1": {
           "ClusterId": "cluster1",
           "Match": {
             "Path": "/api/service1/{**catch-all}"
           }
         },
         "route2": {
           "ClusterId": "cluster2",
           "Match": {
             "Path": "/api/service2/{**catch-all}"
           }
         }
       },
       "Clusters": {
         "cluster1": {
           "Destinations": {
             "destination1": {
               "Address": "https://backend-service1/api/"
             }
           }
         },
         "cluster2": {
           "Destinations": {
             "destination2": {
               "Address": "https://backend-service2/api/"
             }
           }
         }
       }
     }
   }
   

3. Configure YARP in Startup.cs:

   public void ConfigureServices(IServiceCollection services)
   {
       services.AddReverseProxy()
               .LoadFromConfig(Configuration.GetSection("ReverseProxy"));
   }
   
   public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
   {
       app.UseRouting();
       app.UseEndpoints(endpoints =>
       {
           endpoints.MapReverseProxy();
       });
   }
   

In this setup, YARP efficiently routes requests based on the path patterns (e.g., /api/service1/* is routed to backend-service1, and /api/service2/* is routed to backend-service2).

Dockerizing the BFF

Docker provides a way to package the BFF and other backend services into isolated containers, making the deployment and orchestration of services more manageable and scalable.

Benefits of Dockerizing BFF and Backend Services:

1. Portability: Docker ensures that your services run consistently across different environments.
2. Isolation: Each service (BFF, backend services) is isolated, ensuring that they don't interfere with each other.
3. Scalability: Docker containers can be scaled independently using container orchestration platforms like Kubernetes.

Dockerfile for BFF:

1. Create a Dockerfile:

   # Use the official ASP.NET Core runtime as a base image
   FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
   WORKDIR /app
   EXPOSE 80
   
   # Use the SDK image for building the application
   FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
   WORKDIR /src
   COPY ["BFF/BFF.csproj", "BFF/"]
   RUN dotnet restore "BFF/BFF.csproj"
   COPY . .
   WORKDIR "/src/BFF"
   RUN dotnet build "BFF.csproj" -c Release -o /app/build
   
   FROM build AS publish
   RUN dotnet publish "BFF.csproj" -c Release -o /app/publish
   
   FROM base AS final
   WORKDIR /app
   COPY --from=publish /app/publish .
   ENTRYPOINT ["dotnet", "BFF.dll"]
   

2. Build the Docker Image:

   docker build -t bff-api .
   

3. Run the Docker Container:

   docker run -d -p 8080:80 --name bff-api-container bff-api
   

By containerizing the BFF, you enable consistent deployment and easy scaling across environments like development, staging, and production.

Docker Compose for Orchestrating Multiple Services

Docker Compose simplifies running multi-container applications, allowing you to define and manage all services (BFF, backend services) in a single file.

docker-compose.yml for BFF and Backend Services:

version: '3'
services:
  bff-api:
    image: bff-api
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8080:80"
    depends_on:
      - backend-service1
      - backend-service2

  backend-service1:
    image: backend-service1
    environment:
      - ASPNETCORE_ENVIRONMENT=Production
    ports:
      - "8081:80"

  backend-service2:
    image: backend-service2
    environment:
      - ASPNETCORE_ENVIRONMENT=Production
    ports:
      - "8082:80"

1. Run Docker Compose:

   docker-compose up --build
   

This command builds and runs the BFF and backend services as containers. Docker Compose simplifies orchestration by automatically starting all services, managing dependencies, and exposing the appropriate ports.

Bringing it All Together: YARP + Docker in BFF Architecture

1. Frontend Requests: Requests from different frontend applications (mobile, web) hit the BFF API.
2. YARP: The BFF uses YARP to route these requests to the appropriate backend services based on predefined routes.
3. Docker: The BFF and backend services run inside Docker containers, enabling scalable and consistent deployment across environments. Docker Compose helps orchestrate these services, ensuring smooth communication and interaction.
4. Scaling and Deployment: With Docker, you can easily scale services horizontally (adding more instances of the BFF or backend services) and deploy them to container orchestration platforms like Kubernetes or Azure Kubernetes Service (AKS).

Pros and Cons of YARP and Docker in BFF

Pros:

• Optimized for Frontend: BFF provides tailored APIs for each frontend, improving performance and reducing complexity.
• Scalability: Docker allows for easy scaling of individual services based on traffic.
• Centralized Routing: YARP efficiently handles routing and load balancing between backend services.
• Isolation and Portability: Docker ensures services are isolated and can run consistently in different environments.
• Simplified Deployment: Using Docker Compose simplifies the orchestration and deployment of multi-service applications.

Cons:

• Complexity: Adding YARP and Docker increases architectural complexity, especially when dealing with multiple services and deployment configurations.
• Overhead: Docker introduces additional resource overhead, and YARP might add latency due to its role as a proxy layer.
• Coordination Between Teams: Requires coordination between frontend, backend, and DevOps teams to ensure seamless integration and deployment.

Conclusion

Combining YARP and Docker in a Backend for Frontend (BFF) architecture provides a robust, flexible, and scalable solution. YARP simplifies request routing and load balancing, while Docker enables easy containerization, consistent deployments, and scaling across environments. Using Docker Compose further streamlines service orchestration, making it easier to manage and deploy multiple services. This setup allows for efficient handling of frontend-specific logic while keeping backend services isolated and scalable.

I started my public speaking journey about 3 years ago and I have learnt lots since then. In fact, before then I was really scared to speak in public. I'm not the most comfortable or proficient person on stage but things do get easier.

I remember the very first time I delivered a talk. It was about Angular Routing in one of the SSW Angular Hack Days. Since then I did multiple meetups, hackdays, trainings and conferences around the world.

I've heard a lot of people talking about public speaking and asking questions like what's involved? How to get started? Any tips? How is the process of putting together a talk? Do I need to be an expert on the subject? What about impostor syndrome? What if someone asks a question I don't know the answer, I'll feel stupid.

There are so many questions and so many doubts, and for someone who's in the comfort zone that will mean "I'm not speaking in public", "I'm not doing it", "Hell NO!!!".

I'll say it again: I'm far from being the most proficient person in public speaking but here are a few things that worked and still work for me:

How do I get started?

I started with lighting talks (15min) on subjects I was comfortable with and an audience I was familiar with. A great place to start is to propose a talk to one of the many meetups in your local area.

Do I need to be an expert on the subject?

I do NOT present only about things that I work on a daily basis or things I'm an expert about. In fact, a lot of times when I really want to push myself at learning about something, I put my head out and say I want to present about it, usually at local meetups. If they accept my talk then I start putting together the content and learn in the journey.

What about impostor syndrome?

That was a big thing for me when I started speaking. I was really scared to look dumb. I had this feeling that everyone in the room would know more than I did. But you know what, you don't need to pose as an expert in the field, you can be there to share something you are really excited about. You can be there to share YOUR unique experience and tell YOUR story. There's no better person at being you than you.

There is already so much content on 'x' why would anyone want to hear it from me?

That's probably similar to the previous question but I think it's worth emphasising this point a bit more. People come to your talk to hear YOUR point of view about what you're presenting so they can relate to YOUR story.

I have seen in the past super smart people, creator of amazing products/technology, presenting on what they have created and, to be honest, sometimes I rather hear the story from someone using the product/technology, because their pain points will probably align more to mine.

What if someone asks a question I don't know the answer to?

You'll never know everything. There's always going to be a time where someone asks something you don't know and it's fine not knowing the answer. There are a few ways you can get away with it. I try to go with the first one most of the time.

1. "Sorry, I don't know the answer. Is there anyone in the audience that knows about it?"
2. "Sorry, I don't know but I'll find out and come back to you about it."
3. "That's a great question but it's out of the scope of this talk, why don't you come and see me afterwards?" then you tell him/her you have no idea what he/she is talking about.

Do I get nervous before talks?

EVERY SINGLE TIME. It usually starts about 30 minutes before presenting and it escalates until the moment I say "Hi, my name is Thiago Passos" then I get into automatic mode.

Do I prepare the talk first then submit it?

That usually never happens unless it's not the first time I'm presenting it, otherwise, I only put together the title and abstract of a talk, if I do get accepted then I start preparing for the talk.

How do I put together a talk?

That's probably a whole topic on its own, but let's see.

Once I know roughly what the content of my talk is, I try to create a flow or a story that makes sense in my head. For example, if I were to talk about a new front-end framework, I would start with the requirements for installing and using it. Then I would talk about some features of the framework that I think are exciting. And finally, I would provide resources where the audience could go to find out more about it.

I usually split the talk into 3 to 5 major sections and I work on then separately, by doing that I can always come back to a section and make improvements. It's also easier to rehearse and time each section at a time instead of the whole talk. Once I'm happy with a section, I move on to the next one.

Here are some resources you might find useful for putting together your presentations: Slide:ology, Presentation Zen

How do I prepare for talks?

Once I have the content in place, like the slide deck or a demo, I start rehearsing for the talk and that will include my introduction, all sections and the closing of the talk.

I usually record each section individually and time them. Doing these rehearsals is where I fine tune each section. The talk is never going to be perfect the first time, or the second or the hundredth, but it will definitely improve every single time.

After I went through the talk multiple times, the talk is cemented in my brain and when I get in front of an audience, I almost turn into automatic mode.

Any Tips?

I saw this awesome thread on Twitter started by @kapehe_ok about "What are the 3 MUST KNOW things you would tell a first-time conference speaker?". I'll compile some of the responses here with some of the things I think are helpful.

• Rehearse twice as much as you think is enough. Practice out loud to get used to hearing your own voice
• Live demos can go wrong and will go wrong. Have a plan B: either record the demo and/or take screenshots through it.
• If your demo does fail, spend 30sec MAX fixing it then blame the demo gods
• The audience is on your side and they want you to succeed. Most of them would be terrified to be in your place and they respect that.
• It's OK to be nervous
• Breathe, pause, take your time. The pause in your head usually takes 10 times as much as it actually takes.
• Keep water within arms reach and drink it
• Find the nodders in the audience and make eye contact with them
• Pee before you go up
• Make sure you have all the necessary dongles and cables
• Do test runs with your colleagues/friends and ask for their feedback. Take the feedback and improve your talk then repeat.

I was accepted to speak at a conference! Now what?

Own it!!! You got it!!!

Hope that helps. I still have loads to learn, but don't we all?

Cheers

I started writing this blog post a very long time ago when I switched for the first time in my life to a Mac as my main computer. I was super excited to have the shiniest laptop in town and I was sure I could do all my work on it since most of what I did was .NET Core which is cross platform and front end development. So happy days!?!?!? Right? Not really!!!

I hit a massive road block, I found out that the tooling I needed to develop Azure Functions wasn't available for Mac and that was a deal breaker. Without the Storage Emulator, I could only run locally Azure Functions with HTTP triggers, and well within my solution that was the trigger I used the least.

I WAS SAD; I stopped using the Mac for Azure Functions development but life goes on and there's no looking back.

Time has passed and by accident I found out a community maintained open source storage emulator called Azurite. I was pumped and decided to give another chance for the Mac to be my main work machine again. So let's see how it goes.

First I installed Azurite by running sudo npm install -g azurite, once it was installed I kicked it off by simply running azurite-blob.

If you haven't installed the Azure Functions Core Tools yet, do follow the steps from the Microsoft docs.

I put together a super simple code just to prove a point and to be able to share here and to create a Function App I went to the terminal and ran:

mkdir FunctionsOnMac
cd FunctionsOnMac
func init --worker-runtime dotnet

I also created two functions: a timer trigger and service bus trigger as below:

func new -t TimerTrigger -n TimerTrigger
func new -t ServiceBusQueueTrigger -n ServiceBusTrigger

Then I updated my local.settings.json as below to use the storage emulator just as you would in a Windows machine using the official Storage Emulator:

For this example to work, it's required that you have an Azure Service Bus in place and a queue named temp. Also make sure you copy the service bus connection string and update the file below

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "AzureWebJobsDashboard": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet",
        "ServiceBusConnString": "[SERVICE BUSS CONN STRING]"
    }
}

The idea of my sample app is for the timer to send a message to the service bus every 10 seconds and the service bus function to pick up that message and print in the screen, as simple as that.

My timer function will look like this:

using System;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Host;
using Microsoft.Extensions.Logging;
using Microsoft.Azure.WebJobs.ServiceBus;

namespace FunctionsOnMac
{
    public static class TimerTrigger
    {
        [FunctionName(nameof(RunTimer))]
        public static void RunTimer(
            [TimerTrigger("*/10 * * * * *")]TimerInfo myTimer, ILogger log,
            [ServiceBus("temp",EntityType.Queue,
            Connection = "ServiceBusConnString")] 
            ICollector<string> messages)
        {
            log.LogInformation($"C# Timer trigger function executed");
            messages.Add($"Message sent from timer at {DateTime.Now}");
        }
    }
}

And my Service Bus function will look like the below:

using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Host;
using Microsoft.Extensions.Logging;

namespace FunctionsOnMac
{
    public static class ServiceBusTrigger
    {
        [FunctionName(nameof(RunServiceBus))]
        public static void RunServiceBus(
            [ServiceBusTrigger("temp", Connection = "ServiceBusConnString")]
            string message, 
            ILogger log){
                log.LogInformation($"Message Received: '{message}'");
        }
    }
}

Now when I go back to the terminal and run func start that's what I get:

Btw, if you do forget to run azurite-blob, you should be getting the below instead

Hoorey!!!! Happy days again!!! Let's wait for my next roadblock :D

Cheers

I've been using Redis for a while now and it just works, but I find particularly painful when I want to see what's cached without writing a custom tool for that. Another reason that drove me to try this solution was the fact that I'm paying too much for a Redis instance in Azure. So I thought I would give it a try and see how well Comos DB would perform in this situation.

The replacing process for me was actually quite simple since I had, to start with, an interface to deal with the cache called ICacheHelper and two implementation, one using Redis and one using MemoryCache. The interface itself was really simple:

public interface ICacheHelper
{
    Task Set<T>(string key, T obj, TimeSpan span);
    Task<T> TryGet<T>(string key);
    Task Remove(string key);
}

Now, all I needed to do is to create an implementation using Cosmos DB and update the DI configuration to use it.

To start with, I'll need to add the Cosmos DB package. There are multiple ways to do it, I prefer using the command line by running dotnet add package Microsoft.Azure.DocumentDB.Core.

I know I know, it says DocumentDB in the package. Microsoft will change it eventually.

And here's how my implementation is going to look like. Just so it's simpler to understand, I'm going to break down the code in multiple parts and explain the process. For the constructor, all I'm passing is a custom object that contains all the settings I need to connect to a Cosmos DB instance. I'm also setting some defaults for the JsonSerializer, although this is not mandatory at all.

public CosmosCacheHelper(CosmosDbConfig config)
{
    _config = config;
    _jsonSerializer = new JsonSerializerSettings
    {
        NullValueHandling = NullValueHandling.Ignore,
        MissingMemberHandling = MissingMemberHandling.Ignore,
        ContractResolver = new CamelCasePropertyNamesContractResolver()
    };
    this._client = new DocumentClient(
        new Uri(_config.Endpoint), 
        _config.Key, 
        _jsonSerializer);
}

I've created a custom class to store the data I need in the cache. The Id and Data properties are pretty obvious, but what the heck is Ttl? TTL is Time to Live which is a property that will tell Cosmos DB to auto delete a document after a certain number of seconds.

private class CacheDocument<T>
{
    public string Id { get; set; }
    public long Ttl { get; set; }
    public T Data { get; set; }
}

The Set method will receive a key and the object itself and also a time to live as a TimeSpan. When I create the document, I'm coverting the TimeSpan into total seconds and setting the Ttl property.

public async Task Set<T>(string key, T item, TimeSpan span)
{
    var entry = new CacheDocument<T> {
        Data = item, 
        Id = key, 
        Ttl = Convert.ToInt64(span.TotalSeconds)};
    
    await _client.UpsertDocumentAsync(
        UriFactory.CreateDocumentCollectionUri(
            _config.DatabaseId, _config.CollectionId), entry,
        new RequestOptions {JsonSerializerSettings = _jsonSerializer});
}

Time to retrieve some data from the cache. If you know a bit of Cosmos DB, you might notice that I'm setting the PartitionKey the same as the key itself, which is not the most optimal way of using the PartitionKey, but that will do for now.

public async Task<T> TryGet<T>(string key)
{
    try
    {
        Document document =
          _client.ReadDocumentAsync(
              UriFactory.CreateDocumentUri(_config.DatabaseId,
                _config.CollectionId, key),
                new RequestOptions {
                PartitionKey = new PartitionKey(key)
            }).GetAwaiter().GetResult();
        var entry = (CacheDocument<T>) (dynamic) document;
        return entry.Data;
    }
    catch (DocumentClientException e)
    {
        if (e.StatusCode == System.Net.HttpStatusCode.NotFound)
        { return default(T); }
        throw;
    }
}

Finally the Remove method which is not going to be used often, but here it is.

public async Task Remove(string key)
{
    await _client.DeleteDocumentAsync(
        UriFactory.CreateDocumentUri(
            _config.DatabaseId, _config.CollectionId, key), 
            new RequestOptions{PartitionKey = new PartitionKey(key)});
}

When it comes to the DI configuration, that's how mine is looking like, but for you it will really depend on what DI tool you're using.

builder.Register(a => new CosmosCacheHelper(new CosmosDbConfig
{
    Endpoint = GetEnvironmentVariable("CosmosCache_EndPoint"),
    Key = GetEnvironmentVariable("CosmosCache_Key"),
    DatabaseId = GetEnvironmentVariable("CosmosCache_DatabaseId"),
    CollectionId = GetEnvironmentVariable("CosmosCache_CollectionId")
})).AsImplementedInterfaces();

And here's an example of how you can use it.

var key = $"MyCachedCat{cat.Id}";
if ((await _cacheHelper.TryGet<Cat>(key)) != null)
{
    cached = new Cat { Id = cat.Id };
    await _cacheHelper.Set(key, cached, new TimeSpan(0, 1, 0, 0));
}

And just before I forget, in your Cosmos DB container, make sure you enable time to live, otherwise this solution won't work properly.

I'll evaluate this solution and update the post with some dollar amounts after a few weeks.

Hope it helps.

Cheers

The problem I have is basically to fix some weird data structure coming from a data provider, which I'm sure there's some background story on why the structure is that way, into a reasonable structure that I can later on map into a model or entity more easily.

Let's start from the begining and go through some really basic examples when it comes to data binding. Imagine we have a JSON object which you're going to use as the body of a HTTP POST request.

{
	"status": true,
	"version": "2.0.3",
	"expires": "1551829009.0"
}

In the C# side, the parameter of the API can be as such and everything will be bound perfectly.

public class DataRequest
{
    public bool Status {get;set;}
    public string Version {get;set;}
    public TimeSpan Expires {get;set;}
}

What if now, we have a new field in the JSON object that doesn't really follow your naming convention, like the status_code below:

{
	"status": true,
	"version": "2.0.3",
	"status_code": 200,
	"expires": "1551829009.0"
}

That's still not a big deal and with the JsonProperty attribute you can customize which field to bind to.

public class DataRequest
{
    public bool Status {get;set;}
    public string Version {get;set;}
    [JsonProperty("status_code")]
    public int StatusCode {get;set;}
    public TimeSpan Expires {get;set;}
}

The problem gets harder if the field name coming from the JSON object is dynamic. In my example, I have a scructure that's essentially an array, but it wasn't built this way and I have no access to change that so I have to work around it.

{
	"status": true,
	"version": "2.0.3",
	"status_code": 200,
	"expires": "1551829009.0",
    "players":
    {
        "a_hales": {
            "seasonal_role": "batsman",
            "fullname": "Alex Hales",
            "name": "AD Hales"
        },
        "j_root": {
            "seasonal_role": "batsman",
            "fullname": "Joe Root",
            "name": "JE Root"
        },
        "d_bishoo": {
            "seasonal_role": "bowler",
            "fullname": "Devendra Bishoo",
            "name": "Devendra Bishoo"
        }
    }
}

Using JsonProperty is out of the equation because I have no idea what the property name for each individual player is going to be, also at the end of the day I want to bind that property name to the value of an Id field. Another tricky point is the fact that's players is an object and I want it to be an array.

Here comes the solution

I want each individual player inside that players object to be bound to this C# class.

public class Player
{
    public string Id { get; set; }
    [JsonProperty("seasonal_role")] 
    public string SeasonalRole { get; set; }
    public string Fullname { get; set; }
    public string Name { get; set; }
}

The DataRequest would look something along these lines, but the Players property wouldn't be bound as it expects a JSON array instead of an object.

public class DataRequest
{
    public bool Status {get;set;}
    public string Version {get;set;}
    [JsonProperty("status_code")]
    public int StatusCode {get;set;}
    public TimeSpan Expires {get;set;}
    public List<Player> Player {get;set;}
}

There it comes a custom JsonConverter from Newtonsoft for the win.

public class PlayersConverter : JsonConverter
{
    // This is used when you're converting the C# List back to a JSON format
    public override void WriteJson(JsonWriter writer, object value, JsonSerializer serializer)
    {
        writer.WriteStartArray();
        foreach (var player in (List<Player>) value)
        {
            writer.WriteRawValue(JsonConvert.SerializeObject(player));
        }
        writer.WriteEndArray();
    }

    // This is when you're reading the JSON object and converting it to C#
    public override object ReadJson(JsonReader reader, Type objectType, object existingValue,
        JsonSerializer serializer)
    {
        var response = new List<Player>();
        // Loading the JSON object
        JObject players = JObject.Load(reader);
        // Looping through all the properties. C# treats it as key value pair
        foreach (var player in players)
        {
            // Finally I'm deserializing the value into an actual Player object
            var p = JsonConvert.DeserializeObject<Player>(player.Value.ToString());
            // Also using the key as the player Id
            p.Id = player.Key;
            response.Add(p);
        }

        return response;
    }

    public override bool CanConvert(Type objectType) => objectType == typeof(List<Player>);
}

And to close the loop, we need to update the DataRequest to use this new converter.

public class DataRequest
{
    public bool Status {get;set;}
    public string Version {get;set;}
    [JsonProperty("status_code")]
    public int StatusCode {get;set;}
    public TimeSpan Expires {get;set;}
    [JsonConverter(typeof(PlayersConverter))]
    public List<Player> Player {get;set;}
}

I hope it helps.

Cheers

I've always known that Postman is powerful tool and a must for any developer and for several years I've been using it just for some trivial testing, nothing too crazy until I found the need to actually do something more meaningful with it.

Recently I had the need to ingest a whole lot of data into the system I'm working on, but the data was scattered across the system and pushing the data straight into the database would be a nightmare.

I already had the process to ingest the data one by one through an API and I didn't want to build something to ingest in bulk just to be used once in a life time. I knew Postman was probably the answer so I started digging.

I found this guys, Valentin Despa, on YouTube showing how you can automate a bunch of API calls using pre-request script to loop through a javascript array and updating environment variables on the way. That was a great start, but it wasn't the full answer as I had a JSON file with thousands of objects that I wanted to turn into requests.

Then I found this other guy, Raghav Pal, also on YouTube showing exactly what I was looking for which was ingesting the API requests using a JSON file.

Just to keep a record here how much I appreciate people sharing their work. It makes my life so much easier and I bet it makes yours too :D

Cheers

I haven't always been a big tester, I started finding the great advantages of unit testing the back end just a couple of years ago. With E2E tests I barely got close, everything I tried was so fiddly and use to break so easily. Well, Cypress changed my way of thinking. It's so powerful and so simple to get started.

1. Let's see how simple it is. I'm going to start with an empty folder and from the console I'll run npm i cypress --save-dev
2. We need now to create a file called cypress.json which will hold all the configuration for Cypress, all I'm going to put inside for now is {}, an empty JSON object.
3. Inside the current directory I'm going to create a folder called cypress, and integration inside cypress. The integration folder will hold all test specs.
4. Now just as a test, I'll create a new file called google_spec.js and inside the file I'll add the below:

describe("Google Thiago Passos", function() {
  it("Should search Thiago Passos' Blog", function() {
    cy.visit("https://www.google.com.au");
    cy.get("input[type=text]:first").type("Thiago Passos");
    cy.get("input[type=submit]:first").click();
    cy.get(".g:first a:first").click();
    cy.url().should("include", "passos.com.au");
  });
});

5. To run the tests, we can simply run cypress run. This will run all the tests in the console without opening a browser.

6. To run the tests in the browser, you can run cypress open --project .. This will open cypress console and you can press on Run all specs

Which will run all the tests in an interactive way.

Hope you now share my excitment about e2e tests.

Cheers

I've just learned recently about this NPM package to mock a REST API using a JSON file. That's a life changer and I see myself using it for any front-end development I do in the future.

It's super simple to get started, all you'll need is Node.js installed and json-server.

To install json-server:

npm i -g json-server

Now all you need is a JSON file and run json-server against it. So try with this one and save it as db.json

{
  "products": [
    {
      "name": "apple",
      "categoryId": 1,
      "id": 1
    },
    {
      "name": "banana",
      "categoryId": 1,
      "id": 2
    },
    {
      "name": "watermelon",
      "categoryId": 1,
      "id": 3
    },
    {
      "name": "orange",
      "categoryId": 1,
      "id": 4
    }
  ],
  "categories": [
    {
      "name": "fruit",
      "id": 1
    }
  ]
}

Time to run it. I'm using the --watch flag so any change made directly to the db.json file gets reflected to the server

json-server db.json --watch

And that's all. You can try it out in the browser http://localhost:3000/products for example.

Cheers

We've been putting together the content for the workshop Jason and I will run at NDC London in January and part of the story is the deployment and why not using something brand new which is the Azure Static Websites? So let's give it a go.

Creating brand new Vue.js app

I'm going to use the Vue Cli in my example. So it's as simple as going to the command line and typing vue create myvueapp. From here you can choose what sort of features you want, in my case I've got a preset with vue-router, vuex, babel and eslint, but the feature I want to highlight in this post is the router, so make sure you enable this one.

Once the app is created, I can start it with this command npm run serve and I've got my app running locally. Too easy!!!

Creating static website in Azure

Okay, let's leave the app as is for now and let's jump into the Azure portal and create our first static website.

1. First we're going to create a storage account. "Hold on!!! I thought we were creating a website". Calm down! We'll get there.

2. Make sure you select the StorageV2. The Static Website feature is still in preview and it's only available on this storage account type.

3. Now it's time to enable the static website feature. The cool thing about this feature is that it also has an error document path which we will also point to index.html and let Vue handle any routing issue. Take note of the primary endpoint here as it's going to be your initial url.

Building and deploying our Vue.js app manually

Again we're going to use the Vue Cli and also the Storage Explorer

1. Let's first build it with the command npm run build, after running it, you'll see a dist folder inside your app folder

2. We're going to copy the content of the dist folder to the $web folder in your storage account using the Storage Explorer. You can basically drag-and-drop if you want.

3. Let's test it out and go to the URL we've copied previously. Hooray!! You can test the routing and see that everything is working perfectly.
   

Building and deploying automatically with Azure DevOps

To do a quick and dirty test, building and deploying your application manually is fine, but it's really not maintainable for a real app. So let's configure a quick CI/CD for it.

I'll assume your source code is either in a git repository on Azure DevOps or somewhere accessible. In my case, I'm going to use a git repository within Azure DevOps.

1. Creating a new pipeline
   

2. Selecting the repository
   

3. We'll start with an empty job in this case
   

4. We're going to create 2 npm steps, the first one is a normal npm install
   

5. The second one is going to use the custom with build parameter
   

6. We should use separate CI and CD pipelines, but just for sake of simplicity, I'm just going to add the step to do the deployment here in the CI pipeline. We're going to search for the Azure File Copy step
   

7. A very important thing to mention here is to use the version 2.* (preview), otherwise it's going to fail when trying to copy to the $web folder.
   

8. Time to save & queue
   

And voila! Your app is now being built and deployed automatically.

One thing to keep in mind here: if you're using YAML and a Windows machine as the build agent, you might encounter some issues if you have multiple commands in a single task. Check Ron's question on Stack Overflow for more information

Hope it helps!

Cheers

It's time to move on. I left a small consultancy a bit over 4 years ago in Melbourne to move to Brisbane and join this awesome company that is SSW, but an unrefusable opportunity came up and I couldn't let it pass.

I've loved working for SSW and all the people that make it such a great place to work, and I have to say that it was a really hard decision to make but since I had my third child I feel an even stronger need to be home more often, so that's what I'm seeking, reducing my commute time by working from home.

Before I joined SSW, Adam Cogan, my boss to be, told me that when it was time for me to leave I should come back to him and tell him what I learnt and how much I grew during my stay there. This really took me by surprise because that was the first time I started in a company where the boss had the peace of mind that eventually I'd be moving on. That was an awesome start...

I learnt so many things at SSW in the past 4 years that it's going to be really hard to mention everything, but it was definitely a milestone in my life and my career, where I started as a mediocre developer and now I have the confidence to call myself a solution architect.

What did I learn?

• I got a grasp of what Scrum is all about
• I left that SharePoint bubble to expand my horizon with pure web and cloud development
• I learned front end development which I wasn't used to
• Continuous integration and continuous deployment? I didn't even know what it meant and now I could even call myself a "DevOps" expert.
• So many development good practices that the list would be way too long to put here
• The power of consistency
• That the rules are not such a bad thing
• The feedback culture. Don't worry, I'm still going to call out for a test please before I give a talk
• Lost the fear of public speaking and I actually got to like it
• The importance of sharing knowledge
• Done videos are so useful
• The value of being compassionate with the client's struggles
• To be a better consultant with all the above

A few very special thanks

Adam and Ana, thank you very much for having me for the last 4 years, not only in the company, but also in your family. I've learned heaps from you two, not only as a professional but as a human being.

Jason and Brendan, you are the super stars of the best SSW office (Brisbane). It was an honour to be in so many projects with you two, keep it up with the great work you guys are doing and I'm sure we're going to work together in the future.

Stevo (Adam from Microsoft), even though you're no longer with SSW, I had to mention you here, you've been a mentor and a friend for most of my stay at SSW until you left us for Microsoft, but I still love you.

Duncan, you were an inspiration for me to get started in the public speaking journey.

Uly, I remember like it was yesterday, I was doing the communication test with you and we probably spent half the time talking about dancing. I went back home very excited to talk to Alyne and tell her I might join a company where they have a salsa champion.

Lindsay, I remember when I was introduced to you, I was asking Adam if I'd need now to report to you and he called you into the conversation, I thought it would be most awkward chat, but you were great. You've been doing a great job with the Brisbane office and taking Chinafy to the world, keep it up.

Gabe, we worked together for such a small period of time but it was great fun, we even managed to start our own YouTube Channel. Your enthusiasm is amazing. Looking forward to more chats and coffees when I'm in Melbourne.

Patricia, keep your smiles up, you bring light to every room you come in. Chris, your optimism is mind blowing. JK, keep it up and don't forget to dance. Rebs, you make our lives so much easier with your magic wand that makes everything look good. And to all of you that were with me in that big project, thank you very much for your patiance, it was a hard gig, quite stressful several times, but we made it.

Jean and Liam, you guys have a duty to keep the community stuff happening in Sydney, keep you talks going.

New, thank you for always being so patient explaining about payment stuff.

Jo and Penny, thank you so much for all the hard work to put together all the events that we did in the last couple of years. It wouldn't be the same without you.

Raj, thanks for making us look good on camera. I learned lots with you and hopefully we'll have shots soon.

Sorry I didn't mention everyone, SSW has plenty of great and smart people. It was an amazing journey and I loved being part of the SSW family.

Cheers

Okay, so I've published my very first npm package. Let's start from the beginning. We've got an internal MVC application that uses the Kendo UI from Progress, the rich text editor to be more specific. We started migrating that application to Angular and, to our surprise, the editor was not available for Angular as yet.

What do we do from here? One of the options was to use the Kendo UI for jQuery and hack it so it works with Angular. Well, I know that sounds dirty and half way through doing it, I had the wash my hands and say "That's enough!".

We then called John Bristowe from Progress to help us make a decision on that and, to our surprise, he suggested us to try ProseMirror as both Progress and DevExpress were evaluating/using it. I gave it a go and looked beautiful. I've even found a great implementation for Vue.js called tiptap.

One of the beauties of ProseMirror is that it handles markdown quite elegantly and that's why we wanted to leverage it.

The problem was I couldn't find an easy implementation for Angular which made my life quite hard but interesting. So I decided to roll my own npm package to simplify the implementation and maybe to help others out there.

Here it is: https://www.npmjs.com/package/ngx-prosemirror

Be aware it's really really really early days, I just published and there's a lot of work to do. If you want to help me out, go to the GitHub repository and give it a go.

Instructions

• npm i ngx-prosemirror
• Import the NgxProsemirrorModule to your module
• Add to your component

<ngx-prosemirror [(content)]="contentInMarkdown"></ngx-prosemirror>

Hope it helps.

Cheers.

I'm sure 100% of you have already heard about what a push notification is, that's what apps and several web sites do to get your attention even if you don't have their app/website open. But the implementation of it might seem a little bit of magic for some. In this post, I'm going to cover how to implement push notifications in an Angular application and also how to handle these notifications differently when you have the app open.

As always, the source code covered in this post is available here

Push notifications in a web site is now possible due to service workers, which is something that's going to run in the background even if you don't have the website open. If you haven't heard about what service workers are, check out this post.

To get started, I'm going to use the .NET Core + Angular SPA template (if you want to know more about this template, check this post). Here are the very simple commands:

mkdir push-notification-angular-dotnet-core
cd push-notification-angular-dotnet-core
dotnet new angular

Here's our plan, the stuff we need to put together:

1. A service worker in place to handle push events when the site is not open
2. Register the service worker
3. Create Public and Private keys
4. A way to subscribe and unsubscribe to push events on demand. Basically, ask permission from the user to send push events.
5. Handling push events
6. Handling subscriptions in the server
7. Send push events from the server

#1 Create our service worker

For now, we're just going to create a sw.js file in the assets folder. This is going to be our service worker.

#2 Register our service worker

Since we're using Angular, I want to do this in the neatest way possible, so I'm going to create a service for this using the Angular Cli:

cd ClientApp\src\app
ng g s core/notificationMiddleware

In the service, I'm going to create a few things. First I'm going to create an object to hold the state of push notification of the browser instance.

public pushNotificationStatus = {
    isSubscribed: false,
    isSupported: false
  };

An init method which I'm going to call from the app.component as soon as the app starts which is going to check if the current browser supports service workers and push notifications, if it does then we're going to automatically register the service worker (sw.js) we added to our assets folder. Also a checkSubscription method to update the isSubscribed flag.

init() {
  if ('serviceWorker' in navigator && 'PushManager' in window) {
    navigator.serviceWorker.register('/assets/sw.js')
      .then(swReg => {
        console.log('Service Worker is registered', swReg);

        this.swRegistration = swReg;
        this.checkSubscription();
      })
      .catch(error => {
        console.error('Service Worker Error', error);
      });
    this.pushNotificationStatus.isSupported = true;
  } else {
    this.pushNotificationStatus.isSupported = false;
  }
}

checkSubscription() {
  this.swRegistration.pushManager.getSubscription()
    .then(subscription => {
      console.log(subscription);
      console.log(JSON.stringify(subscription));
      this.pushNotificationStatus.isSubscribed = !(subscription === null);
    });
}

Now in the app.component.ts, we're going to inject the NotificationMiddlewareService and call the init method:

export class AppComponent implements OnInit {
  title = 'app';

  constructor(private notificationMiddleware: NotificationMiddlewareService) {
  }

  ngOnInit(){
    this.notificationMiddleware.init();
  }
}

If we run ng serve in the ClientApp folder and go to the browser now, we should see the service worker installed by going to the Dev Tool bar > Application > Service Workers.

While in development stage, keep the flag Update on reload checked, so every time you make changes to the service worker, it re-installs it automatically.

#3 Create Public and Private keys

Before we get to the next step which, we need a public and private keys so all the communication between the sender and the receiver is encrypted. There are several ways to do it, but the simpler way I found was via the website https://web-push-codelab.glitch.me. You can just go there and copy both the Public key and Private key. We're going to add our Public key to the environment.ts file:

export const environment = {
  production: false,
  applicationServerPublicKey: `[PUBLIC KEY]`
};

In the server side, we're going to add them to the appsettings.json.

{
  "VapidDetails": {
    "Subject": "[ORIGIN URL, EX:https://localhost:4201]",
    "PublicKey": "[PUBLIC KEY]",
    "PrivateKey": "[PRIVATE KEY]"
  }
}

#4 Subscribe and Unsubscribe

Instead of asking the user to trust the site as soon as they land on the site, it's a best practice that we ask for permission on demand so the user knows what he's agreeing to. So we're going to create subscribe and unsubscribe methods in the just created service and call this from the UI.

The subcribe method encrypts the public key and uses the pushManager to subscribe the user:

subscribe() {
  this.pushNotificationStatus.isInProgress = true;
  //check the source code to get the method below
  const applicationServerKey = this.urlB64ToUint8Array(environment.applicationServerPublicKey);
  this.swRegistration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: applicationServerKey
  })
    .then(subscription => {
      console.log(JSON.parse(JSON.stringify(subscription)));
      this.pushNotificationStatus.isSubscribed = true;
    })
    .catch(err => {
      console.log('Failed to subscribe the user: ', err);
    })
    .then(() => {
      this.pushNotificationStatus.isInProgress = false;
    });
}

I've created a notifications component so I can add a button to call the subscribe method and as soon as I call it, the user will be prompted to either allow or block as per screenshot below. Once they allow, you should have the subscription which will have everything you need to send push notifications.

You might want to copy the subscription from the logs to test the push notifications later on

.

The unsubscribe method will work very similarly:

unsubscribe() {
  this.pushNotificationStatus.isInProgress = true;
  this.swRegistration.pushManager.getSubscription()
    .then(function (subscription) {
      if (subscription) {
        return subscription.unsubscribe();
      }
    })
    .catch(function (error) {
      console.log('Error unsubscribing', error);
    })
    .then(() => {
      this.pushNotificationStatus.isSubscribed = false;
      this.pushNotificationStatus.isInProgress = false;
    });
}

In order to make my life easier, I've created a toggleSubscription method, since we already have a flag that recognizes if the user is subscribed or not:

toggleSubscription() {
  if (this.pushNotificationStatus.isSubscribed) {
    this.unsubscribe();
  } else {
    this.subscribe();
  }
}

#5 Handling push events

Now that we have a subscription, it's time to start handling push events. That's where the service worker is going to shine. Let's go now to the sw.js file.

WARNING: The service worker is javascript file, not typescript.

We're going to add an event listener for the push event.

'use strict';

self.addEventListener('push', function (event) {
    console.log('[Service Worker] Push Received.');
    var data = event.data.json();

    const title = data.Title;
            const options = {
                body: data.Message,
                icon: 'assets/push.png',
                badge: 'assets/push.png',
                data: data.Url
            };

            const promiseChain = self.registration.showNotification(title, options);

    event.waitUntil(promiseChain);
});

To test it out, let's go back to https://web-push-codelab.glitch.me and paste the subscription we got from the previous step. Notice that I'm sending a json document in the message, but you could send just text.

You probably noticed also that I added a Url to the json document I sent and I'm adding it to the options of the notification, but at this point in time, if you click on the notification, it's not going to do anything and that's because we have to start listening for another event, the notificationclick. So let's add it:

self.addEventListener('notificationclick', function (event) {
    const urlToOpen = new URL(event.notification.data, self.location.origin).href;

    event.notification.close();

    event.waitUntil(clients.openWindow(urlToOpen));
});

Great, now if you click on the notification, it will open the Url we sent.

Okay, but what if I already have a tab open of that site, or if I am on the site itself right now? It's going to be a pain in the bum to start getting all those push notifications and opening always a new instance. There's a solution for that, this post talks about all different approaches to improve the push experience which I'm implementing in the source code, but I'm not going to cover here as this post is already getting too long.

#6 Handle subscriptions in the server

For this section, we're going to need both the public and private keys we created in the step #3, also we're going to need to modify the subscribe and unsubscribe methods so it calls the API endpoints to manage the subscriptions.

For testing purposes, I'm going to save all the subscription into memory, but if you're going to implement this somewhere, be sure to persist the subscriptions somewhere else.

To send the push notifications, I'm going to use a nuget package called WebPush. I've also configured in the startup to inject the VapidDetails which are the details we need to send the push notification: Subject (Origin URL), Public and Private keys.

I've created a Notification controller to handle 3 things: Subscribe, Unsubscribe and Broadcast:

[ApiController]
[Route("api/[controller]")]
public class NotificationController : Controller
{
    public static List<PushSubscription> Subscriptions { get; set; } = new List<PushSubscription>();

    [HttpPost("subscribe")]
    [ProducesResponseType((int)HttpStatusCode.OK)]
    public void Subscribe([FromBody] PushSubscription sub)
    {
        Subscriptions.Add(sub);
    }

    [HttpPost("unsubscribe")]
    [ProducesResponseType((int)HttpStatusCode.OK)]
    public void Unsubscribe([FromBody] PushSubscription sub)
    {
        var item = Subscriptions.FirstOrDefault(s => s.Endpoint == sub.Endpoint);
        if (item != null)
        {
            Subscriptions.Remove(item);
        }
    }

    [HttpPost("broadcast")]
    [ProducesResponseType((int)HttpStatusCode.OK)]
    public void Broadcast([FromBody] NotificationModel message, [FromServices] VapidDetails vapidDetails)
    {
        var client = new WebPushClient();
        var serializedMessage = JsonConvert.SerializeObject(message);
        foreach (var pushSubscription in Subscriptions)
        {
            client.SendNotification(pushSubscription, serializedMessage, vapidDetails);
        }

    }
}

Back to the Angular side of the application, I'm going to update the subscribe and unsubscribe methods to call the server side endpoints.

In order to talk to the server, I've implemented OpenApi with code generation, to know more about it, check this post. My NSWAG is also in the source control if you need to re-generate the typescript file.

So now my subscribe method is calling

this.notificationService.subscribe(<PushSubscription>{
  auth: newSub.keys.auth,
  p256Dh: newSub.keys.p256dh,
  endPoint: newSub.endpoint
}).subscribe(s => {
  this.pushNotificationStatus.isSubscribed = true;
})

And the unsubscribe is calling

this.notificationService.unsubscribe(<PushSubscription>{
  auth: sub.keys.auth,
  p256Dh: sub.keys.p256dh,
  endPoint: sub.endpoint
}).subscribe(() => {
  this.pushNotificationStatus.isSubscribed = false;
  this.pushNotificationStatus.isInProgress = false;
});

#7. Send push events from the server

Alright, now to test it all out, I've created a broadcast component to call the broadcast endpoint in the notification controller. Let's see it in action.

1. On the right hand side I've got Chrome which I'm going to broadcast the message from, on the left hand side Microsoft Edge.
2. When I send the message, it broadcasts to everyone who's subscribed.
3. I get a notification for Edge
4. I get an in app notification for chrome since I have it focused.

Hope it helps. Have fun!!!

Cheers.

In the last 2 years, I went to NDC Sydney and it's always been a great event, possibly the best conference I've been, but this time it would be different, this time I wasn't only attending but also presenting. While I did a hell lot of prep to get there, I was still sh*ting on my pants, but let's see how it went. I'm sure it would be awesome anyway.

I'll add the recordings as soon as they are available

Pre conference

Let's start with the call for papers: using Sessionize makes our lives so much easier, I usually have a couple of talks lined up, so the process of submitting talks was a piece of cake. I just wish all other conferences would use it.

Once I was accepted to speak, the whole organization of flights and accommodation was seamless. They got in touch and sorted everything months before the event, giving us enough time to do any preparation from our end.

My goal this time

I was presenting, so my first goal obviously was to do a good job so I could keep coming back, but it wasn't only that. In the previous NDCs, my goal was to watch as many presentations as possible to learn as much as my brain could handle, this time I wasn't going to even try that because I know from previous experience that this is just not possible, I would only have a brain freeze (if there's such thing). This time my main goal was to talk to people, make connections, learn from the great minds. It's one of those things that this conference allows us.

Kick off

As expected, the kick off of the best developer conference in Australia (in my opinion) was amazing, the whole atmosphere was so good. It was great to see so many first time attendees and speakers (including myself), which made me feel even more comfortable.

Conference

Overall, it was amazing. Great people, great talks, great food, great venue, great organizers and volunteers, great after parties.

Outcome

As I said, the conference was great, but here are some of my high and downlights.

Highlights:

• Presenting at the conference I love and not getting any reds
• Being amongst so many smart people
• Interviewing for SSW TV
• Staying at Hilton
• Networking and planning next conferences
• Boat cruise
• Afterparty

Downlights:

• Not attending PubConf

That's it. I'm looking forward to the next NDC, either NDC London, NDC Portugal, NDC Oslo or anything that comes first in my way.

Cheers.

I was really looking forward to having the Cosmos Db provider for Entity Framework Core. So much that I actually submitted a talk for NDC Sydney about how to get started with it even before the provider was out, and it's finally out, still in preview so a lot of things might change, but I'm very excited all the same.

As always, the source code covered in this post is available here

Let's see how to put it together.

Creating an instance of Cosmos Db + Database

In the Azure Portal, you're going to look for Cosmos DB. Just make sure you select the SQL Api when creating it as this is the one supported by EF Core.

Once the instance is created is time to create a new database

This is the database name we're going to use in our application, so save it.

And the collection is like a table in SQL, this is going to line up with a repository (DbSet)

Now give a name to your collection, but be very careful with the throughput.

WARNING!!! You can pay a lot of money if you're careless about the throughput. There's even a check box for you to acknowledge if you set a high value. With the value below, you're looking to pay $11,520.00/month. That's crazy!!!

You're all set from here!

We just need some keys to configure our application

Bringing in the provider

You can do either via the command line which would be dotnet add package Microsoft.EntityFrameworkCore.Cosmos.Sql --version 2.2.0-preview1-35029 or you can use the Visual Studio Package Manager as bellow. There were only 72 downloads at the time. Wow!!!! Is that a good thing (I'm one of the 72 crazy people in the world) or that's a sign I'm going to be in trouble if I try it in production??? :D

Setting up in the project

In my application, I've created a appsettings.json so I can bring the configuration in:

{
  "CosmosDb": {
    "EndpointUrl": "<URI IN THE KEYS SECTION>",
    "PrivateKey": "<PRIMARY OR SECONDARY KEY IN THE KEYS SECTION>",
    "DbName": "<NAME OF THE DATABASE>"
  }
}

In my dependency injection configuration method (if you're creating a Web Api or MVC app, that would potentially be in the startup.cs), I'm going to hook things up.

public static IContainer IocConfig()
{
    ...

    serviceCollection.AddEntityFrameworkCosmosSql();
    serviceCollection.AddDbContext<BlogDbContext>(options =>
    {
        options.UseCosmosSql(
            new Uri(Configuration["CosmosDb:EndpointUrl"]),
            Configuration["CosmosDb:PrivateKey"],
            Configuration["CosmosDb:DbName"]);
    });
    
    ...
}

My DbContext looks very similar to any other.

public class BlogDbContext : DbContext
{
    public DbSet<Post> Posts { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Post>();
        var blog = modelBuilder.Entity<Post>().Metadata;
        // This needs to line up with the collection previously created
        blog.CosmosSql().CollectionName = nameof(Posts);
    }
}

Let's test ride

I've created a command (CQRS pattern) to add a post to the database, but I'm simply calling 2 lines inside it

await _dbContext.Posts.AddAsync(entity);
await _dbContext.SaveChangesAsync();

In my console app, I'm building up the entity before sending to the command and I'm printing the generated ID at the end. That's how it looks when it's running:

Now we can check in the portal and see if the post was created.

And voilà!!!

Hope it helps.

Cheers

In the last post, we talked about how to keep your API layer as slim as possible and then expose them through Azure Functions and I finished the post deploying to Azure using the frightful right-click publish. And as promised, this time we're going to go through the process of setting up your CI/CD pipelines.

The source code covered in this series is in this GitHub repository.

If you find it easier, you can follow the steps in the video below.

We're going to use Visual Studio Team Services (VSTS) for the CI/CD pipelines, if you do not have an account yet, I highly recommend, it's free for up to 5 users. Just go to visualstudio.com to get started.

Prerequisites

• Azure subscription, create a free account before you begin.
• VSTS account
• Git repository (it can be inside of VSTS or not, up to you)

Here are the steps we're going to follow:

1. Create a build pipeline

The screenshots are very self explainatory, but I'll comment on some of them.

Even though I'm using GitHub, you can chose whatever Git repository you want.

Keep in mind here that I'm using the version 2.0 of Azure Functions which supports .NET Core. If it's not your case, then this step will be different.

The only thing you need to customize in the build is the publish step, because, by default, it has the option Publish Web Projects checked which would NOT pick up your Azure Functions project.

2. Create a release pipeline

You're all done with your build pipeline, now it's time to create your release pipeline.


We're going to use as artifact what was generated in the build pipeline.

This step is not necessarly mandatory. You can chose to kick off the release pipeline manually.

In this example, I'm just going over a single environment, but you can add as many environments as you want.

Now you can see the advantage of using VSTS for the CD pipeline. The integration with Azure is amazing. Your list of subscriptions shows up here automatically as long as you're using the same Microsoft account to log in.

And the last thing to do here is to select the right package to deploy, otherwise it's going to deploy all packages generated by the CI pipeline and the deployment will most likely fail.

Extras: Setting up deployment variables

Setting up variables is very easy for your deployment enviroments.

And you can use across all your deployment tasks by just using $([Variable Name]), in my case I'm using $(ConnectionString).

Hope it helps.

Cheers