Monday, August 27, 2018

Hello, Startup - A book for developers building their startups

Developers looking to build their startups should read this book

This is a book that I really recommend and wish developers and non-technical people would read: hello, startup. It has lots of insights not only on startups but also on careers, business, management, culture, handling success, failures and more, way more.

Quoting the author:
This book will teach you how to build products, technologies, and teams in a startup environment. It's based on the experiences of the author, Yevgeniy (Jim) Brikman, as well as interviews with programmers from some of the most successful startups of the last decade, including Google, Facebook, LinkedIn, Twitter, GitHub, Stripe, Instagram, AdMob, Pinterest, and many others.

If you're at all interested in startups, this book is for you.


If you're planning on building your own company, want to know more about the startup scene, is searching for answers regarding your current job and think that a startup may be your best choice, please take a look.

See Also

Monday, August 20, 2018

Exploring MassTransit InMemory Scheduled Messaging using RabbitMQ and .NET Core

On this post, let's explore MassTransit's scheduler messaging system using RabbitMQ

On a previous post, I demoed how to create a MassTransit client/server application using RabbitMQ, .NET Core and Linux. Today we will explore another very interesting functionality: the ability to schedule messages to send them in the future. My experiences with MassTransit so far have been fantastic, however, there are a few use cases that I still would like to test. On this post, we cover the scheduled message use case, testing the in-memory solution.

Persistence Requirements

In order to keep our data persisted for the scheduler to use we'll need to configure MassTransit's storage with one of the following services:
  • Quartz.Net in a hosted server
  • Azure Service Bus
  • RabbitMQ by installing a plugin
  • a test-driven In-Memory implementation
On this post, we'll spike out the in-memory solution due to its simpler requirements but the behaviour should be equivalent for different transports.

Referencing Packages

MassTransit's Scheduling Api utilizes Quartz.Net. So, for it to work, we will need the to add a reference to the MassTransit.Quartz package to your project with:
$ dotnet add reference <project-name> MassTransit.Quartz --version 5.1.3
Once the reference is added, run dotnet restore to load the necessary extension methods to do the initialization.


The initialization code for the in-memory implementation as simple as adding a call to UseInMemoryScheduler() on your bus configuration.
Using the in-memory scheduler uses non-durable storage. If the process terminates, any scheduled messages will be lost, immediately, never to be found again. For any production system, using a standalone service is recommended with persistent storage.

Sample Code

The code below shows a simple implementation of MassTransit and its scheduling system:

Running the Demo app

So, I run my app and my code schedules a message to be sent 3 seconds after sent by the user. This is my output:


Hope this serves as an introduction to the scheduling feature within MassTransit. I've been using MassTransit for a couple of years now and definitely would recommend it as a framework for your distributed systems. Want to learn more about MassTransit? Please consider reading the following posts:

    Source Code

    The source for this post is located on my GitHub page.
    In case you're interested, I recently pushed a more updated MassTransit/Docker/.NET Core 3.1 implementation to GitHub here:

    See Also

    Monday, August 13, 2018

    Creating a MassTransit client/server application using RabbitMQ, .NET Core and Linux

    Let's test the versatile MassTransit framework using RabbitMQ, .NET Core and Linux and see if it can serve as a reliable messaging system.
    On a previous post we introduced MassTransit on this blog and presented and some reasons why it may be a real nice alternative to your system. Today we will review a simple use case: I will simulate a client/server architecture by building two console applications using MassTransit as the service bus, RabbitMQ as the transport running on Docker, .NET Core.

    Sounds complicated? Let's take a look.

    Installing RabbitMQ

    The quickest way to install RabbitMQ locally is by using RabbitMQ's official Docker image. Assuming you have docker installed on your machine, pulling and running it is as simple as:
    $ docker run --hostname rmqhost --name rmqcontainer -p 15672:15672 -p 5672:5672 rabbitmq:3.7.5-management
    Before running that command, let's examine what each part means:
    • --hostname rmqhost : sets the host name
    • --name rmqcontainer : sets the name of the container
    • -p 15672:15672 : maps container port 15672 to host port 15672 so you can access on your localhost
    • -p 5672:5672 : maps container port 5672 to host port 5672 so you can access on your localhost
    • rabbitmq:3.7.5-management : the name of the image to donwload and run. I chose that one because it has a nice UI to manage RabbitMQ in case you want to play with it.
    If you don't have that image yet, Docker will pull it for you and initialize a container based on the parameters above.

    Once the download is complete, Docker will init RabbitMQ for us. On my Fedora box, I get:

    With your image loaded and you can then access the Management UI on http://localhost:15672. Login with guest | guest:
    Cool. Now that we have RabbitMQ running, let's take a look at MassTransit.

    Building a shared .NET POCO Contract

    Since we're building a client and a server, we also need to build a shared contract they can access. Because the client and the server may (and should) run on different servers, the common solution is to build a class library and reference it on both projects.

    In .NET Core we simply type in the terminal:
    dotnet new console -n MassTransit.RabbitMQ.Contracts
    Then open that project and add this simple message:
    That's it. Build that project to validate everything is ok and let's move to the client.

    Building a MassTransit RabbitMQ Client

    As previously said, the client will need to do two important things:
    • connect to the bus so it can start sending messages
    • send messages that the server recognizes. That's why we created the contract on the step above.
    You can initialize your client with a command similar to the one executed above. Once you have your project created, the important bits are: adding a reference to the contract project previously created, initializing the bus and publishing a message to RabbitMQ.

    Initializing the bus

    To initialize the bus, write a code similar to:

    Publishing a message

    Now, we should be able to publish a message with a code like: Build this project with $ dotnet build to make sure everything is ok but don't run it yet. We still need to build the server.

    Building a MassTransit RabbitMQ Server

    The simple server is pretty similar to the client with the difference that:
    • the server does not publish messages
    • the server contains handlers (consumers) to messages published
    Build a new console app and reference the contract project created above. The gist below shows how to init a service that will run on a console terminal and handle the CreateAccount message:


    Now, let's test both the client and the server to see if they're working ok. Don't forget that now you'll need your RabbitMQ instance running. I suggest running the apps side by side and let's see how that goes:

    My Client App:
     My Server App:
    And my RabbitMQ console:
    So, from the above, you see that the messages sent from the client are reaching the server. Remember, those applications do not know about each other and the only coupling between them is the standalone contract project that both references.


    With all that we reach the end of this post. I hope this demo showed how simple it is to create a MassTransit client/server application using RabbitMQ, .NET Core. I've been using MassTransit for a couple of years now and definitely would recommend it as a base framework for your distributed systems. Want to learn more about MassTransit? Please consider reading the following posts:

    Source Code

    The source code used on this post is available on GitHub.

    In case you're interested, I recently pushed a more updated MassTransit/Docker/.NET Core 3.1 implementation to GitHub at:

    See Also

    Monday, August 6, 2018

    MassTransit, a real alternative to NServiceBus?

    Understand how MassTransit could be a real alternative when building distributed systems on the .NET Platform.
    Photo by Markus Spiske on Unsplash

    Looking for an free and open-source alternative to NServiceBus? Maybe MassTransit could be what you are looking for. Let's understand the platform and how it could be used on your next project.

    What is MassTransit?

    MassTransit  is a lightweight service bus for building distributed .NET applications. The main goal is to provide a consistent, .NET friendly abstraction over the message transport (RabbitMQ, Azure Service Bus, etc.). MassTransit is not a new project. They've been around since 2007 and were created as an alternative to NServiceBus. In early 2014, the framework was rewritten to support asynchronous programming as well as leveraged the power of messaging platform. The code was also rewritten, resulting in an entirely new, completely asynchronous, and highly optimized framework for message processing.

    Why MassTransit

    Like NServiceBus, MassTransit helps decoupling your backend from your frontend (and in general, decoupling services), leveraging enterprise design patterns like CQRS and Eventual Consistency. Some of the features you will find in MassTransit are:
    • providing support for messages, sagas
    • supporting different transports
    • allows automated or custom retries on failures
    • asynchronous requests/responses
    • poison message handling
    • exception management
    • custom serialization
    • message correlation
    • routing
    • scheduling
    • support for modern technologies like Azure Service BusApache KafkaAzure Event Hub and Amazon SQS


    MassTransit is also extremely customizable and as mentioned previously, can run on different transports (RabbitMQ, Azure Service Bus, etc) providing enormous benefits as both are strong and stable platforms with different characteristics. It also supports the new .NET Standard on .NET Core and runs on multi-platforms.

    Cloud Support



    MassTransit includes full support for several transports, most of which are traditional message brokers. RabbitMQ, ActiveMQ, Azure Service Bus, Apache Kafka, Azure Event Hub and Amazon SQS are supported.

    Sample Code

    With that introduction, let's review some code. If worked with NSB before, you're probably looking for three things:
    1. How to initialize the bus
    2. How to initialize the host (your backend, where your handlers run)
    3. How to initialize a client (where you send messages from).
    Please take a look at examples below to understand how it all works.

    Initializing the Bus

    The below code shows how to initialize a simple MassTransit Bus:

    Initializing a Server (Host)

    The below code shows how to initialize a simple MassTransit server:

    Initializing a Client

    The below code shows how to initialize a simple MassTransit client that talks to the above service:

    Other aspects to consider

    Before we end, I'd like to bring to your attention other things you should evaluate before committing on such an important framework to your organization. I'd recommend that you research about:
    • Support: NServiceBus, being backed by a commercial organization deserves a point on this item. Having a commercial organization backing the product may potentially be a more compelling argument to your employer. NSB offers multiple support options including consulting and on-site training.
    • Online Documentation: both frameworks have good documentation but NSB is definitely ahead on this criteria. You will find way more documentation about NSB.
    • Community: both MT and NSB have decent online communities, with the latter being bigger and more active.
    • Access to current technologies: MT and NSB will definitely provide you access to modern technologies like cloud and serverless but NSB seems to be ahead on that regard.
    • Active development: both NSB and MT have very active developments.
    • Open-Source: I preferably like to have access to the source code of the product I'm using, in case there are issues
    • Ecosystem: Particular, NSB's parent company, offers lots of other products that are worth considering. These products integrate well with NServiceBus and depending on your use of the platform may 

    Final Thoughts

    This ends our quick introduction about MassTransit. I've been using NServiceBus for quite some time and while I recognize its value, I wanted to explore viable (and cheaper) alternatives for my open-source projects. I've been using MT for a couple of years I can confirm that it's a solid alternative to NServiceBus. MassTransit today is also a bigger and more solid project than it was 5 years ago and definitely deserves your attention.

    However, choosing a critical framework like this is not only about code. I recommend you to also evaluate other criteria such as support, documentation, training and ecosystem. On pretty much every criteria (except for price) NServiceBus is ahead. And maybe those things will count for your organization.

    More about MassTransit

    Want to learn more about MassTransit? Please consider reading these articles:

    Source Code

    As always, the source code is available on my GitHub.


    See Also

      About the Author

      Bruno Hildenbrand      
      Principal Architect, HildenCo Solutions.