Wrapping synchronous code in a Task returning method

Imagine you have an interface.

Now imagine you want to implement this interface, but the code to go in there is not actually asynchronous. Neither is it cpu-intensive and requiring it’s own thread. It is just a regular piece of synchronous code.

There are three ways to do this that I know of.

So what is the difference between these three?
In terms of the IL being generated, the answer is quite a lot. In terms of relative performance though, the following falls strictly into the category of extreme micro-optimization.

The code

The first implementation is the most optimal approach. It turns out that Task has an internal constructor that takes a result. So the static FromResult() method is just a public wrapper around that constructor which returns a completed Task with your value. Task<T> is then cast to Task and off we go.

I find the second approach to be the easiest to read because you just need your async and no weird faux-return. This one actually generates quite a bit of IL. You get a full state machine created, it gets initialized and then executed.

That is a lot of generated code just to save me explicitly returning a Task!

The third option generates the code for the lambda, then passes it off to Task. The task is then handed to the scheduler and what happens next will depend on your scheduler. While this option is lighter on code-gen, the hand-off process makes this the slowest option.

Performance

I ran a couple of quick and dirty performance checks over these three. In each case firing off the method 100,000 times and blocking on the result in a tight for-loop.
The first implementation runs in about 2ms, the second in about 15ms and the third in about 170ms. Like I said, firmly in the realms of micro-optimization.
Something interesting to note though is that if you repeat the test with the debugger attached, the third option blows out to more like 30000ms! I guess there is some more context switching going on with the debugger attached which affects the performance.

Conclusion

Ideally you want to avoid doing any of this. Your best option is to support both synchronous and asynchronous implementations where appropriate. In practice I am finding that I often need to handle this wrapping process and so it is handy to understand exactly what I am asking of the compiler when I do. It may be a micro-optimization but it costs me nothing to do it the best way!

Interfaces again

In my recent post about interfaces I showed one approach to breaking up and consuming your interfaces that I am finding interesting at the moment. The idea was born out placing restrictions on myself and trying to be explicit about my dependencies. I wanted to structure the code in a way where I couldn’t get lazy and just start firing off database code from anywhere in the codebase.

In an earlier iteration of that same thought process I had a different structure that was quite interesting in its own right. I don’t think either is better than the other. But I do find them both interesting and hopefully someone reading this does as well.

So what is my second example for you? Well again it involves tricks of code organisation to change the way the functionality of a class is consumed. This one is more about taking a class that implements multiple interfaces but exposing them in a more structured way. Again I will work in the repository space. For the same reasons as last time, it is a service type we all understand and that we have all seen go wrong at some point. Don’t read this as a guide on how you should structure code it is merely a thought exercise at this point.

So in this case we take a dependency on the large service class, the repository, but even though that class potentially implements a lot of code we use explicit interfaces and getters to cut down the surface of the class and help a consumer find their way through it.

Unlike my previous article this doesn’t give you much in your testing or make your code more explicit about it’s dependencies. It’s doesn’t do as much for refactoring or replacing implementations of individual interfaces. It is all about IntelliSense really and making a class which, for whatever reason needs to be this complex, a little more manageable.

Going back to where all this started, I am thinking a lot lately about how I manage abstraction. Where my interfaces sit, what boundaries they have and how their implementations are structured. It is nice to take a step back like this at times and look at our tools, ask what else can I do with this and how else “could” it look.

There are a lot of opposing opinions out there, opinions that are constantly changing and evolving. In the end we need to find the processes that are working for us, our teams and our codebase. Situations are never the same, so learn as much as you can and apply it where it makes sense.

In that spirit it must be about time for another “Learn Something New” post.

Fun with Explicitly Implemented Interfaces

I’ve picked up a new coding technique recently. I’ve always been a bit uncomfortable with the 1:1 relationship between class and interface. I’ve also been uncomfortable with large service classes like a repository. When you take a dependency on a large service interface you are hiding all the details about what you are actually dependent on, which can cause you problems down the line with your tests and refactorings.
Repositories in particular quickly escalate to large numbers of functions. If I am working on tests for a piece of code that takes a dependency on that repository I have no option other than to read the code to see what methods it is calling. Tedious.

So when I stumbled across the long forgotten (by me) practice of explicitly implementing an interface I saw potential to take a fresh look at some of these concerns.

I still don’t know exactly where this train of thought will take me but I’d like to throw it out there and see if it gets the gears turning for anyone else. I am using this heavily in a new personal project, so by the end of it I should have a good idea of whether it has helped or hindered me.

A quick refresh on explicitly implementing and interface.

When you implement an interface like this (note the interface name in front of the method name) then it is only accessible when your instance of SqlRepository is cast as an IsEmailAlreadyInUse. Through a dependency injection container, which preferably includes an AsImplemetedInterfaces() option, this is very easily wired up.

Notice how the SqlRepository is internal, this is saying that you shouldn’t be giving out instances cast as this type. You should be handing out a single instance (per appropriate lifetime scope) cast as its various interfaces.
With this done, your code that is applying business logic around these persistence calls suddenly needs to be explicit about what functions it needs. It can no longer say “give me a repository and I will do what I please with it”

When you are writing tests (whether before or after writing the implementation) it becomes very obvious what your code is actually dependent on. Which makes it easier to mock and easier to refactor or replace.
An additional benefit is that if you end up with a lot of dependencies you should be stopping to consider if your pushing too much logic into a single code unit. Perhaps things can be broken down further and some reusability gained.

In my personal application I do all this in two code files. I have one where I define all my interfaces and one where I implement them all. Overall the approach is working well for me so far though, it has not been proven to be a burden to organise the code. I have very simple integration tests that ensure each command is doing what I expect it to. All my “complicated” logic is then easily unit tested with FakeItEasy.

Finally I chose the repository as an example because it is a pattern I see often which could really benefit from a new approach. It is by no means the only example. At the same time don’t just go breaking interfaces apart for the sake of it, use them correctly as your units of abstraction.

There is another interesting pattern you can use when implementing your interfaces like this. I will hopefully go into that next time.

Avoid branching

One thing I have noticed recently is that I like to avoid branching. Now what I am talking about here is not branching at a code level. I am talking about mental branching as I am writing code, following other trains of thought or investigating problems whose answers are not immediately necessary.

It seems obvious, but after following along some conversations on twitter recently I think I need to post more, even for things I find obvious. So…

About a meter from my desk I have a whiteboard.

The sections and structure of it don’t really matter, they are what makes sense for my project and the team I am working with.

Almost every note on that board is a branch I could have gone down that would have caused me to stop what I was in the middle of doing and focus on the branch. I find this sort of context switching very disruptive.

To be clear about the whiteboard this isn’t some sort of quasi-agile project workflow (we use trello for that), these are not story cards and if someone calls me up and says “we have some important thing you need to do” then I branch. This is not about sitting in a programming utopia where I am uninterruptable, it is about not interrupting myself. These notes are questions and tasks that need to be answered or completed but ones that can wait. Here are some examples

“Should we avoid making searches we know to be bad?”
”Should we write a $0 tax record or leave the tax record off?”

The domain I am working in at the moment involves talking to a lot third party APIs and integrating them into the internal domain model. So inevitably there is a lot of mapping that goes between the response from the API and the internal model, both are quite complex and different from each other.

So while I am sitting down with a list of 50 properties I need to go though and I come across one where I do not know the business answer to the problem, I write it on a note, stick the note on the board and move on.
Then once I am done, I go to the board and read through through the notes.

Sometimes with the extra knowledge I have gained since writing the note I can now answer it myself.
Sometimes I can ask someone else on the team and they answer it.
Sometimes I can research within the codebase for the answer.
Sometimes I need to talk to the product owner.

That is a lot of “sometimes” and it is precisely why I defer that chain of “sometimes” until the last possible moment.

Enabling sessions in Nancy

As you may know, AppHarbify is built with Nancy. One of the reasons I decided to build it in Nancy, other than the fact that Nancy is awesome, was that I wanted to put together a real project that can be used as an example of Nancy in action. All the code for AppHarbify is available on GitHub.

To go with that I am planning to put together some blog posts talking about various aspects of the code.

To start with I am looking at sessions.

Getting Started

Nancy ships with a single session provider implemented, CookieBasedSessions. You can of course add your own.

This provider stores the session, encrypted, in the users cookies. Which is really not too bad of a solution to get started. You are up and running with a single line of code added to your ApplicationStartup method in your Bootstrapper.

Once enabled, you can simply access the Session property on Request.

Request.Session["Key"]

Now you don’t want to store too much data in a cookie-based session like this, as every request is sending the data back across the wire. Also it is theoretically possible the encryption could be broken. Side note: You can control the encryption provider with an optional second parameter to .Enable(). If you do not, then a new key is generated each time the app starts, invalidating all existing sessions.

Testing

If you do any work with sessions, you are likely to need to test them eventually. While the mechanism is a bit awkward, it is essentially pretty easy. My preferred method is to attach an event to the .Before pipeline in your testing Bootstrapper that injects the required session into the request.

By adding this simple extension method and calling it on your Bootstrapper whenever you want to test a route that needs session information, you can very simply abstract away your real session storage mechanism without adding more layers of abstraction to your actual codebase.

Future

While AppHarbify is currently running along fine using these cookie based session, for the reasons I have stated above it is not ideal. So the plan is to write Redis based session mechanism and take advantage of the easily installed Redis add-on at AppHarbor. Of course this code will be open-source and released independently of AppHarbify as a nuget package. So watch out for that!