CategoryMongoDB

Don’t worry, Heimdall will watch over all your microservices.

TL;DR : I wrote a service registry tool, named Heimdall, go and fork it!

Long version: almost every time I am working on a piece of code I get stuck on something and after a while I get new ideas for new projects. This may lead to a huge number of useless git repos, each one with a partially functional software, but it also pushes me to work on new things each day.

This time I was working on a super-secret project (that I will of course share very soon) based on a nice microservices architecture and I soon realized I needed some kind of Service Registry. The project was quite small so I was not really interested in a complex tool like a router with load balancing functions or similia so I decided to code the thing myself.

For the ones of you that don’t know what a Service Registry is and what it does, allow me to give you some context.
Imagine you’re a client that needs to consume some APIs. You could of course use a configuration file for storing the endpoints but in case you’re cloud-based, urls can change often.

Also, what if you want some nice features like multiple instances, autoscaling and load balancing?

The answer is simple: use a registry! 

Every service will register itself during initialization, allowing clients to query the registry and know the endpoint (possibly the best one).

I found this concept pretty useful so I decided to create a poor man’s version myself, using ASP.NET Core, MongoDB and React and I named it Heimdall, the guardian god of the Norse mythology .
The list of features for now is very scarce, you can just register a service, add/remove endpoints and query, but I have a full roadmap ready 🙂

Oh and I also added help pages using Swagger !

Unit testing MongoDB in C# part 4: the tests, finally

More than a year. Wow, that’s a lot, even for me! In the last episode of this series we discussed about how to create the Factories for our Repositories. I guess now it’s time to put an use to all those interfaces and finally see how to unit test our MongoDB repositories 🙂

Remember: we are not testing the driver here. The MongoDB team is responsible for that. Not us. 

What we have to do instead is to make sure all our classes follow the SOLID principles and are testable. This way we can create a fake implementation of the low level data access layer and inject it in the classes we have to test. Stop.

Let’s have a look at the code:

In our little example here I am testing a CQRS Command Handler, the one responsible for creating a user. Our handler has an IDbContext as dependency, which being an interface allows us to use the Moq Nuget package to create a fake context implementation. 

Also, we have to instruct the mockDbContext instance to return a mock User Repository every time we access the .Users property.

At this point all we have to do is to create the sut, execute the method we want to test and Verify() our expectations. 

Let’s make a more interesting example now:

Now that we have created the user, we may want also to update some of his details. The idea here is to instruct the mockRepo instance to return a specific user every time the FinstOneAsync method is executed.

Again, now we just need to verify the expectations and we’re done!

Note that in this case we are making an assumption about the inner mechanism of the Handle() method of the UpdateUserHandler class. Personally I tend to stick with Black Box Testing, but sometimes (eg. now) you might be forced to use White Box Testing instead. If you don’t know what I am talking about, there’s a nice article here you may want to read.

 

Dell Limerick Hackathon 2016

Hi everybody!

Last January we had an Hackathon here @ Dell Limerick, the main theme was “office productivity”, aka “how would you improve your and your coworker’s productivity”.

I was in a team with other 4 very smart guys, didn’t won but all in all it was a terrific experience…two days straight of brainstorming and coding madness combined with pizza and energy drinks.

The winners came up with an interesting prototype of a chat bot running as Lync addon that can answer every type of question, from “how’s the weather” to “who broke the last build?”, passing from “tell me about story 1234567”. I can’t go too deep in the details (also, lots of natural language analysis is involved) but it was definitely a very, very interesting project and really deserved to win.

My team instead…well we produced a voting platform for ideas. In a nutshell, every user registered to the community can post his ideas (which can be divided into macro-areas) and the others can vote it using points they have received when registering. If an idea is approved, the voters will get back the points and a small bonus. If an idea is cancelled instead, they will get the points back (but no bonus).

It was a cool project to work on, we used a very simple micro-service CQRS architecture running on AngularJS, WebApi and MongoDB. Oh and everything was hosted on Azure.

After the contest, we decided to release all the sources, you can find them on my GitHub repository.

Enjoy!

Unit testing MongoDB in C# part 3: the database factories

Welcome to the third article of the series!

Last time I was talking about the database context and at how I injected a Factory to create the repositories. Of course we could have injected every single repository in the cTor, but this way adding a new collection to the database would force too many changes.

Injecting just the factory instead allows us to create internally all the repositories we need, add new ones easily and of course makes our life easier when it comes to testing.

Let’s take a look at our Repository Factory interface:

as you can see, that’s very standard and easy. The implementation also is pretty straightforward:

A couple of notes on this:

  1. the RepositoryOptions class is just a simple Value Object encapsulating some details like the connection string and the name of the collection
  2. in the cTor we have a dependency on another Factory used to get a reference to the database. Why we do this? I guess you know the answer 😀

As you can see, this injected Factory also is very easy:

you can find the implementation here.

Next time: let’s write some tests!

Unit testing MongoDB in C# part 2: the database context

Hi All!

Last time I rambled a little bit about TDD and how to implement a very simple MongoDB repository.

This time I want to introduce you to my cool friend, DbContext. The basic idea is to have an interface exposing all the collection on your db, or, in our case, all the repositories. Take a look at this:

( I will leave to you the definition of the entities ). The implementation is pretty straightforward:

A couple of details worth noting here:
1) the repositories are exposed as interfaces and not as specific implementation, making tests easier to write
2) again, all the repositories are generated via a factory, injected directly in the ctor.

The Factory Pattern allows us to add more repositories without much hassle and, moreover, to inject a “fake” factory during our tests.

Next time we’ll discuss about how to implement a factory for our repo-needs 🙂

© 2017 Davide Guida

Theme by Anders NorenUp ↑