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”