Message Context and MassTransit

Did you know that MassTransit has the ability to ‘smuggle’ data? Now maybe smuggle isn’t the right word, but messages in MassTransit have the ability to carry ‘more’ than one contract of data.

For example, at work, some of our integration partners provide us with extra data that we need later on in the order life cycle. This data is unique to the provider. In the past this lead to the usage of some patterns I dislike such as the ‘mystery meat’ where we stuff data into a dictionary and use magic strings later to get it
back out.

public interface RegisterSalesOrderWithMysterMeat
{
    string OrderId { get; }
    //other properties
    IDictionary<string, string> MysteryMeat { get; }
}

the alternative of course is to extend your nice clean model with partner specific payload

public interface RegisterSalesOrderWithMoreStuff
{
    string OrderId { get; }
    //other properties

    //shopify stuff
    string ShopifyOneOff { get; }

    //bigcommerce stuff
    string BigCommerceOneOff { get; }
}

I am not a fan of either of these approaches. A third approach creates a message per integration partner, not a bad approach either in my book, but today I want to show of the Message Context in MassTransit, so I am going to ignore it.

Check this out

public class RegisterSalesOrderConsumer :
    Consumes<RegisterSalesOrder>.Context
{
    public void Consume(IConsumeContext<RegisterSalesOrder> context)
    {
        //normal payload
        var salesOrder = context.Message;

        IConsumerContext<RegisterShopifySalesOrder> shopifyDataContext;
        if(context.TryGetContext<RegisterShopifySalesOrder>(out shopifyDataContext))
        {
            //do stuff w/ shopifyData
            var shopifyData = shopifyDataContext.Message;
        }
    }
}

How sweet is that?!

How do you do it?

First you define your contracts with an interface rather than a class.

public interface RegisterSalesOrder
{
    string OrderId { get; }
    //other properties
}

public interface RegisterShopifySalesOrder
{
    //shopify stuff
    string ShopifyOneOff { get; }
}

public interface RegisterBigCommerceSalesOrder
{
    //bigcommerce stuff
    string BigCommerceOneOff { get; }
}

Then at your edge you have a class implement the correct interface.

public class RegisterShopifySalesOrderCommand :
    RegisterSalesOrder, RegisterShopifySalesOrder
{
    //implement the properties
}

public class RegisterBigCommerceSalesOrderCommand :
    RegisterSalesOrder, RegisterBigCommerceSalesOrder
{
    //implement the properties
}

and then publish the concrete class

bus.Publish(new RegisterBigCommerceSalesOrderCommand());

MassTransit will take care of routing the message for you, and now you can add additional content that may or may not be required. This isn’t a feature I recommend abusing, but its one more sharp tool in your toolbox.

Posted in MassTransit | 1 Comment

MassTransit and Interface Contracts

 MassTransit interface-style messages

Did you know that in MassTransit you can use interfaces for your message
contracts rather than classes? If not, you can and here is how.

Let’s take the following example:

public class RegisterSalesOrder
{
    public string OrderNumber { get; set; }
}

public class Program
{
    public static void Main())
    {
        var bus = BuildNewBus();
        bus.Publish(new RegisterSalesOrder { OrderNumber = "abc" });
    }
}

Nothing too surprising here I hope. We get our bus instance and then publish our
message. Later someone will consume it. Like so:

public class Program
{
    public static void Main()
    {
        var bus = ServiceBusFactory.New(sbc =>
        {
            //ignoring a bunch of setup
            sbc.Subscribe(subs =>
            {
                subs.Handler<RegisterSalesOrder>(msg =>
                {
                    //do stuff
                });
            })
        });
    }
}

more configuration options here

Why interfaces?

So this is great and all, but if our contract was that messages should be immutable
it would be nice to have that enforced by the compiler. But with classes that can
be tricky if we want to support being able to easily build the messages when
we need to as well. We could just use private setters, but now they are a pain
to build and would require constructor parameters which further makes
serialization a pain.

public class RegisterSalesOrder
{
    public string OrderNumber { get; private set; }
}

MassTransit support interface based contracts like this

public interface RegisterSalesOrder
{
    string OrderNumber { get; }
}

Now we have an immutable contract, and we can subscribe to this interface in
our subscription setup part of the bus. The trick is now in the publishing.
How do you create an interface and set its properties and publish it?

I simple create a class that implements the interface (outside of the contract dll). I usually make them in the publishing system as they are a private implementation detail of that system.

public class MyRegisterSalesOrder : RegisterSalesOrder
{
    public string OrderNumber { get; set; }
}

Now I can create an instance of the contract w/ ease and it can be made in whatever
way my publishing code needs it. It can be built using a ctor, a factory method,
through the container, whatever my app wants or needs. Then I can simply publish it

bus.Publish(new MyRegisterSalesOrder { OrderNumber = "bob" });

And subscribers to the interface will get the message as it conforms to the interface.

Boom.

Posted in MassTransit | 24 Comments

From IoC to require

Lately I have been working on building out my first non-trivial application with node. It has been a very interesting smashing of my brain cells. Coming from a strictly typed language and moving into a prototype based language has removed a lot of my tools from my tool belt. I can no longer ‘scan assemblies for types’, even if I had an IoC i would be forced to use normal strings rather than Type names. I also no longer have my powerful toolset of Visual Studio and ReSharper (yes its a resource hog, but its damn powerful too). But of all the changes, I think it is the lack of IoC that is hurting me the most.

Last weekend I attended a session at Houston Code Camp on “Beyond AMD” where my good friend talked about the various ways people are extending JavaScript applications. Ryan summed them up into three flavors, you can modify an instance (duck punching), you use a factory (think jQuery $.fn) or you can use a plug in model (think flatiron.js Broadway). It was a great talk that really helped to round out my understanding of developing in JavaScript land.

It wasn’t until I was really rereading through the flatiron docs that it hit me. I really have two ways to get at things. One is by attaching it to a global (it seems that the app object is the preferred one) or I can use require to locate the objects I need. Since require felt right at the time, I started to happily require my way into happiness. That is until my first refactoring that changed a file path. You see require doesn’t have an app root concept so through out my code I am calling require(‘./file’) and then deeper in a nest I have require(‘../../../file’) and different files have different paths. For a moment I thought, Aha! I know what I will do. I will add to require the ability to do something like require(‘~/someFile’) where the ‘~’ was my package root. As I thought it about it having the file system involved at all just didn’t feel right. It seems that for JS the best thing for me to do really is to just extend the ‘app’ global.

It all comes back to the fact that I don’t have a type system in the way that I am used to thinking of it. Its ok, because I can stub this out quite easily for tests. But I do believe that it ALSO means I have to stay extra on guard because I am passing around a global and depending on its presence. It will be very interesting to me to watch how this next round of coding procedes because of this. I hope to report back with more, as I get actual experience doing it. But until then, I am jumping in feet first.

-d

Side Bar: I am drawn to node because I feel it has the module problem solved well. Python has the whole 2.x vs 3.x distutils vs setuptools (easy_install vs pip) etc stuff going on. Ruby has the bundle vs gems thing going on, where node just has npm which is private by default with SEMVER support. I like this. (its still no APT-GET but it works nicely. :) )

I am also loving Sublime 2 – though I am missing VIM’s keyboard navigation.

I also, enjoyed reading this. JavaScript is tragically important. LULZ. Its funny cuz its true.

Posted in Uncategorized | 15 Comments

A story on composable systems

<warning>This is a long post that attempts to describe a positive experience leveraging multiple frameworks</warning>

TL;DR. Static Typing / IoC == AWESOME FLEXIBILITY

Recently while working at Dovetail I had the absolute pleasure to provide a solution to a customer request. We were adding SAML authentication to our product, and we wanted to provide an extensibility point to handle unknown users. By default the product would show a not authorized screen if we encountered a valid SAML assertion referencing an unknown user. This was pretty easy to setup, but as I said, we really wanted this to be extensible. What I wanted to support was redirecting the user to a different page, maybe one that a customer has specified which would give the user the information needed to request access to our application through the approved channels. That would have been pretty easy with just a configuration entry, but we decided that really wasn’t enough. We also wanted to be able to handle a request to make a user right there. Well, now we need the ability to execute some code, a configuration file isn’t going to handle that very well. Even if we kept the config file approach we would have to redirect the user to somewhere else in the app, and then figure out how to shuffle all of the required data around. :( It just didn’t feel like a solid solution.

Thankfully, FubuMVC, Bottles and StructureMap came to the rescue. FubuMVC gives us controllers that can easily take dependencies on services (nothing to fancy here, you can do this in ASP.NET MVC too). So our SAML Authentication controller (or action in Fubu land) takes in a service that acts as a policy (SuccessfulSamlAssertionPolicy) it takes a valid SAML assertion, and attempts to locate the user in the database, if it finds them, the policy logs them in, and then redirects the user to the home page. If we can’t find the user, then we invoke the UnknownUserPolicy (another service/policy thing which is injected in the SuccessfulSamlAssetionPolicy) the default implementation of this policy simply redirects them to an error page of ours, but since it’s a interface/class pair, we can easily swap that out. This is where IoC/DI/StructureMap make things really nice.

So, the above may seem a bit complex (I definitely didn’t explain it that well). So lets break it down and make it concrete. I have an interface that looks like this

public interface UnknownUserPolicy
{
    //FubuContinuation is a way to redirect the user
    FubuContinuation HandleUnknownUser(SamlAssertion assertion);
}

we ship with the following implementation

public class DefaultUnknownUserPolicy : UnknownUserPolicy
{
    public FubuContinuation HandleUnknownUser(SamlAssertion assertion)
    {
        return FubuContinuation.RedirectTo<LoginController>(c => c.Login(null));
    }
}

Super easy code, nothing too hard here. We wire it up in StructureMap using a convention, so there is really nothing else to show. Now, lets imagine we have a customer, that doesn’t want them redirected to the login page, they should instead go to: https://silly.corporate.subdomain.company.com/request_access.cfm . Using StructureMap, this is as easy as registering our policy later in the container (after the default registrations) by adding a line like this:

For<UnknownUserPolicy>().Use<CompanyXUnknownUserPolicy>();

That will override the default policy and boom! We have just customized our application for this one customer. So that’s great and all – but I want that in only ONE deployed instance of the application. I do not want to modify the base product for this customer, and this is where Bottles comes to my rescue. :)

Bottles is a framework for assisting us in loading dynamic code in a controlled and predictable manner. Its built with an IoC container in mind, but is completely agnostic of them and FubuMVC entirely. When our application starts up, we go through all the usual stuff for a .Net / IoC project. We initialize logging, spin up our container, blah, blah, blah. The one new step that we add with Bottles though, is to run through every discovered Bottle, and look for ‘StructureMap Registries’ and load them into the container. Now, a bottle is pretty much a glorified zip file holding .Net assemblies — among other things. The bottles, being a separate file from the base product, can be used to modify our existing application. In this case, we have a Customer Bottle that does one thing. It executes that above piece of SM registration code to override the base UnknownUserPolicy. :) WIN.

So, by putting all of these various tools, patterns, and frameworks together, we were able to build a solution that allows for a lot of customizability, does NOT require us to change our base product (would have loved to have had this at the bank), and I think truly encapsulates the changes that customizations for a customer can bring into one easily deployable unit.

There are a LOT of things going on in this post, we have programming to interfaces, we have making small classes that do one thing well, we are using IoC, we are using a web framework that makes redirecting deep in the bowels of the app easy and testable, we have composition, dynamic code loading and a lot of ‘abstractions’ (Yup, learned about those at a young age ;) ). Using all of these has allowed us to add a lot of seams to our application, and it’s this kind of power that keeps our application nimble and easily customizable for any customer.

Posted in Uncategorized | 8 Comments

Slice of Life: Converting my Personal Site

Over the last few months I have been having a lot of fun converting my personal site (http://drusellers.com) from a pure static html site, to one that uses a back end server side language.

When I first started the main purpose was to learn a little more about python. So I started off using Flask, a micro framework for python. Flask is a lot like Sinatra for ruby and the comparison was a lot of fun because my good friend Ryan Rauh (RyRy) was writing a site in Sinatra at the time so we were able to compare and contrast the two approaches quite easily.

As I learned more about flask and all that it could do, I was impressed by how much I could do with so little. It served as a solid reminder that we should strive for simpler solutions.

In addition to learning python I also took the time to dive into LESS. Organizing the CSS content of applications has always been difficult for me. Finally, with LESS I had variables and the ability to nest selectors. Basically, all of the things that I have wanted CSS to do for a very long time. I started out using the runtime compilation modes of LESS, but as I learned more I eventually switched to running the watch mode on the compiler and then stripping that functionality out of the app. Right now, I really like this approach. It feels more like PROD vs DEV, but I still have the ability to iterate quickly. The real choice to use LESS, was that the popular CSS framework from Twitter called Bootstrap had just launched. By studying their approach and trying to deconstruct things I have learned a lot about CSS and its application to better CSS approaches.

But as with all things in the technical world, a change was on the horizon. That change was SASS/SCSS. RyRy read a post somewhere comparing SCSS and LESS and he came away with the impression that SCSS RULED, and LESS DROOLED. This was one of those moments, where I gave RyRy a stern look and then sat down to start converting my website from LESS to SCSS, because when the guy you ask all of your questions too, changes directions sometimes its just easier to go with the flow. Thankfully it wasn’t that hard, allowed me to revisit my CSS and improve things further.

Around the same time, I discovered semantic.gs, a SCSS friendly grid system, finally I can get rid of the BS classes like span-4 and what not that have been plaguing me since I first found blueprint.css and 960grid. Whoot! I have been able to further clean up the website’s CSS approach.

Well, of course the project can come to a close quite that simply. After improving my CSS and getting an understanding of python, I of course, had to completely rebuild it something new and shiny. Damn, my attention span.

So, yeah. Node.js the new shiny language/framework. My JavaScript skills have always suffered, so I rationalized changing my backend code to JavaScript as a means to improve my JS skillset. So, I converted my site again, learned a lot about JavaScript in the process, melted my brain trying to get things to work in this under powered language (under powered because I am used to my language providing much more to me).

So now my site is running Node.js – its a whole lot cleaner and easier to work on. I love how simple the underlying code is, and I have really learned a lot about some of the new languages and frameworks out there.

Posted in Uncategorized | 1 Comment