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.
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.
At work I was recently assigned to a UWP app. This post chronicles my discoveries over the first couple days. Continue reading “A Brief Start with UWP”
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.
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?
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. Continue reading “Eliminating Hard Dependencies”
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. Continue reading “Hide Your Secrets”
Yeah. This post is titled that. Continue reading “The Case Against Private Methods”
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. Continue reading “Handling Errors from Plug-ins”
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. Continue reading “A Plug-in Primer”