The first layer is the handy UI-capable bulk reverse-proxy, and the next thing we layer on to it is generic traffic inspection.
(I should so not be writing this up right now. I got other fish to fry. But there are some blockers I’m waiting on, and I have a little time, and I just feel like mapping it out further.)
Once we have that first layer running, we’ve got on our local box 1) our downstream app development environment, 2) UDispatch. All the traffic from our downstream goes through UDispatch, and this fact exposes the second layer of functionality: render it well. Remember, this is all related to the upstream-centric architecture stuff we’ve been talking about lately. What we’re after is killing off some very common waste in the making of such apps.
A huge source of that waste: "what happened?" Your code calls this service, and that service, and the other, and renders a really nice fat NPE direct to your user. WHY!?!?
Generally speaking, what happened is one of two things: 1) you’re cute but somewhat dim and you wrote bad code to combine the responses for your own downstream. 2) one of your upstreams said some random crap it shouldn’t have, and you haven’t accounted for that yet in your code.
Well, let’s go figure out what you said to the upstreams and what the upstreams said back to you. If all that looks good, we know it’s "cute-but-dim". If all that looks borked, we’re a lot closer to finding our problem.
There are several ways one could go about it. You could go read their logs. You could go read your own log. You could add println’s. You could get a generic packet-sniffer. You could copy/paste your query into postman. You could run it again and see if it goes away.
You could fire up the debugger. You could ask your next-door-neighbor if the fritzengorple service is down again. You could double-check that you typed your endpoints right. You could run it a third time and see if it goes away.
You get the drift.
Or. UDispatch is sitting right there. Open it and see all of the traffic, request & response, to all of the upstreams, in the order in which it was sent/received, with generic rendering of the results in an easy-to-view form.
You could filter it. You could drill to any aspect of the HTTP protocol. You could spot that 500, that security fail, that springboot html endpoint-not-found.
And this is the second layer of value that UDispatch brings to the table. Because all your downstream’s traffic runs through UDispatch, it can remember and render any of it. It can render request/response as pairs or as separate sequences.
HTTP traffic is often quite recognizable, regardless of source. HTML, JSON, XML, and SOAP-over-HTTP are all pretty easy for a computer to detect. UDispatch gives you tabs for each item it recognizes. It always recognizes HTTP, so there’s always a tab for that. When it recognizes JSON or XML or HTML, there’s tabs for that, too. And they don’t just show you the ASCII. ASCII is technically human-readable, but in these formats it’s usually perfectly human-incomprehensible.
All three of those protocols are tree-shaped. If we had one good way to show a tree, we could use that same way for all of them. (If it’s HTML we could also show a browser-render.) You getting a feel for this?
So. If the first level of function is just a fancy bulk reverse-proxy thing, the second level is just a fancy traffic-sniffer-visualizer.
- Notice: Both of these tools exist in the wild. You can try to COTS-ify it all together. But the thing that’s so handy about UDispatch is that it’s already fit specifically to your task: developing your downstream that has a bunch of upstreams that are themselves changing.
It knows your upstreams. It knows your sets. It knows your downstream. A standard reverse-proxy just knows endpoints. A standard sniffer sniffs all traffic, and the best ones sniff IP not HTTP.
So now you see the first two layers unfolding. It gives us a little more than a little. If UDispatch stops right there, it’s still handy. But it doesn’t. There are more layers that can be built on those first two.
Descriptions coming soon to a muse near you.
Okay, dayjob calleth. It’s still just "warm" here, with scorching right around the bend.
Have a scorchin’-hot day of geekery!