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.

Roundup #14: NuGet Source Repo Link, RESTful API Guidelines, Async/Await, High Perf .NET

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.

NuGet Source Repository Link

Small but really useful feature.  You can specify RepositoryUrl and RepositoryType in your csproj.  For example:

Link: https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets

Zalando RESTful API and Event Scheme Guidelines

Zalando’s software architecture centers around decoupled microservices that provide functionality via RESTful APIs with a JSON payload. Small engineering teams own, deploy and operate these microservices in their AWS (team) accounts. Our APIs most purely express what our systems do, and are therefore highly valuable business assets.

This is an extensive guideline.  I don’t agree with some of them but regardless, always interesting to read and digest what others are doing.

Link: https://opensource.zalando.com/restful-api-guidelines/

Async and Await

I’ve seen a bit of chatter this week related to Async/await and landed on this blog post from several years ago by Stephen Cleary.  It’s probably one of the best overviews of really getting how async/await works.  If you’re still unsure how to use async/await, I highly recommend reading.

Link: http://blog.stephencleary.com/2012/02/async-and-await.html

Writing High-Performance Code in .NET

Come and hear some tales from the trenches on building highly scalable services with .NET powering various Bing services. The good, the bad, and the ugly! In this talk, we’ll focus on best practices to build high performance code, to instrument the code for deep analysis, and how to use various tools to help achieve your performance goals and drive down costs.

 

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.