LazyCache: Caching Service for ObjectCache

LazyCache ObjectCacheI recently blogged about in-memory caching while I was looking for a library to sit on top of .NET ObjectCache or MemoryCache.

Alastair Crabtree commented on my post, suggesting I take a look at this LazyCache library.

So I figured I would take my existing demo application and port it to using LazyCache.

As with most of my posts, all the following code is available as a demo application on GitHub.

This demo console app is going to show currency exchange rate between USD and CAD for a given day.

LazyCache

Lazy cache is a simple in-memory caching service. It has a developer friendly generics based API, and provides a thread safe cache implementation that guarantees to only execute your cachable delegates once (it’s lazy!). Under the hood it leverages ObjectCache and Lazy to provide performance and reliability in heavy load scenarios.

Since it uses ObjectCache under the hood and by default it will use MemoryCache.Default.  It has all the expiring features of ObjectCache.

This means you can specify a CacheItemPolicy, which allows you to expire on a specifc DateTimeOffset, Timespan Expiration, as well as gives you Update/Remove callbacks.

So for this demo, I’m only going to simply use the Timespan expiration for invalidating a cached item after 30 seconds.

Demo

First we can start off by creating a new instance of an CachingService.

Next, I want to create a method that is going to query for the exchange rate. But before it does, I want to check the cache to see if it exists.

The beauty with of LazyCache is the GetOrAdd method which returns the existing item from your cache or calls the provided delegate Func<T> which will return the object you want to cache.

Now to write this all up, I’m going to take a date as input from the console application and have it invoke our GetCurrencyRate(DateTime).

Result

Now when we run our application, we can see that if we request the same date, within the last 30 seconds, we will hit the cache instead making our HTTP call.

ObjectCache

  1. Requested 2016-01-01, 2016-01-02, 2016-01-03, 2016-01-04, all of which were fetched from HTTP service.
  2. Request 2016-01-01 which is fetched from the HTTP service because it exceeded 30 seconds between the first call for that date.
  3. Request 2016-01-04 which returned from cache.

More

The other interesting aspect of LazyCache is that since it can take an ObjectCache in it’s constructor, this opens the door to using it with Redis ObjectCache.

Let me know if you have any comments related to LazyCache or other caching libraries in comments or on twitter.


Source Code

GithubThe source code for this demo is available on GitHub.

In-Memory Caching with Foundatio

In-Memory CachingI was recently looking for a simple in-memory caching library that sat on top of ConcurrentDictionary.  I didn’t have many requirements other than it needing to be thread safe and and had some expiry policy built-in.  I’ve used .NET MemoryCache before, but figured there likely had to be something simple else already built.

My search led me to Foundatio:

Pluggable foundation blocks for building distributed apps.

Turns out Foundatio was created for building Exceptionless.  I’ve blogged about Exceptionless before, which is a real-time error and logging .NET and Javascript.

Basics

Caching in it’s various forms (in-memory, distributed) is simply about storing a copy of the data in a way that improves performance.  This could be data from a web service, database, or any other call that involves reading data that rarely changes but is read/queried often.

Foundatio

First thing will be to get the latest NuGet package.

PM> Install-Package Foundatio

There are many other components that Foundatio provides besides Caching, such as: Queues, Locks, Messaging, Jobs, File Storage, Metrics and Logging.  I haven’t dug into any of these other areas yet, but once I do, you can expect a blog post.

In-Memory Caching Demo

As with most of my posts, all the following code is available as a demo application on GitHub.

This demo console app is going to show currency exchange rate between USD and CAD for a given day.

Since historical exchange rates don’t change, there is no point in making an HTTP call for a day that was already queried.

Also, one really cool feature I’ll show, is that you can set the max number of items in your cache.

So for this demo, I’m only going to keep the last 3 exchange rates by date in cache.

First we can start off by creating a new instance of an InMemoryCacheClient and setting it’s MaxItems property to 3.

Next, I want to create a method that is going to query for the exchange rate, but before it does, I want to check the cache to see if it exists.

The key for our cached object is going to be the date.  If the key does not exist in the cache, then we will make our HTTP call, get the results and cache it.

Now to write this all up, I’m going to take a date as input from the console application and have it invoke our GetCurrencyRate(DateTime).

Result

Now when we run our application, we can see that if we request the same date, within the last 3 requests, we will hit the cache instead making our HTTP call.

result

  1. Requested 2016-01-01, 2016-01-02, 2016-01-03, all of which were fetched from HTTP service.
  2. Requested 2016-01-01 again, which was pulled from cache.
  3. Requested a new date 2016-01-04 which was fetched from the HTTP service.
  4. Requested 2016-01-02 again, however since it is no longer the last 3 requested (2016-01-03, 2016-01-01, 2016-01-04) it has to fetch from the HTTP service.

More

There are other interesting CacheClient’s such as a hybrid Redis + InMemory cache client that I’m looking forward to exploring in Foundatio.

Let me know if you have any comments related to Foundatio or other caching libraries in comments or on twitter.


Source Code

GithubThe source code for this demo is available on GitHub.

Octopus Deploy in Your Cake (C# Make)

Octopus DeployI’ve looked at using Cake (C# Make) for build automation in C#.  The basics were to compile a solution/project using MSBuild and then run our automated tests with xUnit.

Another common set of tasks that are performed in a build pipeline are:

  • Create a NuGet package
  • Push the NuGet package to Octopus Deploy
  • Create an Octopus Deploy Release

NuGet

First thing we need to do is to create a NuGet package.  You have a couple options here, one is to create a nuspec and invoke the Nuget.exe to create your package.  I’m going to choose an alternative which is to use the built-in Nuget support to generate our NuGet package all within code.

I’ve added a new “Pack” task which is called from our “Default” task.  This task will create our NuGet package when we run our build.ps1

Now when we run our build, we can see the Pack task was created our NuGet package: “CakeDemo.0.0.0.1.nupkg”

pack

Octopus Deploy

Cake has built-in support for Octopus Deploy.  To get started, you need to include the OctopusTools in your build.cake file.

#tool "nuget:?package=OctopusTools"

We can use the OctoPush method for pushing your newly created NuGet package to the Octopus Deploy NuGet Server.

Create Release

Now that our NuGet package has been pushed to Octopus Deploy, we can create a release using the OctoCreateRelease method.

To tie this all together, we need to make sure that our Default task will run our OctoPush and OctoRelease tasks.  Here is our final build.cake file

Now when we run our build we can see that our Octopus Deploy release was created.

result

More

There are a ton of built-in tasks and the Cake documentation is really good.  Hopefully you can see the benefits of having a build script in code which can be version controlled and run anywhere.

Let me know if you have any comments related to Cake or any other build automation tooling either in comments or on twitter.


Source Code

GithubThe source code for this demo is available on GitHub.