Head in the Cloud

Last time  we looked at setting up a microservice based on WebAPI with dependency injection an persistance. In this article, we’ll look at global exception handling and error responses. The Error Response We return standard error message formats for 500 errors. In WebAPI, Microsoft uses  HttpError  internally within the framework. For consistency, we do the same. That way, whether the error was generated in the pipeline, or by our business logic, the message is the same. Under the hood, HttpError inherits  Dictionary . You can add custom key/value pairs for anything you’d like to return. The response the looks something like… { "message" : "An error has occurred" , "exceptionMessage" : "Object not set to an instance of an object." } The dictionary keys to look up standard error information are available on the  HttpErrorKeys  type. Using it, we can generate a  IHttpActionResult  to return… public class Except...

We’ve been building microservices here for a while, so I thought I’d share how we do it. I’ll try to cover the basics of how we implement all our services without getting too complex. I’ll provide a high-level overview of the basic components that lay the foundation for our services and share some code snip-its. The goal is to provide you with a simple foundation to build your own microservices framework strategy upon. What’s a Microservice? There are a lot of opinions on the matter. When I use the term microservice in this article, I’m referring to a service that is independently deployable and encapsulates a single bounded context. Though the techniques in this article could be applied to any service, even large monoliths. Core Technology Stack Even though the benefit of microservices is “use what every you want”, we found that having a standard set of tools in the tool box keep our lives simple and allow us to produce services more quickly. If your shop does give developers...