After about 25 years or so in the software industry, I finally founded my own business named JasperFx Software last year at about this time with the general strategy of building a services and product company around the “Critter Stack” tools (Marten, Wolverine, Weasel, and soon to be some others) as well as any or all consulting opportunities around server side .NET development or automated testing. After a year, it’s time for a little retrospective.

How’s it going?

Everything has taken longer than I’d hoped, and technical or company milestones have taken longer than I wanted. To quote the old adage, “it’s darkest right before the dawn.” I was so discouraged about the company right before Christmas that I was strongly considering giving up. Then JasperFx signed a couple big deals that gave me enough space and revenue to keep going, and even allowed JasperFx to bring on Babu Annamalai as a consultant and collaborator.

I’ve long been telling folks who ask me how it’s going that the technology side looks good, but the business is going just well enough to be encouraging but not well enough to feel confident yet. Right now I think I can finally say the business is strong enough to be thinking much more about how to grow and become sustainable than working on exit strategies. To put it more succinctly, I think that potential clients can trust that JasperFx Software is going to be around as a technical partner.

The big goals for this next year are to grow enough to be able to bring on full time colleagues for round the clock support and to continue to grow the “Critter Stack” platform. A big part of that is the planned “Critter Stack Pro” and “CritterWatch” commercial add on products I’m hoping will be demonstrable by the end of the 3rd quarter this year.

Client Work Highlights

JasperFx Software doesn’t exist without its clients — and we could always use more! Here’s some of the highlights of our client work in the past year:

• By my count just now, we have worked with clients headquartered in six different countries so far, but I’ve already lost track of which countries our client contacts are located in
• Event sourcing is relatively new, so there’s been a lot of engagement with various clients about the best ways to model their domains with events or how to best use projections for read or write models
• I’ve gotten to work very closely with a client building an IoT system using event sourcing with Marten, messaging and HTTP services with Wolverine, and Rabbit MQ. That work has led to several improvements especially with Wolverine that have helped reduce repetitive code
• JasperFx has helped several clients set up automated testing strategies and mentored teams on unit testing practices. Honestly, I think this might be the one way in which we’ve delivered the most “bang for the buck” for our clients. Automated testing strategies and designing for testability are primary areas of expertise within JasperFx Software — and that might be a little lacking in the larger software community these days
• Multiple clients have complicated requirements for multi-tenancy in their systems, and that’s mightily pushed forward capabilities for both Marten and Wolverine in reaction. The specific highlights have been dynamic multi-tenancy in both tools, multi-level multi-tenancy, HTTP integration, and an effective virtual actor capability per tenant for Wolverine
• Helped several clients with support contracts with JasperFx Software to use the tools more effectively. This has typically involved issues around transactional integrity, using a transactional outbox, error handling, and generally how to make systems be more robust or more performant
• Concurrency issues are quite common, and JasperFx has worked with several of our customers to either make their systems more resilient to concurrency or to reduce potential issues around concurrency through design changes. This has been a common enough issue that I’m going to build out a new conference talk gathering the issues and possible solutions called “Surviving Concurrency in Event Driven Architectures”
• We greatly improved Marten’s integration behind GraphQL endpoints using Hot Chocolate for a client, and we’re continuing on with strategies to use Wolverine for GraphQL mutations with Hot Chocolate
• JasperFx delivered an early release of the forthcoming “Critter Stack Pro” tools for a client to greatly improve their ability to scale up to very large numbers of expected event data by better distributing load throughout an application cluster
• Wolverine got an MQTT integration as the request of a JasperFx client
• I helped a client kick off a big new initiative (that will ultimately be built with Ruby, so that’s been interesting) by facilitating multi-day Event Storming workshops
• Helping multiple clients evaluate their current application code looking for areas of concern and potential remediation or modernization efforts

If you have a problem, and trust me, you can easily find us, maybe you can engage with JasperFx Software for your own development efforts with an email to sales@jasperfx.net. Or by contacting me directly through Discord, what’s left of Twitter, or wherever.

The State of the Critter Stack

Most of the time I’m focused on what is not already good, soft spots, flaws, outright bugs, and holes in the capabilities of Marten or Wolverine. Occasionally folks pop into our Discord channels just to say positive things, but most of the interactions there or on GitHub are with folks who are having trouble with something at that very moment. Last week I spent some serious time comparing the Critter Stack’s capabilities to some other toolsets for Event Driven Architecture in the .NET ecosystem and a bigger offering in the JVM ecosystem. And you know what?

• Marten is already the most robust and feature rich toolset for Event Sourcing in the .NET ecosystem. Sure, you can roll the barebones basics for Event Sourcing yourself, but there are a lot of significantly challenging technical issues around projected state data, subscriptions to event data, concurrency protections, and instrumentation that Marten already supports today in a robust way that you would otherwise have to build out yourself. Likewise, you could cobble a lot of what Marten already does today with various libraries (none of which are documented as well or as widely used as Marten) or other event stores, but you’d still end up writing a lot more non-trivial code to glue it all together and fill in holes than you would by just using Marten.
• Wolverine is a unique server side application framework that can be used to dramatically reduce the amount of boilerplate code that is so common in server side .NET development. Moreover, it’s the perfect toolset for really using the “vertical slice architecture” approach in a simpler way. And if used idiomatically, Wolverine can help you structure your code for easy unit testing by separating your application logic from infrastructure concerns without ridiculously high ceremony Hexagonal/Clean/Onion Architectures.
• Used together, the Critter Stack is arguably the most feature complete solution for Event Driven Architecture in .NET today — but I’ll weasel this a bit by saying that Actor-based platforms are so conceptually different in approach that I wouldn’t do a straight up comparison
• The Critter Stack tools can lead to much better testability, both for unit testing and for integration testing with infrastructural elements, that help our users deliver software faster and with more confidence. I believe that the Critter Stack’s approach and support for automated testing has no peers in the .NET space.

The Critter Stack suite is going to grow this year with commercial add on libraries for increased scalability and with a custom monitoring and management tool codenamed “CritterWatch.” If all goes according to plan (and it won’t), the Critter Stack is going to also grow this year with event sourcing alternatives based on at least Sql Server as the underlying persistence with CosmosDb and/or DynamoDb following afterward.

How’d I get here?

Hey, this section is going to get into some pretty serious TMI, so feel free to skip any of this.

For various reasons, maybe because I’m terrible at organizational politics, disinterest in what I was working on, bad luck, or all of the above, I never managed to find a role or a company where I felt like it was my shop and I was happy right where I was at. A noticeable trend that always frustrated me was that I was frequently much better known and more professionally respected in the outside world that where I happened to be employed at the moment:

I’ve known for a long time that I enjoyed my OSS work building shared libraries and frameworks for other developers much more than what I happened to be doing for my real job. What I’ve long wished I could do was to was get to build development tools, preferably where I was one of the primary drivers of the company and I had a major hand in driving the vision. I thought I’d absolutely blown my chance when a very ambitious, prior project failed miserably years ago, and I had been admittedly pretty adrift in my career in the following years.

I had a couple possible opportunities to join Microsoft in their Dev Div division when I was younger, but there was always some personal reason not to take those positions. I’ve occasionally wished that would have worked out, but that was ages ago.

A couple years ago I told a therapist that I thought I was going through a mid-life crisis, and he laughingly told me that I just had some as yet unfulfilled ambitions. About the same time I got a message from another developer then working at a software tools company asking why we weren’t already monetizing Marten because he thought it was already better than certain commercial offerings. Those two incidents, other friends founding their own company at the same time, plus a lot of encouragement from my wife, and a few other breaks led me to finally go off and take a chance on myself and start JasperFx Software. I won’t lie and say it’s been all rainbows and unicorns and that I haven’t struggled mightily with stress this past year, but it’s trending upward right now and I love being able to roll out of bed knowing that I’m working on my technical vision (for at least some of the day!) or working to help clients who respect my input and contributions to their work.

I’ve been occasionally writing posts about old design patterns or techniques that are still occasionally useful despite the decades long backlash to the old “Gang of Four” book:

• The Lowly Strategy Pattern is Still Useful
• The Occasionally Useful State Pattern
• The Decorator Pattern is sometimes helpful
• Linked Lists in Real Life (this post)

A linked list structure is a simple data structure where each element has a reference to the next element. At its simplest, it’s no more than this single linked list implementation:

public abstract class Item
{
    public Item Next { get; set; }
}

Now, I got into software development through Shadow IT rather than a formal Computer Science degree, so I can’t really get into what Big O notation stuff a linked list gives you for sorting or finding or whatnot (and don’t really care either). What I can tell you that I have occasionally used linked list structures to great effect, with at least two samples within the greater “Critter Stack” / JasperFx codebases.

For the first example, consider the complex SQL generation from this LINQ query in Marten using Marten’s custom “Include Related Documents” feature:

        // theSession is an IDocumentSession from Marten
        var holders = await theSession.Query<TargetHolder>()
            .Include<Target>(x => x.TargetId, list, t => t.Color == Colors.Green)
            .ToListAsync();

Behind the scenes, Marten is generating this pile of lovely SQL:

drop table if exists mt_temp_id_list1; 
create temp table mt_temp_id_list1 as (select d.id, d.data from public.mt_doc_targetholder as d);
 select d.id, d.data from public.mt_doc_target as d where (d.id in (select CAST(d.data ->> 'TargetId' as uuid) from mt_temp_id_list1 as d) and CAST(d.data ->> 'Color' as integer) = $1);
  $1: 2

If you squint really hard, you can notice that Marten is actually executing four different SQL statements in one logical query. Internally, Marten is using a linked list structure to “plan” and then generate the SQL from the raw LINQ Expression tree using the Statement type, partially shown below:

public abstract partial class Statement: ISqlFragment
{
    public Statement Next { get; set; }
    public Statement Previous { get; set; }

    public StatementMode Mode { get; set; } = StatementMode.Select;

    /// <summary>
    ///     For common table expressions
    /// </summary>
    public string ExportName { get; protected internal set; }

    public bool SingleValue { get; set; }
    public bool ReturnDefaultWhenEmpty { get; set; }
    public bool CanBeMultiples { get; set; }

    public void Apply(ICommandBuilder builder)
    {
        configure(builder);
        if (Next != null)
        {
            if (Mode == StatementMode.Select)
            {
                builder.StartNewCommand();
            }

            builder.Append(" ");
            Next.Apply(builder);
        }
    }

    public void InsertAfter(Statement descendent)
    {
        if (Next != null)
        {
            Next.Previous = descendent;
            descendent.Next = Next;
        }

        if (object.ReferenceEquals(this, descendent))
        {
            throw new InvalidOperationException(
                "Whoa pardner, you cannot set Next to yourself, that's a stack overflow!");
        }

        Next = descendent;
        descendent.Previous = this;
    }

    /// <summary>
    ///     Place the descendent at the very end
    /// </summary>
    /// <param name="descendent"></param>
    public void AddToEnd(Statement descendent)
    {
        if (Next != null)
        {
            Next.AddToEnd(descendent);
        }
        else
        {
            if (object.ReferenceEquals(this, descendent))
            {
                return;
            }

            Next = descendent;
            descendent.Previous = this;
        }
    }

    public void InsertBefore(Statement antecedent)
    {
        if (Previous != null)
        {
            Previous.Next = antecedent;
            antecedent.Previous = Previous;
        }

        antecedent.Next = this;
        Previous = antecedent;
    }

    public Statement Top()
    {
        return Previous == null ? this : Previous.Top();
    }

    // Find the selector statement at the very end of 
    // the linked list
    public SelectorStatement SelectorStatement()
    {
        return (Next == null ? this : Next.SelectorStatement()).As<SelectorStatement>();
    }

    // And a some other stuff...
}

The Statement model is a “double linked list,” meaning that each element is aware of both its direct ancestor (Previous) and the next descendent (Descendent). With the Statement model, I’d like to call out a couple wrinkles that made the linked list strategy a great fit for complex SQL generation.

First off, the SQL generation itself frequently requires multiple statements from the top level statement down to the very last statement, and you can see that happening in the Apply() method above that writes out the SQL for the current Statement, then calls Next.Apply() all the way down to the end of the chain — all while helping Marten’s (really Weasel’s) batch SQL generation “know” when it should start a new command (see NpgsqlBatch for a little more context on what I mean there).

Also note all the methods for inserting a new Statement directly before or after the current Statement. Linked lists are perfect for when you frequently need to insert new elements before or after or even at the very end of the chain rather than at a known index. Here’s an example from Marten that kicks in sometimes when a user uses the LINQ Distinct() operator:

For more context if you’ve lived a more charmed life and have never run across them, here’s an explanation of Common Table Expressions from PostgreSQL (this is commonly supported in other databases).

internal class DistinctSelectionStatement: Statement
{
    public DistinctSelectionStatement(SelectorStatement parent, ICountClause selectClause, IMartenSession session)
    {
        parent.ConvertToCommonTableExpression(session);

        ConvertToCommonTableExpression(session);

        parent.InsertAfter(this);

        selectClause.OverrideFromObject(this);
        var selector = new SelectorStatement { SelectClause = selectClause };
        InsertAfter(selector);
    }

    protected override void configure(ICommandBuilder sql)
    {
        startCommonTableExpression(sql);
        sql.Append("select distinct(data) from ");
        sql.Append(Previous.ExportName);
        sql.Append(" as d");
        endCommonTableExpression(sql);
    }
}

When Marten has to apply this DistinctSelectionStatement, it modifies its immediate parent statement that probably started out life as a simple select some_field from some_table query into a common table expression query, and appends the DistinctSelectionStatement behind its parent to do the actual SQL distinct mechanics.

In this particular case of the SQL generation, it’s been frequently necessary for a Statement to “know” about its immediate ancestor, as you can see in the sample code above where the DistinctSelectStatement picks off the ExportName (the CTE name of the preceding statement) to use in generating the right SQL in DistinctSelectStatement.Apply().

For another example, both Marten and Wolverine use a runtime code generation model to build a lot of their “glue” code between the framework and user’s application code (you can see an example of that runtime code generation in this post). One of the core conceptual abstractions in the shared code generation model is the abstract Frame class which roughly equates to logical step in the generated code — usually just a single line of code. During the code generation process, the Frame objects are assembled in a single linked list structure so each Frame.

When actually writing out the generated source code, a typical Frame will write its code, then tell the next Frame to write out its code and so on — as shown by this sample class:

// This is from Wolverine, and weaves in code
// to add selected tags from incoming messages to
// message handlers into the current Open Telemetry Activity
public class AuditToActivityFrame : SyncFrame
{
    private readonly Type _inputType;
    private readonly List<AuditedMember> _members;
    private Variable? _input;

    public AuditToActivityFrame(IChain chain)
    {
        _inputType = chain.InputType()!;
        _members = chain.AuditedMembers;
    }

    public override IEnumerable<Variable> FindVariables(IMethodVariables chain)
    {
        _input = chain.FindVariable(_inputType);
        yield return _input;
    }

    public override void GenerateCode(GeneratedMethod method, ISourceWriter writer)
    {
        writer.WriteComment("Application-specific Open Telemetry auditing");
        foreach (var member in _members)
            writer.WriteLine(
                $"{typeof(Activity).FullNameInCode()}.{nameof(Activity.Current)}?.{nameof(Activity.SetTag)}(\"{member.OpenTelemetryName}\", {_input!.Usage}.{member.Member.Name});");

        // Tell the next frame to write its code too!
        Next?.GenerateCode(method, writer);
    }
}

Where the linked list structure really comes into play with the source generation is when you need to wrap the inner Next Frame with some kind of coding construct like a using block or a try/finally block maybe. Here’s an example of doing just that where the following CatchStreamCollisionFrame places a try/catch block around the code generated by the Next frame (and all of the other frames after the Next frame as well):

// This is the actual middleware that's injecting some code
// into the runtime code generation
internal class CatchStreamCollisionFrame : AsyncFrame
{
    public override void GenerateCode(GeneratedMethod method, ISourceWriter writer)
    {
        writer.WriteComment("Catches any existing stream id collision exceptions");
        writer.Write("BLOCK:try");
        
        // Write the inner code here
        Next?.GenerateCode(method, writer);
        
        writer.FinishBlock();
        writer.Write($@"
BLOCK:catch({typeof(ExistingStreamIdCollisionException).FullNameInCode()} e)
await {typeof(StreamCollisionExceptionPolicy).FullNameInCode()}.{nameof(StreamCollisionExceptionPolicy.RespondWithProblemDetails)}(e, httpContext);
return;
END

");
    }

The ugly generated code above will catch a Marten exception named ExistingStreamIdCollisionException in the generated code for a Wolverine.HTTP endpoint and return a ProblemDetails result explaining the problem and an HTTP status code of 400 (Invalid) instead of letting the exception bubble up.

By having the linked list structure where each Frame is aware of the next Frame, it makes it relatively easy to generate code when you need to wrap the inner code in some kind of C# block structure.

Summary

I spent a lot of time as a kid helping my Dad on his construction crew and helping my grandfather on his farm (you can’t possibly imagine how often farming equipment breaks). Both of them obviously had pretty large toolboxes — but there’s some tools that don’t come out very often, but man you were glad you had them when you did need them. The average developer probably isn’t going to use linked lists by hand very often, but I’ve found them to be very helpful when you need to either model a problem as outer/inner handlers or ancestor/descendents. Linked lists are also great when you need to be able to easily insert items into the greater collection relative to another item.

Anyway, dunno if these examples are too involved or too specious, but there the only two times I’ve used a linked list in the past decade.

I hope it’s obvious, but the JasperFx Software logo is meant to be a tractor tire around a cattle brand. The company name and logo is a little tribute to my family heritage, such as it is:)