In January this year, Enable sent three developers to attend NDC London. Since its start-up in Oslo 2008, the Norwegian Developers Conference (NDC) has become one of the largest conferences for .NET & Agile development with events held in London, Oslo, and most recently Sydney. With Enable primarily developing solutions using .NET, and with the conference boasting several .NET MVP speakers, the conference is a great fit for us.

Technical conferences such as this one can be extremely valuable for training and insight. They also give our developers the opportunity to get out of the office and meet with other developers, as well as the experts working on the technology we use day-to-day. While not all the talks in the agenda will yield gold, there will always be those few that positively impact the work we are developing today and some that will steer what we do tomorrow.

Verification

Sometimes the talks can reassure you that you're doing the correct things. Dominick Baier gave two talks, “Securing Web Applications and APIs with ASP.Net Core 2.2 and 3.0” and “Building Clients for OpenID Connect/OAuth 2-based systems”, both of which were highly applicable to what we develop. We're happy to say that most of the topics or concerns raised in these talks have been addressed in our latest solutions.

Other talks such as Troy Hunt's “Hack to the Future” serve as stark reminders of where problems can occur if corners are cut.

Insight

The knowledge from two of the attended talks has already been deployed to the solutions we've been working on.

Life beyond Distributed Transactions: An Apostate's Implementation -- Jimmy Bogard

Years ago, web development was somewhat simpler. Many applications consisted of a single web server and a single application database. When multiple records needed to change within the database together -- for example, a customer order system where orders and stock were tracked -- the changes could be wrapped in a transaction and all the records would either be updated or not. Today, applications are built for greater scalability where a typical web application may consist of many API layers or microservices each owning part of the data story. The challenge this flexibility presents is that more infrastructure is needed to achieve the same “all-or-nothing” transactional behavior.

In this talk Jimmy Bogard presented the outbox pattern for achieving distributed transactional behavior. In short, this approach requires you to store the intent of an action in an “outbox” that exists within the same transactional realm of your solution. If something goes wrong with executing this intent, you have a record of it so that it can be retried later. As an example, we may have a system that, after saving a record, needs to send a message using RabbitMQ or Azure service bus for a chain of other actions to be started. If something fails to queue this message, then the next set of events do not occur and the system fails to do something potentially important. Using the outbox pattern, the message being added to the queue and the edited record are committed to the application's database at the same time. This can be achieved transactionally so that the record can't be added without the intent and vice versa. A dispatcher program can then periodically search for these intents that appear to have failed and then retry them until they succeed.

Some resiliency requirements cannot be solved by using the outbox pattern alone. For example, it may be crucial that the code being triggered by the message is only executed once, with multiple executions resulting in errors. Fortunately, these requirements can be met by using the inbox pattern. Jimmy's website has some excellent articles about resiliency using these approaches which are certainly worth a read.

What you need to know about ASP.NET Core 2.2 -- Damian Edwards, David Fowler

Unsurprisingly, this talk covered some of the highlights of the ASP.NET Core 2.2 release. While features such as Endpoint Routing and IIS in-process hosting feature higher up the release notes, two features from this talk have already made it into code we deployed in our last project cycle.

Health checks

Being able to probe the health of our applications is important and until now we have relied on our own approach to allow us to monitor the health of our web applications. With .NET Core 2.2, we no longer need to roll our own code for this and can leverage the framework to achieve the same result. Adding health monitoring to a .NET Core 2.2 web application can be achieved as simply as adding the following to your Startup.cs file:

public void ConfigureServices(IServiceCollection services)
{
    services.AddHealthChecks();
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseHealthChecks("/health");
}

Web API conventions

When you wish to automatically produce documentation for your API you need to add attributes to the endpoints to tell the tool of choice what they do. This can lead to code such as:

[HttpPost]
[ProducesResponseType(typeof(User), 201)]
[ProducesResponseType(typeof(User), 400)]
public IActionResult Create([FromBody, Required] User user)

The more your API endpoint does, the more attributes it will need which can make the code seem cluttered. .NET Core 2.2 allows you to tidy away common attributes with DefaultApiConventions. Adding the following line to your Startup.cs class does just that:

Less relevant

Sometimes talks can be useful in order to confirm that some technology is less relevant to us right now. For example, in the containerised world of Docker, Kubernetes is often used to automate the deployment, scaling and management of the containers. Our developers attended a talk that demonstrated this and, while the content was interesting, it was concluded that we can achieve the same scale-out behavior with Azure without the need for the additional orchestration.

The future

Finally, some talks give a glimpse of technology that may be adopted in the future. One such talk was Steve Sanderson's talk, Blazor, a new framework for browser-based .Net apps. Microsoft have made several attempts to have server-side code running in the browser -- Active X and Silverlight being two examples. The difference with Blazor is that the code is executed by a version of the .NET Core runtime that runs on WebAssembly which is a web standard supported by all modern browsers -- no additional plugins need to be installed on the browser.

While work is being done to make the performance and size of the .NET runtime that is downloaded as optimal as it can be, a lot of work has gone into making the development story as smooth as it can be. In the talk it was demonstrated that you could debug the C# code being executed by the browser in the browser's own debugging tools or within Visual Studio.

What is hard to tell at this stage is whether Blazor will gain enough traction for it to become a viable alternative to us using Angular for our front-end development. However, it is a technology we will be keeping an eye out for when it ships.

Conclusion

NDC London 2019 provided us with some great insight into the tooling and approaches we're using today and what we may consider using in the future. We look forward to learning what topics will appear in next year's conference.