UDispatch has multiple layers of functionality in it. The first thing it is: a reverse proxy on the dev box that knows your upstreams and knows they’re sets. When you’re coding in a downstream, you typically have multiple upstreams you’re developing against. Service#1, Service#2, and so on. Your code sends HTTP to those services, they answer with HTTP.
These services are typically arranged in sets. That is, to use Service 1A, one must also be using service 2A and 3A. (Ed. Note: I’ve never actually seen them named this succinctly, they usually have random strings and letters that don’t indicate any sort of grouping at all.)
One encounters, in developing our service, two very typical patterns, then. 1) bouncing our service to change the endpoint URLs it should be hitting. 2) changing several of them — or forgetting or mistyping one — whenever you change one of them.
This involves a lot of tacit knowledge, of course. You have to know which upstreams go with which. The upstreams aren’t named well, even when they’re named consistently, which they often aren’t. It eats mental bandwidth. Solving this problem in your own code isn’t hard, it’s the same thing we try to do with all tacit knowledge in code: make it explicit. Define data structures to associate them, give them good names. Change one variable to change all the endpoints.
(Persistence here is usually handled by some sort of profile mechanism, though not always. I’ve seen it in databases, and seen it require another external service, for instance.)
But there’s no very good reason to put this in prod code, and no very good reason to solve it differently (or copy/paste) with every new downstream you create. Instead. What if we aimed 100% of our URL’s at another app running right on our local box. What if it was that app’s job to actually know the real endpoint and communicate with it?
An app like that is called a reverse proxy. Your downstream is talking to UDispatch. It doesn’t know it is (in prod mode). It thinks its talking to the real endpoints. You’ll notice, though, we can’t aim our URL’s exactly at the same endpoint on UDispatch. We have multiple upstreams. We need to talk to all of them. How do we say which one we’re talking to? Easy. Add a one-word path variable to the base URL.
So, if you talk to the Mother service and the Father service, the endpoints are http://localhost:XXX/mother/ and http://localhost:XXX/father/. And UDispatch now knows what the real endpoint is, rewrites the URL, sends the request, returns the response, and bob’s yer uncle. (Don’t kid yourself, there are gotchas, mostly having to do with security, but let’s solve that later.)
We give UDispatch the ability to define these names. We give it the ability to combine them into named sets, one supposes families in this case, "Simpsons", "Cleavers", and so on.
Now, to swap out endpoints in a set, the developer doesn’t edit her downstream’s profiles/database/service at all. She doesn’t bounce her app at all. She just hits the UDispatch UI and pulls down a combo, and from that moment forward her app is talking to a different set.
Of course, you don’t have to change those url’s as sets. UDispatch is actually offering an ad hoc arrangement, the sets are just named "presets" to change each item in the ad hoc.
So. Some questions.
- Can this be done?
- How hard is it?
- What does it get us?
Some answers:
- Yes. I have done it.
- Not hard, a little finicky, the basic stuff worked right out of the box.
- It gets us a little — not enough, and not as much as we want — a little.
A little: no more bouncing the downstream to change its endpoints.
A little: human-readable names for sets of associated upstreams.
A little: team-wide or org-wide app AND DATASET for all this.
So the first layer of UDispatch is just this: it’s a bulk reverse-proxy with a UI that runs locally. The UI can view, edit, associate, share, & select multiple upstreams to offer its downstream. It does this at runtime 100% dynamically, with no reboots of it or its downstream.
There’s more. There’s actually three more layers to it, each adding another level of value to teams that are using orchestras of services to do their work. We’ll get to these.
But this is enough for the moment. The next few muses in this series will just be about getting this going, open-source, binary-downloadable, and so on.
I am wanting to remind you: all of this is possible only because we’re re-balancing, because we’re looking away from the made to look at the making. UDispatch isn’t part of whatever pile of services you’re shipping. It’s part of how we’re going to make that pile.
I better get back to the day-job. In theory, I have some fairly lightweight UI-tightening stuff today, should go smooth and mellow.
Have your own self a smooth and mellow afternoon!