Roundup #17: StackExchange.Redis v2, Microservices with HTTP, ngrok, Angular Console

Here are the things that caught my eye this week.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

 

StackExchange.Redis v2.0

Been waiting for this to be released.  Since this is a breaking change, it will be interesting to see what kind of madness occurs when in a diamond dependency where one of your dependencies requires 1.0 and another upgrade to 2.0.

Link: https://stackexchange.github.io/StackExchange.Redis/ReleaseNotes

 

Lightweight microservice collaboration using HTTP – Christian Horsdal

With a microservices arhcitecture system behaviour gets spread out across many, many narrowly focused microservices. Much of the functionality in the system depends on those services collaborating. In this talk I explore different modes of collaboration between microservices, how they compare, which are preferable, and how to keep it all simple. Along the way I will show how to use HTTP for the different types of collaboration and how to use Nancy to implement them on top of ASP.NET Core.

Interesting seeing events exposed simply as an HTTP resource where consumers can query the event stream.   The consumer would keep track of which events it has processed.  Simple approach if you don’t want to introduce a message broker.

Link: https://www.youtube.com/watch?v=_qyxGGpVj_E

 

ngrok

Spend more time programming. One command for an instant, secure URL to your localhost server through any NAT or firewall.

Every once and awhile I need to provide an external service with a URI to my localhost.  An example is if you were doing any local development with AWS SNS.  I’ve used a few other similar services but ngrok seems to be the one that never fails me.

Link: https://ngrok.com/

Angular Console

The Power of the Angular CLI. The Convenience of an App. Spend less time looking up command line arguments, and more time shipping incredible products.

With CLI being all the rage (which I enjoy), I thought this was fairly interesting for those who are not.

Link: https://angularconsole.com

 

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #16: NET Standard 2.1, Endpoint Routing, Bullseye, API Spec Workflow

Here are the things that caught my eye this week.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

.NET Standard 2.1

This document describes the plan for .NET Standard 2.1, which includes the definition of its API surface.

We did a diff between .NET Core 2.1 and .NET Standard 2.0 to see which APIs that were added in .NET Core would be great candidates for inclusion in the standard.

Interesting to read some of the pros/cons for versioning and the decision to go with 2.1

Link: https://github.com/dotnet/standard/blob/master/docs/planning/netstandard-2.1/README.md

 

Endpoint Routing

We’re making a big investment in routing starting in 2.2 to make it interoperate more seamlessly with middleware. For 2.2 this will start with us making a few changes to the routing model, and adding some minor features. In 3.0 the plan is to introduce a model where routing and middleware operate together naturally. This post will focus on the 2.2 improvements, we’ll discuss 3.0 a bit further in the future.

Pretty nice to see this as I’ve been wanting this for some time now, hence blog post on generating links to routes outside of MVC.

Link: https://blogs.msdn.microsoft.com/webdev/2018/08/27/asp-net-core-2-2-0-preview1-endpoint-routing/

 

Bullseye

Bullseye is a .NET package for describing and running targets and their dependencies.

Bullseye can be used to write targets that do anything. It is not coupled to building .NET projects.

Really cool project that I just discovered by Adam Ralph.  Bullseye feels like a great and simple way to define some targets for doing tasks.  Feels very much like Cake without all the extra plugins.  Anyone using it already? Going to explore it more.

Link: https://github.com/adamralph/bullseye

 

Our API Specification Workflow

A year ago we started trying to figure out the best way to not just document HTTP APIs, but to leverage API specifications to avoid duplicating efforts on loads of similar-but-different tasks; maintaining Postman Collections, creating mocks, contract testing, payload validation, etc. To us, it felt like API developers were wasting a lot of time writing up the same logic over and over again. Listing endpoints, defining what fields should have what data, figuring out validation logic, writing up examples, doing this all over and over again in loads of different formats, then — the few folks that have enough time and interest —would write loads of tests to make sure all these different formats were saying the same thing.

Link: https://engineering.wework.com/our-api-specification-workflow-9337448d6ee6

 

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Creating Simple Tasks in .NET with Bullseye

How many times have you created a console application to run specific tasks in .NET?  These tasks could be processing a file, making some HTTP call to an external service or even helping in your build process.  Ultimately ending up with a collection of different tasks which often have dependencies on each other.

I just discovered a project called Bullseye by Adam Ralph which really feels like a simple task runner.  But better yet, is just a library you add to your own console application and not its own process itself.

Bullseye

Bullseye is a .NET package for describing and running targets and their dependencies.

Bullseye can be used to write targets that do anything. It is not coupled to building .NET projects.

Platform support: .NET Standard 1.3 and upwards.

Examples

The simplest example which is described on the Bullseye readme is similar to as follows:

There’s really only two components needed.  Define your target(s) using the Target() methods and then specify which targets to run via RunTargets()

If you do not specify a target to run then the “default” target is used.

If you simply run dotnet run will produce the output:

This would have been the equivalent of running dotnet run default

Dependencies

Here’s a simple example of having one target depend on another.  In one target I’m hitting a service to get the exchange rate from CAD to USD.  In another, I want to save that rate to a file.

When run with dotnet run saveexchangerate

Now if I just want to get the rate but not save it, I could just run dotnet run getexchangerate

Targets

How are you handling running small tasks/targets?  Simple console applications?  Using the new global tools? Let me know on Twitter or in the comments.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.