Friday, February 18, 2022

Ports and Adapters, Part 2

Ports and Adapters part 2

Approach, not reproach

Many programming tutorials are difficult to follow.  I do not necessarily expect this one to be any different, but I'll try.  I'm going to start with relatively broad concepts, any of which may lead to a new post drilling down into that topic in further detail one day.

Take a client-centric view of the solution

We have nobody to blame but ourselves.  We've all done it.  You hit Google, or StackOverflow, and you grab a chunk of code that interfaces with some library we want to use.  Then we change the shape of our code, introducing abstractions that don't really gel that well with the ones around it, in order to make that adopted code work.
Don't do that.

Design the API you want to use

Think about things from your own application's point of view.  Do you need a database client?  Or do you need a way to get data based on a few 'key' criteria?  What level of abstraction do you really want to be working with as you write your code?

Test first

I prefer a TDD (Test Driven Development) approach to writing code.  When one first encounters the notion, it seems backwards.  It was certainly very different from practices I'd spent years on.  But in the end, following this discipline beats the hell out of attempting to add unit tests to the tangled messes many of us naturally weave otherwise.  I've been called good (or sometimes better than that) at what I do, but when I look around at my code, what I see is still more of a mess than I'd like.
TDD really helps with that.  I think that topic deserves a post of its own.
Use your concept to build some code.  Mock the responses you intend your own API to provide.  Call your own API.  It's all a kind of unit/integration testing hybrid, it's all provably correct.  It also works the way you think as a developer, long before you've actually decided which database or messaging system you'll be using.

Adapt your concept to a real-world library

When you've achieved that level, it's finally time to replace the mocked service provider with a real one... And testing that can appear very difficult.  I'll discuss techniques for that in future posts.

But first, a word about using code that demonstrates use of a library:

There's nothing wrong with learning how to use a library that way.  It should teach you the general usage patterns, pre-requisites, etc.  But that doesn't mean you should copy that demo function into your production application and start to use it!

At a bare minimum paste it into a new source file.  Better yet, use a test-driven approach to create a new file that implements the subset of capabilities you need.

That's really all you have to do to get dependencies out of your own code.  It sounds easy, and sometimes it is.  Actually, a lot of the time it is, once you figure out how to think about it.

Monday, January 31, 2022

Ports and Adapters part 1

Ports and Adapters part 1

A love story

Today I want to begin a series about a technique which has helps to isolate code from changes in implementation details.  Sometimes those details may seem central to the code in question, but many times it just isn't.

I'm going to start with a little story.  I don't know if it's interesting or not, but it's all true.3

Many years ago, back when my razor stubble was brown and I was a hired gun programmer, I was responsible for maintaining a corporate security library.  This was an important library.  Dozens of applications depended on it to authenticate and authorize corporate users.

There's just one problem:  It relied on an obsolete LDAP library which was no longer being maintained, and that had to change.

This was a pretty frightening task.  It absolutely had to work.  This was before the idea of providing such a thing as a service had become popular, and the library was statically linked to all those applications.  A mistake meant a patch, a patch that would get attention, and what's more a patch that would have to be quickly rolled out to all affected applications.

I hate attention.  Well, bad attention anyway.  I suppose I'm also not really a big fan of emergency deployments. 

I had to formulate a plan of attack.  As per my usual practice, I banged my head against things until I eventually worked out what I could have found in a book.  Let me walk you through my process:

Step 1:  Tests

First, I built a comprehensive suite of unit tests that validated all of the library's functions.  The tests were a little more integration-ey than I would build today, but when things were green?  I had great confidence that I would have a successful build.  We were also adopting Jenkins at the time, so every code commit was tested and built automatically.

Step 2: Isolation

Next up, I isolated all of the library calls behind interfaces.  That was a lot of effort, but with the tests backing me up, I was able to keep everything working just as before.  I did have to add a factory to instantiate the main library class, but kept that hidden behind a facade that looked unchanged to the API users. 

Step 3: In with the new

Now I started on the new code.  By sticking to the interfaces which allowed me to accomplish step 2, I was able to swap back and forth between the fully functional production implementation and the one under development.  All I had to do was change the name of the class from 'new obsoleteImplemenation()' to 'new unfinishedImplementation()'.  I could run the test suite and get a pretty solid idea of how far I had come and how far I had to go.

Step 4: Risky business

I realized that this was dangerous territory.  If I shipped a library that had an unexpected bug under load or under some kind of unexpected error condition, there could be really big implications.  The user base included both internal and external entities, offering lots of exposure.  That was too big a risk, so I had to do something to mitigate it.

Step 5: On reflection, this is a good idea

I was working in Java, so I decided to take advantage of reflection to create the class.  If you aren't familiar with the concept, it is just a way of creating an object using the name of the class as a string value.  That came in handy, because now I could just have the two different class names for the now-isolated library and use either one live at run-time.  To make it as safe as possible, I initially defaulted to the old library, but gave the clients an option to set an environment variable to enable the new one.

Fortunately, I had good ties with developers for several of the other projects, and I was able to cajole them into testing and then deploying with the optional library enabled.

Step 6: Once more into the breach

Once I had good feedback, I felt safe making the new library the default, while allowing an environment variable to enable the old library.  I kept that around for a good long while, until I was sure it was safe to get rid of it.


That was a lot of effort and a lot of worry as well. We can do a little better than this.  In fact, we can do a great deal better than this, although frankly I was proud of my accomplishment.  What I'd stumbled into was a more general idea around dependency isolation.  You'll hear terms like 'hexagonal architecture' used to tell you what to do.  

But how do you actually DO it?

That's what I want to talk into in the next few posts.  Swapping dependencies can be a giant pain point, but it does not have to be.  The most difficult thing, really, is adapting how you think about systems.  The trick is to stop trying to adapt our code to someone else's idea of how an API should work.  That is OK for quick demonstrations or tutorials, but it's not how I believe we should build systems.

Instead, when we require a capability, we should design an API for that capability ourselves, whether or not we intend to implement it.  The design should be harmonious with our existing system, or at least follow similar conventions.  It should not feel tacked on.

Integrating external libraries deeply into our own code base is a code smell.  I want my code talking to my own libraries, which will act as adapters to the third party code I want or need to use.  Let those adapters have the weird stuff that thinks the way other people do.  My job is to make those adapters conform to the expectations I've set for/with my API design.

Next time around, I'll dig a little deeper into what I mean by designing an API ourselves, and what the benefits (and costs) are.