Going full-on with hypermedia takes some preparations and to convince the masses will require some tooling and examples. Especially tooling. The ability to produce rich developer experience is the determinant of many successful technologies. Another crucial factor are real-life uses cases solved by the technology in question. I would like to focus on the former.

As much as the industry has bought into lightweight Web APIs, often inappropriately called RESTful, there has been an uphill battle to have real hypermedia gain traction.

Read on →

Lately I’ve been working on a library to consume Hydra Core hypermedia-rich APIs. This is something I’ve been planning for a long time now and given that the Argolis server-side component pretty much works it was about time I started working on consuming the API Documentation.

In this post I showcase the simplest usage of heracles and describe some design decisions. I guess I should write about Argolis too in the near future.

Read on →

Given that I’m fairly satisfied with the state of my server-side Hydra library for NancyFx called Argolis it is now time to write some client-side library to consume it. I did some spiking in another small project and it was now time to do it properly. I’ve already had some experience with TypeScript and JSPM so I decided to give these two a go.

Unfortunately getting the project setup right was harder than I’d hoped. Here’s how I managed to get my first test to pass.

Read on →

I recently wrote about the Registrations class of NancyFx. It is a great tool for implementing reusable Nancy packages, which define all their DI requirements and does that with no dependency on any concrete DI container.

Unfortunately every rose has its thorns and there are some limitations and the exact behaviour slightly differs between containers. Read on to see what are the problems you can face when using the Registrations class for setting up your application.

Read on →

Attributes are a very useful feature of many languages but I personally feel that they are used too often and in wrong circumstances. They’re primary shortcoming is the fact that attributes are set up at compile time. During code execution they can only be read but not modified.

Read on →

The open-closed principle is the second letter of the SOLID acronym. SOLID is a set of software design guidelines which help build better software. The open-closed principle declares that

software entities should be open for extension, but closed for modification

One way to satisfy this principle is through the use of the Strategy design pattern, sometimes called Policy. I’d like to show how easy it is to employ this pattern in reusable and extensible components for a Nancy application.

Read on →