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.

Roundup #15: LittleForker, TDD: Where Did It All Go Wrong, net461/netstandard2, Bing on netcore21

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.

LittleForker

An exploration in the launching and supervision of processes. Written to scratch and itch where the primary use case is installing a single service (on windows) who then spawns other process as part of a multi-process application.

A pretty cool project that I recently stumbled upon by Damian Hickey.  I plan on experimenting with this soon for a current project.

Link: https://github.com/damianh/LittleForker

 

TDD, Where Did It All Go Wrong

Since Kent Beck wrote the book on TDD in 2002 a lot of words have been dedicated to the subject. But many of them propagated misunderstandings of Kent’s original rules so that TDD practice bears little resemblance to Kent’s original ideas. Key misunderstandings around what do I test, what is a unit test, and what is the ‘public interface’ have led to test suites that are brittle, hard to read, and do not support easy refactoring. In this talk, we re-discover Kent’s original proposition, discover where key misunderstandings occurred and look at a better approach to TDD that supports software development instead of impeding it. Be prepared from some sacred cows to be slaughtered and fewer but better tests to be written.

I’ve actually seen this talk a while ago by Ian Cooper, but I watched the newest iteration this week and thought it was worth sharing.

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

 

What they don’t tell you about event sourcing

Event sourcing and CQRS gained a lot of popularity recently. The advantages are obvious and they share a very peculiar symbiosis with each other and with the current tech state of the art making them very relevant. However after working for several years with them in production there are several caveats that one should care for.

Probably one of the better posts I’ve read in awhile about Event Sourcing.

Link: https://medium.com/@hugo.oliveira.rocha/what-they-dont-tell-you-about-event-sourcing-6afc23c69e9a

 

.NET Standard 2.0 & .NET Framework 4.6.1

This isn’t overly shocking as I’ve had nothing but problems with 4.6.1 and binding redirects with things like System.Net.Http.  This is a real bummer as all the previous documentation and guidance was that net461 would be netstandard2 compliant.

Do yourself a favor if you can and move to 4.7.2 (although I’ve had success with same issues under 4.7.1).

 

Bing.com runs on .NET Core 2.1

Since its beginning, Bing.com has run on the .NET Framework, but it recently transitioned to running on .NET Core. The main reasons driving Bing.com’s adoption of .NET Core are performance (a.k.a serving latency), support for side-by-side and app-local installation independent of the machine-wide installation (or lack thereof) and ReadyToRun images.

Link: https://blogs.msdn.microsoft.com/dotnet/2018/08/20/bing-com-runs-on-net-core-2-1/

 

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.