Net API Notes for 2019/11/08
Hello! I hope everyone had a happy (and safe) Halloween - filled with more treats than tricks!
It has been a couple of busy weeks for me (as I briefly mention here and here and here). Hopefully, you have had an equally productive month and are settling in for some well-deserved trick-or-treating. Now, to the notes!
NOTES
WHERE ARE THE PUBLIC GRAPHQL APIS?
When a technology is (relatively) new, much of the press around it can be hyperbolic; the wild-eyed zealous are trying to recruit others to validate their different approaches. Much of what I consider for inclusion regarding GraphQL still falls into that category.
However, Marc-André Giroux has become my must-read source for balanced, thoughtful GraphQL commentary. Marc is a GraphQL proponent that I've covered in the notes before. His post, "Why we Don't See Many Public GraphQL APIs", is likewise worth checking out.
Facebook, where GraphQL started, doesn't have a public GraphQL API. In unpacking why that is, Marc does a great job articulating where GraphQL excels and where other approaches might be more appropriate.
Overall, it is an excellent piece for those currently weighing the pros and cons of various API approaches.
EVENT-DRIVEN ARCHITECTURE WITH MICROSERVICES
The request/response service interaction is powerful, but it isn't the only one. There's a great video from Duana Stanley, a Thoughtworks employee, that provides an enlightening overview of the various event-driven approaches.
Duana covers several event patters like:
- Event Collaboration - Things publish events, and other things listen for those events. This isn't new and could also be implemented with different architectural patterns, like pubsub.
- Event Streaming - Beyond collaborating between two points to using events to create new events: aggregating and filtering, for example.
- Event Sourcing - There is no recorded 'state'; rather, the 'state' of a system (like 'account balance') is sourced directly from the playback of system events from a checkpoint to the desired moment in time.
When talking about event-driven microservices, there are additional terms bandied about like CQRS, event notification, and event-carried state transfer. Duana defines these are properties of the patterns listed above, rather than distinct patterns in their own right.
That is all great stuff, but then Duana goes beyond and defines characteristics where other alternatives, like request/response APIs, may be more appropriate.
I highly recommend spending some time with this one, even if video may not be your preferred format.
HOW MANY ARCHITECTS DOES IT TAKE TO CRITICIZE A MICROSERVICES DIAGRAM?
This weekend there was quite a Twitter kerfuffle. It started with Jack Kleeman tweeting a visualization of Monzo's '1500 microservices'.
That's cool; we've seen these before from companies with large service architectures. The style of diagram, in fact, has become called the "microservice death star". For whatever reason, however, this particular case became a Rorschach test for software twitter.
microservice death star, numerous API and software architecture folks chiming in - Grady Booch, co-founder of UML, remarked "this seems so so very wrong"). He elaborated:
"If it works for them now, then good for them. But talk to me again, five years from now, when the original team is gone and architectural drift takes place."
Others, like 'Fintan Ryan', dug deeper and were even more puzzled:
"I have so many questions about this, and there are blog posts to come from the author which might explain things, but the big thing that sticks out is the fact Monzo have added 800 new micro services in 13 months."
While there was ire and distaste aplenty (after all, this is Twitter we're talking about) architectural consultant Simon Brown called for pragmatism. He pointed out that there's only so much we can glean from a static image; just because it seems complicated for us, we are a poor judge of whether or not that is a good model for the team.
Australian software developer Robert Watkins shared a similar sentiment:
"By far the biggest problem with that approach is removal of unnecessary detail. Models should be simpler than reality, to focus on what they are trying to express. Generating from a single-source-of-truth makes that really difficult."
In other words, the chart looks impressive, but what purpose can it serve other than to say "look at all our services"? Judging whether this architectural arrangement is right or wrong, without additional context with this level of detail, says more about the peanut gallery than it does the company.
And really, how many organizations could generate a similar mapping of their dependencies? As Nick Tune said:
"There are 2 types of people:
- Those who laugh at the complexity of this architecture
- Those who understand what their own architecture looks like
MILESTONES
- In the last newsletter, I mentioned Dapr but didn't provide much detail. Now that people have had a chance to kick the tires and the new car smell is gone we have a better idea: it's a service mesh sidecar, optimized for Azure.
- Every day for the next month, microXchg is releasing a new video from its 2019 conference to its YouTube channel. Whoo-hoo!
WRAPPING UP
Quite a few events have been added NetAPI.events for 2020. If you're looking for an in-person opportunity to rub shoulders with other folks in the API community, check it out. And if you know of a meetup, hackathon, or conference that should be added, let me know.
Finally, thank you to my Patreons. I'm looking forward to work-work slowing down a bit so that I can get back into something of a routine in these here parts.
Till next time,
Matthew @libel_vox and matthewreinbold.com