Self-Registering APIs – Part 2: Authentication API, Registering Other Services, and Service Discovery

Today, I’ll be continuing the tour of my self-registering API architecture by taking a look at the authentication API and the mechanics of how a service registers itself. This will be a more practical dive than the previous post’s theory-heavy chit-chat.

Advertisement

Self-Registering APIs – Part 1: An Overview

Several months ago, I started working on a new desktop application project that was to be backed by an microservice ecosystem. I ended up designing an API where the only well-known service is the one that handles authentication, and all other services register themselves with the authentication API and only access each other via service discovery. This yields extensibility: a new service doesn’t need to be explicitly set up in the ecosystem; just add it and go.

A Brief Start with UWP

At work I was recently assigned to a UWP app. This post chronicles my discoveries over the first couple days.

Extreme DRYness

I ran across an interesting scenario at work today that I think merits some discussion. In this post, I’ll cover what DRY is, and when following it religiously may actually cause problems.

Breaking Changes

Today we’re going to talk about breaking changes in libraries. Specifically, we’re going to answer the following:

• What constitutes a breaking change?
• How can I avoid making breaking changes?
• When is a breaking change a good idea?
• How do I indicate that a new version contains a breaking change?

Eliminating Hard Dependencies

You found it! After many hours of scouring the internet, you’ve finally discovered the library that does precisely what you need. Except… it has a dependency… on a package that your architect has declared unfit for your company.

Hide Your Secrets

In the last post we discussed why it could be preferred to expose all of your methods publicly. However, I deliberately left something out. Some of you may have noticed.

The Case Against Private Methods

Yeah. This post is titled that.

Handling Errors from Plug-ins

Before we get into today’s topic, I have some sadness to report. My beloved Dallas Stars were eliminated from the NHL playoffs. Also, my favorite player, Trevor Daley, who now plays for the Pittsburgh Penguins, has suffered a broken ankle and will not be able to play in the Stanley Cup games. Happily, if the Penguins win the Cup, he’ll still get his name engraved on its holy base!

Anyway, enough of that. Let’s get on to software.

Last time we built a very simple pluggable program where each plugin provides a translation of the string Hello, World! Today, we’re going to explore some of the problems inherent in our approach.

A Plug-in Primer

First of all, I’m sorry. It’s been a while. I committed to writing this blog, and I got a little lazy. That’s not to say that I haven’t been really busy, though.

Secondly, I’d like to say… LET’S GO STARS!!! (The Dallas Stars are currently in the Stanley Cup playoffs after having won the Western Conference and coming in #2 in the NHL during the regular season!)

Okay. Now that that’s out of the way, let’s get on with this blog post.

---

Today, we’re going to embark on a new journey: building WPF applications that support plugins. There are a number of ways to build plugable applications, and I recently had the opportunity to play around with a few ideas. In this series we’ll explore some of our options and their merits. But first, let’s look at what a plug-in is.