This week on API Intersection podcast, we dive into the challenges of integrating with legacy systems, integrating a variety of third-party systems, building diverse APIs, and how to manage different levels of sophistication between African banks and mobile network providers. We interviewed Chris Turner, Senior Software Engineer and Agile Practitioner at Segovia Technology, a Crown Agents Bank. Crown Agents Bank uses computer systems and APIs to move money between countries, particularly in Africa.
With his current role, Chris emphasizes that he could very well be working with one organization or agency with a modernized, high-technology stack that needs to integrate with an organization whose main form of technology is an array of spreadsheets.
There is a level of complexity and nuances involved in working with APIs across different domains and industries, particularly in the context of Crown Agents Bank's mission to facilitate cross-border money transfers. With such a stark variety of diverse integration partners and the complexity of their APIs, building a standardized API program is all the more critical.
Check out Chris's work at software.skipoles.co.uk
_____
To subscribe to the podcast, visit https://stoplight.io/podcast
--- API Intersection Podcast listeners are invited to sign up for Stoplight and save up to $650! Use code INTERSECTION10 to get 10% off a new subscription to Stoplight Platform Starter or Pro.
Offer good for annual or monthly payment option for first-time subscribers. 10% off an annual plan ($650 savings for Pro and $94.80 for Starter) or 10% off your first month ($9.99 for Starter and $39 for Pro).
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Every place you come across as a differentway of doing it and is definitely that.
If you have specific rules or principlesand you try to apply them,
they probably work.
The first time you build the softwarebecause it's nice and clean.
But then as soon as you
then try and expand the software,maintain the software, add
new features into the software,you get into this horrible world of do I
do I break the principlesto achieve what I want to do?
(00:22):
Or do I spend much longerripping everything apart
to insert the new stuff and maintainthe principles again.
I'm Jason Harmonand this is API intersection
where you'll get insights from experiencedAPI practitioners to learn best
practices on things like API design,
governance, identity, versioning and more.
(00:55):
Welcome back to API Intersection.
So I'm not going to say the thing.
I would saythat we're going to do something different
because it's always different, right?
It's I'm reminded every day latelythat APIs are everywhere now.
I mean, if you can touch something,there's probably an API for it.
You just haven't turned it on yet.
So from the UK,
(01:16):
joining me today is Chris Turner,who's actually writes code for a living,
which I have to point outis somewhat unusual for our guest.
So, Chris, thanks for joining.
And tell us a little bit about yourself.
Hi, I'm really glad to be here.
So, yeah, I'mI'm a software engineer in the UK and I'm
still 25 years into my career.
(01:37):
I still my main goal is writing code.
I love writing code and designing systemsand works across a range of domains
from everythingfrom sort of travel reservation,
telecoms, media, e-commerce.
GreenTech But currently I am working for
a really niche UK bank called Crown AgentsBank, and we're sort of a
(02:01):
a specialist bankthat's very specialized in moving money
in between countries, particularlymoving money from the developed world
into developing countries,particularly in Africa,
and using sort of computer systemsand joining up all the APIs
in the various systemsto actually make those these payments
into countries where that moneyreally makes a difference.
(02:24):
Yeah, that's super interesting.
And, you know, I couldn't help but noticeon your profile,
you've been working on this API stufffor quite some time
and, you know, it's like I was saying,they're everywhere now.
So yeah, you end uplearning a lot of different things.
I guess when you look back at allthese different domains,
all these different kind of industries,
where does that kind
of take in your thinkingwhen now you're in fintech and banking,
(02:47):
which I have some experience with,and it's pretty different, but
do you feel like there are sort ofportable things from that that you're now
more focused on and implementing this?
Yeah, definitely.
I think over the years I've been through,again, all the all the standard things
like the journey throughso and all of those things and
still see this thing
(03:08):
that everyone sort ofkind of like creates their own API.
And each API is subtly differentto every other API, which is always makes
a, a fun integration challengeand particularly sort of
what we're doing at Crown Banks.
We've got lots of legacybanking systems, modern banking systems,
and we're also offeringintegrating into banks and mobile
network providers in Africa,which have again, a variety
(03:31):
of different levelsof sophistication on their APIs.
And just looking at that gotwe think started to get us thinking around
how can wehow can we try and create a common view
of all those APIs without trying
to aggregate them all together,because that's never going to happen.
We've just got such a diversityand might spirits have years.
We've shown that it'ssort of try to create generic APIs
(03:55):
is never really worked.
I've always found thatwhat you end up with
is either a horrible giant mess,which is really difficult
to deal with or somethingwhich is like the worst of all worlds.
So what we started to look at is let's,
let's try and focus these APIs around
particular domainsand then use some sort of
(04:15):
the software engineering techniquesthat we use to build good software
and see how we can apply them intothat world of APIs that we're building.
Yeah, it's interesting because I feel like
when I look at theyou mentioned like aggregation
and the idea that you can come up withlike the perfect API for a given vertical,
(04:36):
you know, I'm old enoughand I guess you probably asked you
to rememberlike the days of Oasis and Soap, right?
And we saw these industrygroups get together and say, Well,
let's all agree
between all these different huge companiesas to what the specs should be.
And by the time they're done,no one wants to use it because it's like,
you know, 50,000 fields to do anything.
(04:56):
But it's interesting to see these daysthere's more
and more of these kind of aggregationplatforms
that are trying to make it easierand that sort of thing.
But I'm kind of with you.
It seems like a fleeting goalthat is diminishing returns over time.
Yeah, I've definitely foundin particularly my previous dry work
settings of green tech energy,and we were integrated
(05:17):
with a lot of energy APIsand there were lots of developments
of standards for sort of grid managementand things like that.
But every new providerthat came in with something different
had a bit to add a bit to itand you sort of end up with a core
and all these little extensionsthat go off of their various profiles
and it actually becomes
such a big blob of stuff to tryand get your head around and implement.
(05:39):
It would have
it would have been so much easierjust to have half a dozen very simple APIs
that they understand abilitythat I find would be a much greater.
So is easier to understand, easierto build than trying to sort of create
something that requires
a massive amount of codewith lots of additional statements,
which is hard to testand likely to have a lot more bugs in it.
(06:01):
Yes, it's an interesting facetof what you're doing here
and having some prior experiencein fintech in my time at PayPal,
know, you know, one of the like Americanperspective things that I learned was
the whole worlddoesn't use credit cards to pay for stuff.
And certainly,like I was more involved with Japan
but was aware of of Africa that likemobile phone based payment is the way.
(06:25):
And so,
you know,
I would imagine connecting with all ofthe different sort of telecom providers
and all that sort of stuff, which in thatmarket it's text based payment, right?
So super foreignand seems like impossible to secure, but
so I'd imagine your your perspectiveon consumption here is is somewhat
different too, which is partially the wayyou're describing this problem.
(06:48):
Yeah. Yeah.
It's effectively
yeah every every single providerthat we potentially connect to has got a
that they're very similar because they'reall trying to do mobile payments of money
when we're moving sort of small amountsinto people's mobile accounts,
but they all do itin a slightly different way.
And we, we, we still got some customers,some providers that we integrate to
(07:08):
where are still using portals
and we actually have to web scraped themso they're not even on the API.
I think they'reYeah but but a lot of them are APIs but
there are lots of sort of an Excelbased APIs, I think.
So that and they're,
they're all very subtly differentin terms of exact ideas
and how they representsort of particular data.
So it's kind of quite hard to aggregateall of those into a common approach.
(07:31):
So we do tend to end up with a corebut sort of specific
implementationsfor each sort of each provider
that we're actuallyconnecting to for that.
Yeah,and connecting with that many providers.
I mean, beyond I guess, you know,I would venture to guess you've got sort
of an internal representationof how to aggregate those things
that, you know,you only use for your own implementation.
(07:54):
But how do you look at sortof the resilience of having to connect
all those different things,which I could imagine
in a developing market like Africa,you might have things that go up and down
and they might be a little shakierthan in some other parts of the world.
Yeah, that's absolutely.
We have a, a lot of the coreimplementation of us of our code is around
(08:15):
sort of strategies for dealing with sortof retry mechanisms, back off mechanisms.
And we even have some providerswho, for example, we might have a
a single accountthat we have to log in to.
So we can only make payments sequentially.
So therefore we've then got some back offqueuing mechanisms
and sort of a semaphores
in that we have to kind of createthat actually prevent access
(08:37):
at multiple payments.
Don't try and process that,putting everything in queues.
So it's a whole sort of gambitof different things that we have to
sort of think on top of rather than justthe protocol that we send as well.
It makes it fun.
Yeah, for sure.
I think you just won four new term
on API intersection Semaphore,so congrats.
(09:00):
I don't think I've ever heard anyonemention it before.
CSS people ACA stuffmost people forget about.
Yeah.
They call those core techniques are stillthey're still out there.
There's still they are under the covers.
Absolutely.
So on all this kind of resiliency stuff,
are there specificsort of tools that you know you've used
(09:22):
that have made this easier to deal within terms of, you know, all the back office
and all these things you're talking about,or is this all bespoke?
There's a lot of bespoke stuff,but quite a lot.
We use a framework.
So taking from sort oflike the world of domain driven design,
one of the sort of concepts in thereafter you may have sort of
come across these courts and seek you.
(09:43):
RS Command clearresponsibility, segregation.
So in this area you're having effectivelya stream of events, which is your event
event source,
which is your source of truthand your timeline, and then you from that
you process the events and createvarious views and things.
So we kind of tend to make use of that.
So there's a particular framework,excellent framework,
which is an implementation of that,which is very good and it contains lots of
(10:07):
useful technology for like timing events,setting retry events to trigger
at some point in the future so we cansort of send off a message asynchronously.
Wait, and if it times out,we can then schedule a retry event
to occurat some point in the future to try again.
And we use that to also scheduleevents around managing resources and
the back of that.
(10:28):
So kind of using that sort of thatold audit
trail of all the transaction historythrough that, we can actually use that.
And then everything is
then an event coming back in to triggersort of the the next stage or the retry
or some kind of buildingqueuing mechanism to stack the up.
So it's sort of like a lot of bespoke,but building on some standard core sort of
(10:50):
modeling practices that have been provenover a number of years.
Yeah, I feel like thatit's a thing that always comes up.
I'll say though,I feel like a lot of shops I've been in,
I see folks fail at trying it.
They get halfwayand it's sort of like crass or curious
or somethinglike it's, you know, kind of halfway done.
(11:11):
But the dream is always that, well,we can replay this stuff in
in tests, right?
So have you realized the dreamand can you actually do
the replay of log kind of stuff in test?
We're getting we're getting closer.
We're not we're definitely not there yet,but we are We're definitely at the point
where we can collect the event sourceand we can replay the stream through.
(11:33):
But we probably still gota little bit of work to actually do that.
And that the real challengeis, is when with most of the systems
we're integrating.
So a lot of them are very unreliableand unstable.
So they actually don't even have like testinstances that we can use.
So we can't replay those eventsagainst live services.
And so a lot of the work we're working ontowards now is how can we actually create
(11:55):
a simulation of those servicesthat actually honors the same API contract
and then be able to replay the sequenceof events against the simulation
to test our software.
But then can we use the stream of eventsthen against the actual API to test
that their system is still behavingin the way we expect it to.
So we'vedefinitely got a long way to go on that.
(12:17):
But it's it's going to bea very good journey when we get there.
I think.
Well,I'll say in our experience at a stoplight,
when we see folksusing marking like you're describing,
it's usually a good signof a level of maturity in approach.
It's not usually a thing.
People start with the kind of,you know, learn about it over time.
So that's that's a good sign
On events.
(12:38):
I'm curious and I suppose this is validfor the API side too.
Are you using sort of suspect formatsto describe these things?
Yeah, we again, we just releasedwanting to get into proper
sort of API contractsand things and enforcing those.
So for particularlyfor our sort of our synchronous HTP stuff,
(13:00):
we're starting to get sort of open APIcontracts properly drafted for all those
so that we've got sort of somethingto validate and,
and creating them as wellfor the third parties
that we're integratingbecause most of them don't have that.
They have some,some very flaky documentation quite often.
So actually trying to sort ofbuild some contracts for those as well.
Getting those PDFsin your email. Apps, I mean,
(13:22):
you've got to love that way of working.
It'll never not exist.
It's always going to be a thing somewhere.
So open API for the synchronous stuffon the event side,
are you using anythingin similar fashion for contract?
Not really at the moment,so that's definitely
an interesting area to look at the most.
Fortunately, we're at the point where mostof the systems that we are integrating
(13:46):
with tend to be synchronousand they tend to be fairly unstressed
excited and that we're polling thembecause that's largely what they
they support.
And most of they are sort of converting
that sort of asynchronous eventshappens within our own,
our own landscapeand our own microservices.
So we kind of largely in control of those,but definitely
something we probably need tolook at a bit more is how we kind of
(14:09):
define those and contractthose events moving between the different
sort of the different bounded contextswithin our system.
Yeah, it'sit certainly seems to be a growing
trend of folks that are tryinga more event driven architecture.
And it's like in the same waythat you can kind of get this API sprawl
with the synchronous stuff where,you know, you lose consistency as scale
(14:31):
goes up.
The same thing happens with events.
The upside being,it seems to be predominantly
internally focused,which it sounds like is your story here.
So I guess, you know,we've been talking a lot
about all this stuffyou have to consume to operate,
but I guess if we shift backto kind of that internal focus,
you know,
what do you do to kind of tryto gain some kind of consistency
(14:54):
with what sounds like a real patchworkof external connections?
Yeah.
So so what we've been doing is we'veand it's very much going back to sort of
like 2004 actually, whereby sortof journey on this started and there's a
and chuckled Eric Evans and he wrotea book called Domain Driven design
which is it's one of it'sone of those classic books that
(15:16):
even though it's sort of almost 20 yearsold, it's still,
if everything in it is still relevant,just as relevant today
as it was when he wrote it backall those years ago.
Unlike the books about various frameworkswhich even become obsolete,
this is kind of like one of thosecore books that I go back to all the time.
It's just got so much great material.
I definitely recommend itfor an investigation.
(15:37):
The read,if you haven't sort of come across that.
But one of his main concepts in there is
that the domain is your focus.
And what we've discovered fairlyquickly is actually within our world,
there isn't just one domain,there are lots of different domains.
And where we hadin previous versions of our architecture,
(15:57):
those domains that kind of overlapswith each other a bit.
So concepts from one,it's seeped into another.
So weird, weird, cryptic field valuesor field names or data structures
from, say, the banking domain had sort ofseeped into the payments domain.
And then as the banking domain changes,
then the payments servicesuddenly potentially breaks,
(16:19):
or you have those significant sortof breaks in API contracts between them.
So what we've really beenfocusing is not on this work
is actually looking at let's createa proper bounded context for each domain,
define the domain model inside itof how all the states is structured,
what it looks like,how it integrates with all these services,
(16:39):
but then focus really clearly on thethe contracts
that that provides to other bitsin our infrastructure, other domains.
So have a very clean API model for that
and a really clean set of eventsthat we clarify.
And to document very thoroughly.
And that's the waywe trying to keep that separation so
we can build those two bits independently,different teams, different speeds,
(17:03):
but without allowing 1 to 1to cross-pollinate
too much in the otherinto the other that causes that breakage.
Yeah, it's it's funny, Ithink sometimes people get really wrapped
around the axle with DDT stuffand I'm not saying you are,
but I often have to kind of remind folks,just bring it back down
to like the simplest thing is just singleresponsibility principle, right?
(17:25):
Build the thing to do one thing.
If it takes more than one wordto describe it, you're probably doing it
wrong, right?
If you've got the end or the slashin the name of this capability
or this API, right?
Like take a step back.
Is it really doing a single purpose,you know,
and you don't need to read a bookto understand that idea either.
(17:46):
So it,
it sounds like on kind of the
I'd imagineyou have a lot of legacy things here.
We were talking before
and you're saying this is like a 200 yearold company or something.
Yeah, Yeah.
It's originally a a sort of aa British colonial era
era bank that sort of evolvedevolved over time from sort of
(18:08):
investing in these foreign countries,
sort of part of the British Empire legacy,gone through lots of various changes
and now is sort of evolvedinto much more of a
it's a fintechwith a banking history behind it.
So it has a nice network of correspondents
in Africaand other countries all around the world.
(18:29):
But actually at the heart of the front,it's becoming more and more of a fintech
embracing payments.
But there are legacy banking systemsin there with nice sort of XML based APIs
and a couple of systems that you haveto talk to where we actually just invoke
stored procedures on a databasebecause that's all that's there.
And we're trying to sort of
wrap those with APIsto make that much more integrated.
(18:51):
Okay. But again,keep treating them in their own context.
So the details of those systemsas they gradually move away and change
over timeand get replaced by newer systems
that we're trying to make sure thatwe don't build our our new fintech stuff,
all that sort of foundation where we'retied to whatever those old services were.
(19:12):
And that'swhere the domain modeling really comes in.
Is this define a domain for thatthat we don't necessarily worry
about exactly how it's implementedat the moment.
We know we've got a domaina new domain model
that's backed by an old legacy systemwith a good public contract.
And then as we strip away one of those oldlayers and replace it with a new layer,
(19:32):
hopefully if we've done the domainmodeling right, working with the business
to make sure we've capturedall the concepts that they want,
then we hopefully don't end up with that
change of backend system having to impact on us.
FinTech Payment engine.
Well said.
Yeah.
You know, sometimes I see these threadswhere, you know, it's like
Reddit or StackOverflow or something,
(19:53):
and some of these like, well, clearlyyou're doing it all wrong
because you haven't all designed,you know, designed it all perfect.
And having worked in some places before,like I worked at a place that was like
67 year old manufacturing company,you realize like
on a long enough timeline,there's going to be masses.
And just having it's likedressing up the order,
(20:13):
taking window because nobody wants to takea tour in the kitchen, right?
Like, just make sure that that contractis clean and then you can swap out
the underlying implementationby trim off all the capillaries
of sideloaded traffic, right?
It's at scale.
It's kind of the only way to do it.
As much as, you know, idealists whohaven't seen it might have other ideas.
(20:35):
So I can totally respect that,I guess other other aspects besides and
I know it's it's not exactly a concept,but to me it is a single responsibility.
Are there other aspects of thatfrom a design perspective,
when you think about
scaling out the future of the platformthat you feel have been really powerful
from Didi?
Yeah, that definitely the
(20:56):
sort of the whole concept of context of abounded context that we've got isolation
and there are some really good patternsin there sort of adapt to patterns,
which is how we're sort of managing sortof talking to those systems.
This was a really good stuffin there around
what they call an anti-corruption layer,which is kind of quite good on the API
world, which is all aboutrather than just take taking the concept
(21:18):
of taking the domain modelthat you've got in your in one domain.
So say we've got a domainabout core banking,
so bank accounts and statement entries,we could shift that
straightaway over into our paymentsdomain and build that on the same model.
And actually it's okay.
We want to debit money from an account,credit money to a different account.
But actually you're you're then bringingthe concepts of one domain inside another.
(21:43):
And that creates that sort of fragilitybetween the two.
So that's sort of the anti-corruptionthere indeed
kind of says rather than doing that,what you do is you make sure
that your banking domain exposes something
which is meaningful to the paymentsdomain, but not its internal details.
And then when you bring that
into the payments debate,we actually transform it from
(22:03):
that into a payment domain model worldand then manipulate it in there.
So it's a it's a transformationbetween one domain and another,
rather than exposing the details of oneinto another across the API.
And that then means that the two can moveat different paces and develop
as long as they as long as you maintainthat transformation from one to the other,
(22:24):
you actually get that.
You get that
that you break that fragility pattern,which is why it's called anti fragility.
You break that fragility of changesin one place affecting another place.
So that that's something we've really beenfocused on is what is the core.
Again, the single responsibilityof this domain to this other domain.
And let's just encapsulatejust the essence of that in those APIs.
(22:48):
Yeah, for sure.
I don't know.
Again, I feel like that wholehow do you take a big, you know, pile of,
you know, interlaced thingsand peel them apart?
This is why I said that, you know,these are the ways to peel them apart.
Another thing that you
you've mentioned
in kind of some of your writing and stuffis this idea of this Cupid concept,
(23:10):
which I'll admit like news to me untilabout 30 minutes before we got on here.
So tell me more. I'm intrigued.
Yeah.
So, yeah, there's a there's a softwareengineer, sort of architect,
sort of thought leader based in this of UKsoftware development
community called Daniel North,who's quite respected, written a few books
and he started,he came up with this idea of beat
(23:32):
based on looking at the sort of
the original solid principleswhich most anyone who's worked in object
oriented development should understandthe basic, solid principles.
But he started looking at ita slightly different ways, how
those are great for an engineeringpoint of view, but they are sort of
they're almost like a set of rules whereyou have to follow them and it's actually
(23:53):
why do you need a fixed set of rulesthat don't always apply to everything?
So he started looking for a different setof properties
that you could use to describe software
that's really good to work with softwarethat's actually joyful.
Hey, his word is joyful.
So software that's joyful to work withand that we started looking at that
(24:13):
a bit more is actually can those applyto architecture, Can they apply to APIs?
And actually they work really,really well to APIs.
So he's kind of a Cupid.
If I go through the five terms,which is kind of the thing.
So he's to focus much more on the roleof the being principles or rules.
They're morethe more properties that you lose.
(24:35):
So that kind of you, you can evaluatewhere you are along the line.
You don't have to be absolutely dived intointo this layer in the maximum detail.
You can start at the other endand gradually move away,
move along the line of these propertieswhich is why they're
that they're so structured in that way.
But yeah,so the five of properties of Cupid and
(24:56):
there's a if you have a look on his Cupiddot dev website, it's
actually really good explanation,but the first one is composable.
So this is aboutrather than having an API one API
that does something and then another APIwhich has done something
so in a completely different way is mateand so you can chain them together.
So the, the outputs and one API should be
(25:18):
with a small transformation, the inputsto the next step in the workflows.
If you're building a workfor at most main points,
you can just call transform,call, transform,
and then with a sort of a common errorhandling pattern across them all.
So it's actually easyto just build a chain of APIs.
And then if you want a different workflow,you can take out the certain endpoints
that you don't needand replace them with different endpoints
(25:40):
rather than having to rebuild the wholelot with heavyweights of API from scratch.
Yeah, this is thethis is the legacy slide.
Everyone sticks in their APItalk, right? That this is.
Yeah that's that's
what it's about plug and play differentkeep that common capabilities yeah.
Yeah yeah and the second one is
he's called it Unix like which is kind ofto make the Cupid's acronym.
(26:01):
But is that it.
That is the,
that's the single responsibility principleand that whole sort of
like lining stuff together each,each in each endpoint you do one thing
and what you're actually trying tothen do is build a workflow
by composing all these little bitsthat do one thing together well.
And I have to call outfrom like the to Cupid dev site, you know,
And for those not watching video of youtoo, I'm tapping on my heart here
(26:24):
that it's described as Unix philosophywhich this is like a
if you look across software in the lastcall it 50 years if you want
there's no single more
successful thingthan kind of the Unix philosophy of,
you know, if you try to write like a Linuxor UNIX command
(26:44):
line thing,it's got to do one job real good.
And if you embrace that in designperspective, when it comes to APIs,
it just fits, just makes sense,
but yet is still ultimatelysingle responsibility at its core, right?
Yeah, absolutely.
Yeah. Yeah.
And the next one he's got is predictable.
So this is, this is one of my petpeeves on API is where you you call it
(27:07):
you call an API and it does one thingand then you call it another time.
And depending on some kind of stateor some weird
cryptic field value that it does something
completely differentthe next time you call it.
And that's kind of the,the predictability.
It should do the same.
It shouldyou should know what it's going to do
and it should reliably do that for youevery single time.
Yeah,I would argue that, like predictability
(27:29):
in softwareengineering is pervasive like that.
I mean, you know,
like you can ask a team at a stoplight,like first thing I did
when I walked in the doora couple of years ago
says, we're going to get predictableas an organization.
But that boils down through every layerof what you do.
Like something should not have unintendedunintended side effects
as much as you can prevent it. Right?
So yeah, I love that one again.
(27:51):
And then the next next one is idiomatic.
So that's kind of just stuff.
Stuff should work in the wayyou expect it to work.
And again, in the API world,another one of my sort of tech pieces,
people are adding all these sortof extra document elements to re
replicate the error handling that'sactually built into the protocol itself
or sort of re reusing
(28:12):
HP response code in unexpected waysto mean different things
than they actually do mean.
It's like it's there's an idiomatic viewof how APIs should work
within particular protocolsor within particular structure.
Your API should stick to that.
Yeah, I won't go down the rabbit hole,but I will call out here that in the
the show notes that Bailey put togetherfor Chris, it just said Chris hates
(28:34):
GraphQL, so I'm going to leave that onethere next to idiomatic and we'll move on.
Yes, that's a whole other discussion.
Yeah, it is where we don't have time.
Maybe we'll have you backfor that one joke.
And then the final elementis sort of going back to the domain
driven design, which is domain based,so that the API is the stuff
(28:56):
that the names of your APIs,the data structures in your APIs
should be in a meet, have a meaningfuldomain structure that's understandable
to the business and particularlyunderstandable to the client.
And that's one of the thingswe've particularly looking is it's great
if you build a really complex domain,but if the client can't understand that
domain, then actually you've sort of youfailed on the purpose
(29:17):
of making that joyfulfor them to integrate to.
It's it's domain based,but it's got to be a domain that the,
you know, structured in a waythat the client can do with it
rather than just the sort of the engineerswho built it.
Understand.
Yeah, I think it's part of why I likeI tend to have a bit of an allergy to
sometimes folks can be real ideologueswith the TDD stuff because they're looking
(29:37):
at it in this very modularitytechnical perspective.
But like when I talk to product folks
who are learning APIs, it'slike this is about customer centricity.
That's all it really is, right?
If we had to describe our platform on amarker board with a roomful of customers,
would they be able to go,Oh yeah, that's my stuff.
I understand that, right?
(29:57):
If you haven't accomplished that,
then you're just kind of like shouting,aren't you?
Yeah, absolutely.
And again, it's
sort of another example from our worldis and of sanctioned screening
so that we have to do like
for a lot of these paymentsin some countries we have to check for
that we're not sending them to people
who are doing moneylaundering and things like that.
And that's a whole othersort of that's a world of expertise.
(30:19):
And actually you could do that two ways.
You can actually expose all the detailsof sanctioned screening into our payments
domain and make it really complex thatunless you're an absolute expert in that,
that you can't really understandor we kind of ship that into its own
bounded context rapidlytweet traffic behind some APIs
and actually the paymentsdomain just needs to effectively know, oh,
(30:42):
we send this for screening,did it pass or not?
And then that's somethingthat the business
and the clients of thatcan actually understand
without having to dealwith all that sort of those nuances of
of all the various different scenariosit can fail in.
Yeah, it was honestly one of my singlebiggest learnings about my couple of years
in FinTechis that the real hidden game in that space
(31:04):
for people who get all, youknow, zealot, excited about,
Oh, we're going to solve this, it'sgoing to be easy.
So you've got to be good at riskand compliance if you want to go global.
And it takes at least a decadeto figure out all those different markets
and like especially in developing markets,I mean, you're talking about like
go into a windowwith paper to get stuff done sometimes.
So yeah, I totally get that.
(31:25):
Yeah.
I want to reflect real quick though,on this Cupid thing.
I'm totally enamored.
That's probably just because it saidUnix philosophy and it sucked me in, but
I wantto reflect on you started with Solid,
which for listeners who maybe
aren't familiar with this from a softwareengineering perspective
and I'm going to go down this list
(31:45):
and it's not going to be funI'm sorry, listeners, but we got to do it
because I want to show you the contrastsingle responsibility principle.
We talked about that one a lot.
It's easy to understandopen, closed principle.
I don't have time to explain it right now,but list of substitution principle.
I definitely don't have timeto explain that
interface segregation principleand dependency inversion principle.
(32:06):
So, you know, for hardcore softwareengineers are going to go, yes,
that sounds great.
But I do think that the computerscience world sometimes doesn't translate
well into a design context.
And when you're just lookingat designing something, it's,
you know,designing a platform in particular,
you need a set of principlesthat are understandable that everyone
(32:26):
can can kind of groknot just the software engineer.
So I love these kinds of efforts.
There's been a lot of them out there,
but it's it's way like one of
my core ideals is like principles,not frameworks.
Like don't give me a rigid structurebecause every place is different, right?
And I'd imagine you've been in enoughdifferent shops to know this too.
(32:48):
Yeah. Yeah.
If every every place you come across
as a different way of doing itand is definitely that
if you have specific rules or principlesand you try to apply them,
they probably workthe first time you build the software
because it's nice and clean.
But then as soon as youthen try and expand
the software, maintain the software,add new features into the software,
you get into this horrible world ofwhat do I do?
(33:09):
I break the principlesto achieve what I want to do or do I spend
much longer ripping everything apartto insert all the new stuff and maintain
the principles again,which is why sort of something like Cupid,
which takes much more sort of it'sa property, it's not a rigid thing,
it's kind of a guideline.
You should be aiming to try andget to the better end of the guideline,
(33:31):
but it acceptsyou're not there at the moment.
And then you movein that way. It just makes
it makes those it makes your life buildingthe software much easier, having those
guides, but not sort of an absoluterigid set of things that you can follow.
Yeah, every platform projectI've ever worked on, it inevitably becomes
the thing is like,what are our principles?
And I feel like it'skind of like a social contract exercise
(33:54):
where it's not so muchwhat you end up with.
You can have anything from kindergartnersto executives.
The list looks pretty similar in defininga social contract between a group,
but it's about having the discussion andreally embracing ideals for yourselves.
But I feel like this is a fantastic
starting pointand definitely want to dig into it.
So thank you for sharing it.
Excellent. Thank you. Very pleased to.
(34:14):
Well, Chris, I appreciate you having
given some of your very valuabletime to us here in closing.
And if you've ever listened to the podcastbefore, you'll know this is coming.
But we just talked abouta whole lot of stuff that for someone
who's just, you know, kind of setting upto look at the self,
evaluate their own situationmight go, that is overwhelming.
(34:35):
Where do I get started?
What do you think is the most kindof valuable thing to embrace, to start
turning a corner on either transformationor kind of starting from scratch?
And I probably can look definitely
the Q site because that just givesa good outline of that.
And there
there are lots of sort of really good sortof starting tutorials
(34:56):
on domain driven design.
So that's a, that's a good point.
And I've kind of like tried to summarizethose a little bit in my blog post
so you can potentially hunt down
those as a reading point,as a sort of starting point.
I've tried to keep them sort ofnot at a too technical level,
but yeah, I would definitely starthaving a look at just
touching into the domain driven designbecause there's a few basic concepts
(35:18):
like creating a ubiquitous languagethat the business understands,
separating stuffinto those separate concerns.
It just start playing aroundwith some of those ideas
and then the rest kind ofyou can build on gradually after that.
Yeah, So you tried to plug yourself there,but you got to tell us where
where do we goto find your things that you write?
(35:39):
Okay, that's on my
blog, which is softwareI don't ski Postcode UK.
Nice.
Well, Chris, thanks again for coming on
and giving us a little bit of a grimierhands on view of the world.
But I have to say it's it'snot really probably that much different
than the typical management typeswe get on here.
But by the way, thank you so much.
(36:00):
Thanks for listening.
If you have a question you want to ask,look in the description of whichever
platform you're viewing or listening onand there should be a link there
so you can go submit a questionand we'll do our best to find out
the right answer for you.
API Intersection Podcast listeners
are invited to sign up for Stoplightand save up to $650.
(36:22):
Is the code intersectiontend to get 10% off a new subscription
to stoplight platform starter or pro.
Take a look at this episode'sdescription for more details.
Every place you come across as a differentway of doing it and is definitely that.
If you have specific rules or principlesand you try to apply them,
they probably work.
The first time you build the softwarebecause it's nice and clean.
But then as soon as you
then try and expand the software,maintain the software, add
new features into the software,you get into this horrible world of do I
do I break the principlesto achieve what I want to do?
(00:22):
Or do I spend much longerripping everything apart
to insert the new stuff and maintainthe principles again.
I'm Jason Harmonand this is API intersection
where you'll get insights from experiencedAPI practitioners to learn best
practices on things like API design,
governance, identity, versioning and more.
(00:55):
Welcome back to API Intersection.
So I'm not going to say the thing.
I would saythat we're going to do something different
because it's always different, right?
It's I'm reminded every day latelythat APIs are everywhere now.
I mean, if you can touch something,there's probably an API for it.
You just haven't turned it on yet.
So from the UK,
(01:16):
joining me today is Chris Turner,who's actually writes code for a living,
which I have to point outis somewhat unusual for our guest.
So, Chris, thanks for joining.
And tell us a little bit about yourself.
Hi, I'm really glad to be here.
So, yeah, I'mI'm a software engineer in the UK and I'm
still 25 years into my career.
(01:37):
I still my main goal is writing code.
I love writing code and designing systemsand works across a range of domains
from everythingfrom sort of travel reservation,
telecoms, media, e-commerce.
GreenTech But currently I am working for
a really niche UK bank called Crown AgentsBank, and we're sort of a
(02:01):
a specialist bankthat's very specialized in moving money
in between countries, particularlymoving money from the developed world
into developing countries,particularly in Africa,
and using sort of computer systemsand joining up all the APIs
in the various systemsto actually make those these payments
into countries where that moneyreally makes a difference.
(02:24):
Yeah, that's super interesting.
And, you know, I couldn't help but noticeon your profile,
you've been working on this API stufffor quite some time
and, you know, it's like I was saying,they're everywhere now.
So yeah, you end uplearning a lot of different things.
I guess when you look back at allthese different domains,
all these different kind of industries,
where does that kind
of take in your thinkingwhen now you're in fintech and banking,
(02:47):
which I have some experience with,and it's pretty different, but
do you feel like there are sort ofportable things from that that you're now
more focused on and implementing this?
Yeah, definitely.
I think over the years I've been through,again, all the all the standard things
like the journey throughso and all of those things and
still see this thing
(03:08):
that everyone sort ofkind of like creates their own API.
And each API is subtly differentto every other API, which is always makes
a, a fun integration challengeand particularly sort of
what we're doing at Crown Banks.
We've got lots of legacybanking systems, modern banking systems,
and we're also offeringintegrating into banks and mobile
network providers in Africa,which have again, a variety
(03:31):
of different levelsof sophistication on their APIs.
And just looking at that gotwe think started to get us thinking around
how can wehow can we try and create a common view
of all those APIs without trying
to aggregate them all together,because that's never going to happen.
We've just got such a diversityand might spirits have years.
We've shown that it'ssort of try to create generic APIs
(03:55):
is never really worked.
I've always found thatwhat you end up with
is either a horrible giant mess,which is really difficult
to deal with or somethingwhich is like the worst of all worlds.
So what we started to look at is let's,
let's try and focus these APIs around
particular domainsand then use some sort of
(04:15):
the software engineering techniquesthat we use to build good software
and see how we can apply them intothat world of APIs that we're building.
Yeah, it's interesting because I feel like
when I look at theyou mentioned like aggregation
and the idea that you can come up withlike the perfect API for a given vertical,
(04:36):
you know, I'm old enoughand I guess you probably asked you
to rememberlike the days of Oasis and Soap, right?
And we saw these industrygroups get together and say, Well,
let's all agree
between all these different huge companiesas to what the specs should be.
And by the time they're done,no one wants to use it because it's like,
you know, 50,000 fields to do anything.
(04:56):
But it's interesting to see these daysthere's more
and more of these kind of aggregationplatforms
that are trying to make it easierand that sort of thing.
But I'm kind of with you.
It seems like a fleeting goalthat is diminishing returns over time.
Yeah, I've definitely foundin particularly my previous dry work
settings of green tech energy,and we were integrated
(05:17):
with a lot of energy APIsand there were lots of developments
of standards for sort of grid managementand things like that.
But every new providerthat came in with something different
had a bit to add a bit to itand you sort of end up with a core
and all these little extensionsthat go off of their various profiles
and it actually becomes
such a big blob of stuff to tryand get your head around and implement.
(05:39):
It would have
it would have been so much easierjust to have half a dozen very simple APIs
that they understand abilitythat I find would be a much greater.
So is easier to understand, easierto build than trying to sort of create
something that requires
a massive amount of codewith lots of additional statements,
which is hard to testand likely to have a lot more bugs in it.
(06:01):
Yes, it's an interesting facetof what you're doing here
and having some prior experiencein fintech in my time at PayPal,
know, you know, one of the like Americanperspective things that I learned was
the whole worlddoesn't use credit cards to pay for stuff.
And certainly,like I was more involved with Japan
but was aware of of Africa that likemobile phone based payment is the way.
(06:25):
And so,
you know,
I would imagine connecting with all ofthe different sort of telecom providers
and all that sort of stuff, which in thatmarket it's text based payment, right?
So super foreignand seems like impossible to secure, but
so I'd imagine your your perspectiveon consumption here is is somewhat
different too, which is partially the wayyou're describing this problem.
(06:48):
Yeah. Yeah.
It's effectively
yeah every every single providerthat we potentially connect to has got a
that they're very similar because they'reall trying to do mobile payments of money
when we're moving sort of small amountsinto people's mobile accounts,
but they all do itin a slightly different way.
And we, we, we still got some customers,some providers that we integrate to
(07:08):
where are still using portals
and we actually have to web scraped themso they're not even on the API.
I think they'reYeah but but a lot of them are APIs but
there are lots of sort of an Excelbased APIs, I think.
So that and they're,
they're all very subtly differentin terms of exact ideas
and how they representsort of particular data.
So it's kind of quite hard to aggregateall of those into a common approach.
(07:31):
So we do tend to end up with a corebut sort of specific
implementationsfor each sort of each provider
that we're actuallyconnecting to for that.
Yeah,and connecting with that many providers.
I mean, beyond I guess, you know,I would venture to guess you've got sort
of an internal representationof how to aggregate those things
that, you know,you only use for your own implementation.
(07:54):
But how do you look at sortof the resilience of having to connect
all those different things,which I could imagine
in a developing market like Africa,you might have things that go up and down
and they might be a little shakierthan in some other parts of the world.
Yeah, that's absolutely.
We have a, a lot of the coreimplementation of us of our code is around
(08:15):
sort of strategies for dealing with sortof retry mechanisms, back off mechanisms.
And we even have some providerswho, for example, we might have a
a single accountthat we have to log in to.
So we can only make payments sequentially.
So therefore we've then got some back offqueuing mechanisms
and sort of a semaphores
in that we have to kind of createthat actually prevent access
(08:37):
at multiple payments.
Don't try and process that,putting everything in queues.
So it's a whole sort of gambitof different things that we have to
sort of think on top of rather than justthe protocol that we send as well.
It makes it fun.
Yeah, for sure.
I think you just won four new term
on API intersection Semaphore,so congrats.
(09:00):
I don't think I've ever heard anyonemention it before.
CSS people ACA stuffmost people forget about.
Yeah.
They call those core techniques are stillthey're still out there.
There's still they are under the covers.
Absolutely.
So on all this kind of resiliency stuff,
are there specificsort of tools that you know you've used
(09:22):
that have made this easier to deal within terms of, you know, all the back office
and all these things you're talking about,or is this all bespoke?
There's a lot of bespoke stuff,but quite a lot.
We use a framework.
So taking from sort oflike the world of domain driven design,
one of the sort of concepts in thereafter you may have sort of
come across these courts and seek you.
(09:43):
RS Command clearresponsibility, segregation.
So in this area you're having effectivelya stream of events, which is your event
event source,
which is your source of truthand your timeline, and then you from that
you process the events and createvarious views and things.
So we kind of tend to make use of that.
So there's a particular framework,excellent framework,
which is an implementation of that,which is very good and it contains lots of
(10:07):
useful technology for like timing events,setting retry events to trigger
at some point in the future so we cansort of send off a message asynchronously.
Wait, and if it times out,we can then schedule a retry event
to occurat some point in the future to try again.
And we use that to also scheduleevents around managing resources and
the back of that.
(10:28):
So kind of using that sort of thatold audit
trail of all the transaction historythrough that, we can actually use that.
And then everything is
then an event coming back in to triggersort of the the next stage or the retry
or some kind of buildingqueuing mechanism to stack the up.
So it's sort of like a lot of bespoke,but building on some standard core sort of
(10:50):
modeling practices that have been provenover a number of years.
Yeah, I feel like thatit's a thing that always comes up.
I'll say though,I feel like a lot of shops I've been in,
I see folks fail at trying it.
They get halfwayand it's sort of like crass or curious
or somethinglike it's, you know, kind of halfway done.
(11:11):
But the dream is always that, well,we can replay this stuff in
in tests, right?
So have you realized the dreamand can you actually do
the replay of log kind of stuff in test?
We're getting we're getting closer.
We're not we're definitely not there yet,but we are We're definitely at the point
where we can collect the event sourceand we can replay the stream through.
(11:33):
But we probably still gota little bit of work to actually do that.
And that the real challengeis, is when with most of the systems
we're integrating.
So a lot of them are very unreliableand unstable.
So they actually don't even have like testinstances that we can use.
So we can't replay those eventsagainst live services.
And so a lot of the work we're working ontowards now is how can we actually create
(11:55):
a simulation of those servicesthat actually honors the same API contract
and then be able to replay the sequenceof events against the simulation
to test our software.
But then can we use the stream of eventsthen against the actual API to test
that their system is still behavingin the way we expect it to.
So we'vedefinitely got a long way to go on that.
(12:17):
But it's it's going to bea very good journey when we get there.
I think.
Well,I'll say in our experience at a stoplight,
when we see folksusing marking like you're describing,
it's usually a good signof a level of maturity in approach.
It's not usually a thing.
People start with the kind of,you know, learn about it over time.
So that's that's a good sign
On events.
(12:38):
I'm curious and I suppose this is validfor the API side too.
Are you using sort of suspect formatsto describe these things?
Yeah, we again, we just releasedwanting to get into proper
sort of API contractsand things and enforcing those.
So for particularlyfor our sort of our synchronous HTP stuff,
(13:00):
we're starting to get sort of open APIcontracts properly drafted for all those
so that we've got sort of somethingto validate and,
and creating them as wellfor the third parties
that we're integratingbecause most of them don't have that.
They have some,some very flaky documentation quite often.
So actually trying to sort ofbuild some contracts for those as well.
Getting those PDFsin your email. Apps, I mean,
(13:22):
you've got to love that way of working.
It'll never not exist.
It's always going to be a thing somewhere.
So open API for the synchronous stuffon the event side,
are you using anythingin similar fashion for contract?
Not really at the moment,so that's definitely
an interesting area to look at the most.
Fortunately, we're at the point where mostof the systems that we are integrating
(13:46):
with tend to be synchronousand they tend to be fairly unstressed
excited and that we're polling thembecause that's largely what they
they support.
And most of they are sort of converting
that sort of asynchronous eventshappens within our own,
our own landscapeand our own microservices.
So we kind of largely in control of those,but definitely
something we probably need tolook at a bit more is how we kind of
(14:09):
define those and contractthose events moving between the different
sort of the different bounded contextswithin our system.
Yeah, it'sit certainly seems to be a growing
trend of folks that are tryinga more event driven architecture.
And it's like in the same waythat you can kind of get this API sprawl
with the synchronous stuff where,you know, you lose consistency as scale
(14:31):
goes up.
The same thing happens with events.
The upside being,it seems to be predominantly
internally focused,which it sounds like is your story here.
So I guess, you know,we've been talking a lot
about all this stuffyou have to consume to operate,
but I guess if we shift backto kind of that internal focus,
you know,
what do you do to kind of tryto gain some kind of consistency
(14:54):
with what sounds like a real patchworkof external connections?
Yeah.
So so what we've been doing is we'veand it's very much going back to sort of
like 2004 actually, whereby sortof journey on this started and there's a
and chuckled Eric Evans and he wrotea book called Domain Driven design
which is it's one of it'sone of those classic books that
(15:16):
even though it's sort of almost 20 yearsold, it's still,
if everything in it is still relevant,just as relevant today
as it was when he wrote it backall those years ago.
Unlike the books about various frameworkswhich even become obsolete,
this is kind of like one of thosecore books that I go back to all the time.
It's just got so much great material.
I definitely recommend itfor an investigation.
(15:37):
The read,if you haven't sort of come across that.
But one of his main concepts in there is
that the domain is your focus.
And what we've discovered fairlyquickly is actually within our world,
there isn't just one domain,there are lots of different domains.
And where we hadin previous versions of our architecture,
(15:57):
those domains that kind of overlapswith each other a bit.
So concepts from one,it's seeped into another.
So weird, weird, cryptic field valuesor field names or data structures
from, say, the banking domain had sort ofseeped into the payments domain.
And then as the banking domain changes,
then the payments servicesuddenly potentially breaks,
(16:19):
or you have those significant sortof breaks in API contracts between them.
So what we've really beenfocusing is not on this work
is actually looking at let's createa proper bounded context for each domain,
define the domain model inside itof how all the states is structured,
what it looks like,how it integrates with all these services,
(16:39):
but then focus really clearly on thethe contracts
that that provides to other bitsin our infrastructure, other domains.
So have a very clean API model for that
and a really clean set of eventsthat we clarify.
And to document very thoroughly.
And that's the waywe trying to keep that separation so
we can build those two bits independently,different teams, different speeds,
(17:03):
but without allowing 1 to 1to cross-pollinate
too much in the otherinto the other that causes that breakage.
Yeah, it's it's funny, Ithink sometimes people get really wrapped
around the axle with DDT stuffand I'm not saying you are,
but I often have to kind of remind folks,just bring it back down
to like the simplest thing is just singleresponsibility principle, right?
(17:25):
Build the thing to do one thing.
If it takes more than one wordto describe it, you're probably doing it
wrong, right?
If you've got the end or the slashin the name of this capability
or this API, right?
Like take a step back.
Is it really doing a single purpose,you know,
and you don't need to read a bookto understand that idea either.
(17:46):
So it,
it sounds like on kind of the
I'd imagineyou have a lot of legacy things here.
We were talking before
and you're saying this is like a 200 yearold company or something.
Yeah, Yeah.
It's originally a a sort of aa British colonial era
era bank that sort of evolvedevolved over time from sort of
(18:08):
investing in these foreign countries,
sort of part of the British Empire legacy,gone through lots of various changes
and now is sort of evolvedinto much more of a
it's a fintechwith a banking history behind it.
So it has a nice network of correspondents
in Africaand other countries all around the world.
(18:29):
But actually at the heart of the front,it's becoming more and more of a fintech
embracing payments.
But there are legacy banking systemsin there with nice sort of XML based APIs
and a couple of systems that you haveto talk to where we actually just invoke
stored procedures on a databasebecause that's all that's there.
And we're trying to sort of
wrap those with APIsto make that much more integrated.
(18:51):
Okay. But again,keep treating them in their own context.
So the details of those systemsas they gradually move away and change
over timeand get replaced by newer systems
that we're trying to make sure thatwe don't build our our new fintech stuff,
all that sort of foundation where we'retied to whatever those old services were.
(19:12):
And that'swhere the domain modeling really comes in.
Is this define a domain for thatthat we don't necessarily worry
about exactly how it's implementedat the moment.
We know we've got a domaina new domain model
that's backed by an old legacy systemwith a good public contract.
And then as we strip away one of those oldlayers and replace it with a new layer,
(19:32):
hopefully if we've done the domainmodeling right, working with the business
to make sure we've capturedall the concepts that they want,
then we hopefully don't end up with that
change of backend system having to impact on us.
FinTech Payment engine.
Well said.
Yeah.
You know, sometimes I see these threadswhere, you know, it's like
Reddit or StackOverflow or something,
(19:53):
and some of these like, well, clearlyyou're doing it all wrong
because you haven't all designed,you know, designed it all perfect.
And having worked in some places before,like I worked at a place that was like
67 year old manufacturing company,you realize like
on a long enough timeline,there's going to be masses.
And just having it's likedressing up the order,
(20:13):
taking window because nobody wants to takea tour in the kitchen, right?
Like, just make sure that that contractis clean and then you can swap out
the underlying implementationby trim off all the capillaries
of sideloaded traffic, right?
It's at scale.
It's kind of the only way to do it.
As much as, you know, idealists whohaven't seen it might have other ideas.
(20:35):
So I can totally respect that,I guess other other aspects besides and
I know it's it's not exactly a concept,but to me it is a single responsibility.
Are there other aspects of thatfrom a design perspective,
when you think about
scaling out the future of the platformthat you feel have been really powerful
from Didi?
Yeah, that definitely the
(20:56):
sort of the whole concept of context of abounded context that we've got isolation
and there are some really good patternsin there sort of adapt to patterns,
which is how we're sort of managing sortof talking to those systems.
This was a really good stuffin there around
what they call an anti-corruption layer,which is kind of quite good on the API
world, which is all aboutrather than just take taking the concept
(21:18):
of taking the domain modelthat you've got in your in one domain.
So say we've got a domainabout core banking,
so bank accounts and statement entries,we could shift that
straightaway over into our paymentsdomain and build that on the same model.
And actually it's okay.
We want to debit money from an account,credit money to a different account.
But actually you're you're then bringingthe concepts of one domain inside another.
(21:43):
And that creates that sort of fragilitybetween the two.
So that's sort of the anti-corruptionthere indeed
kind of says rather than doing that,what you do is you make sure
that your banking domain exposes something
which is meaningful to the paymentsdomain, but not its internal details.
And then when you bring that
into the payments debate,we actually transform it from
(22:03):
that into a payment domain model worldand then manipulate it in there.
So it's a it's a transformationbetween one domain and another,
rather than exposing the details of oneinto another across the API.
And that then means that the two can moveat different paces and develop
as long as they as long as you maintainthat transformation from one to the other,
(22:24):
you actually get that.
You get that
that you break that fragility pattern,which is why it's called anti fragility.
You break that fragility of changesin one place affecting another place.
So that that's something we've really beenfocused on is what is the core.
Again, the single responsibilityof this domain to this other domain.
And let's just encapsulatejust the essence of that in those APIs.
(22:48):
Yeah, for sure.
I don't know.
Again, I feel like that wholehow do you take a big, you know, pile of,
you know, interlaced thingsand peel them apart?
This is why I said that, you know,these are the ways to peel them apart.
Another thing that you
you've mentioned
in kind of some of your writing and stuffis this idea of this Cupid concept,
(23:10):
which I'll admit like news to me untilabout 30 minutes before we got on here.
So tell me more. I'm intrigued.
Yeah.
So, yeah, there's a there's a softwareengineer, sort of architect,
sort of thought leader based in this of UKsoftware development
community called Daniel North,who's quite respected, written a few books
and he started,he came up with this idea of beat
(23:32):
based on looking at the sort of
the original solid principleswhich most anyone who's worked in object
oriented development should understandthe basic, solid principles.
But he started looking at ita slightly different ways, how
those are great for an engineeringpoint of view, but they are sort of
they're almost like a set of rules whereyou have to follow them and it's actually
(23:53):
why do you need a fixed set of rulesthat don't always apply to everything?
So he started looking for a different setof properties
that you could use to describe software
that's really good to work with softwarethat's actually joyful.
Hey, his word is joyful.
So software that's joyful to work withand that we started looking at that
(24:13):
a bit more is actually can those applyto architecture, Can they apply to APIs?
And actually they work really,really well to APIs.
So he's kind of a Cupid.
If I go through the five terms,which is kind of the thing.
So he's to focus much more on the roleof the being principles or rules.
They're morethe more properties that you lose.
(24:35):
So that kind of you, you can evaluatewhere you are along the line.
You don't have to be absolutely dived intointo this layer in the maximum detail.
You can start at the other endand gradually move away,
move along the line of these propertieswhich is why they're
that they're so structured in that way.
But yeah,so the five of properties of Cupid and
(24:56):
there's a if you have a look on his Cupiddot dev website, it's
actually really good explanation,but the first one is composable.
So this is aboutrather than having an API one API
that does something and then another APIwhich has done something
so in a completely different way is mateand so you can chain them together.
So the, the outputs and one API should be
(25:18):
with a small transformation, the inputsto the next step in the workflows.
If you're building a workfor at most main points,
you can just call transform,call, transform,
and then with a sort of a common errorhandling pattern across them all.
So it's actually easyto just build a chain of APIs.
And then if you want a different workflow,you can take out the certain endpoints
that you don't needand replace them with different endpoints
(25:40):
rather than having to rebuild the wholelot with heavyweights of API from scratch.
Yeah, this is thethis is the legacy slide.
Everyone sticks in their APItalk, right? That this is.
Yeah that's that's
what it's about plug and play differentkeep that common capabilities yeah.
Yeah yeah and the second one is
he's called it Unix like which is kind ofto make the Cupid's acronym.
(26:01):
But is that it.
That is the,
that's the single responsibility principleand that whole sort of
like lining stuff together each,each in each endpoint you do one thing
and what you're actually trying tothen do is build a workflow
by composing all these little bitsthat do one thing together well.
And I have to call outfrom like the to Cupid dev site, you know,
And for those not watching video of youtoo, I'm tapping on my heart here
(26:24):
that it's described as Unix philosophywhich this is like a
if you look across software in the lastcall it 50 years if you want
there's no single more
successful thingthan kind of the Unix philosophy of,
you know, if you try to write like a Linuxor UNIX command
(26:44):
line thing,it's got to do one job real good.
And if you embrace that in designperspective, when it comes to APIs,
it just fits, just makes sense,
but yet is still ultimatelysingle responsibility at its core, right?
Yeah, absolutely.
Yeah. Yeah.
And the next one he's got is predictable.
So this is, this is one of my petpeeves on API is where you you call it
(27:07):
you call an API and it does one thingand then you call it another time.
And depending on some kind of stateor some weird
cryptic field value that it does something
completely differentthe next time you call it.
And that's kind of the,the predictability.
It should do the same.
It shouldyou should know what it's going to do
and it should reliably do that for youevery single time.
Yeah,I would argue that, like predictability
(27:29):
in softwareengineering is pervasive like that.
I mean, you know,
like you can ask a team at a stoplight,like first thing I did
when I walked in the doora couple of years ago
says, we're going to get predictableas an organization.
But that boils down through every layerof what you do.
Like something should not have unintendedunintended side effects
as much as you can prevent it. Right?
So yeah, I love that one again.
(27:51):
And then the next next one is idiomatic.
So that's kind of just stuff.
Stuff should work in the wayyou expect it to work.
And again, in the API world,another one of my sort of tech pieces,
people are adding all these sortof extra document elements to re
replicate the error handling that'sactually built into the protocol itself
or sort of re reusing
(28:12):
HP response code in unexpected waysto mean different things
than they actually do mean.
It's like it's there's an idiomatic viewof how APIs should work
within particular protocolsor within particular structure.
Your API should stick to that.
Yeah, I won't go down the rabbit hole,but I will call out here that in the
the show notes that Bailey put togetherfor Chris, it just said Chris hates
(28:34):
GraphQL, so I'm going to leave that onethere next to idiomatic and we'll move on.
Yes, that's a whole other discussion.
Yeah, it is where we don't have time.
Maybe we'll have you backfor that one joke.
And then the final elementis sort of going back to the domain
driven design, which is domain based,so that the API is the stuff
(28:56):
that the names of your APIs,the data structures in your APIs
should be in a meet, have a meaningfuldomain structure that's understandable
to the business and particularlyunderstandable to the client.
And that's one of the thingswe've particularly looking is it's great
if you build a really complex domain,but if the client can't understand that
domain, then actually you've sort of youfailed on the purpose
(29:17):
of making that joyfulfor them to integrate to.
It's it's domain based,but it's got to be a domain that the,
you know, structured in a waythat the client can do with it
rather than just the sort of the engineerswho built it.
Understand.
Yeah, I think it's part of why I likeI tend to have a bit of an allergy to
sometimes folks can be real ideologueswith the TDD stuff because they're looking
(29:37):
at it in this very modularitytechnical perspective.
But like when I talk to product folks
who are learning APIs, it'slike this is about customer centricity.
That's all it really is, right?
If we had to describe our platform on amarker board with a roomful of customers,
would they be able to go,Oh yeah, that's my stuff.
I understand that, right?
(29:57):
If you haven't accomplished that,
then you're just kind of like shouting,aren't you?
Yeah, absolutely.
And again, it's
sort of another example from our worldis and of sanctioned screening
so that we have to do like
for a lot of these paymentsin some countries we have to check for
that we're not sending them to people
who are doing moneylaundering and things like that.
And that's a whole othersort of that's a world of expertise.
(30:19):
And actually you could do that two ways.
You can actually expose all the detailsof sanctioned screening into our payments
domain and make it really complex thatunless you're an absolute expert in that,
that you can't really understandor we kind of ship that into its own
bounded context rapidlytweet traffic behind some APIs
and actually the paymentsdomain just needs to effectively know, oh,
(30:42):
we send this for screening,did it pass or not?
And then that's somethingthat the business
and the clients of thatcan actually understand
without having to dealwith all that sort of those nuances of
of all the various different scenariosit can fail in.
Yeah, it was honestly one of my singlebiggest learnings about my couple of years
in FinTechis that the real hidden game in that space
(31:04):
for people who get all, youknow, zealot, excited about,
Oh, we're going to solve this, it'sgoing to be easy.
So you've got to be good at riskand compliance if you want to go global.
And it takes at least a decadeto figure out all those different markets
and like especially in developing markets,I mean, you're talking about like
go into a windowwith paper to get stuff done sometimes.
So yeah, I totally get that.
(31:25):
Yeah.
I want to reflect real quick though,on this Cupid thing.
I'm totally enamored.
That's probably just because it saidUnix philosophy and it sucked me in, but
I wantto reflect on you started with Solid,
which for listeners who maybe
aren't familiar with this from a softwareengineering perspective
and I'm going to go down this list
(31:45):
and it's not going to be funI'm sorry, listeners, but we got to do it
because I want to show you the contrastsingle responsibility principle.
We talked about that one a lot.
It's easy to understandopen, closed principle.
I don't have time to explain it right now,but list of substitution principle.
I definitely don't have timeto explain that
interface segregation principleand dependency inversion principle.
(32:06):
So, you know, for hardcore softwareengineers are going to go, yes,
that sounds great.
But I do think that the computerscience world sometimes doesn't translate
well into a design context.
And when you're just lookingat designing something, it's,
you know,designing a platform in particular,
you need a set of principlesthat are understandable that everyone
(32:26):
can can kind of groknot just the software engineer.
So I love these kinds of efforts.
There's been a lot of them out there,
but it's it's way like one of
my core ideals is like principles,not frameworks.
Like don't give me a rigid structurebecause every place is different, right?
And I'd imagine you've been in enoughdifferent shops to know this too.
(32:48):
Yeah. Yeah.
If every every place you come across
as a different way of doing itand is definitely that
if you have specific rules or principlesand you try to apply them,
they probably workthe first time you build the software
because it's nice and clean.
But then as soon as youthen try and expand
the software, maintain the software,add new features into the software,
you get into this horrible world ofwhat do I do?
(33:09):
I break the principlesto achieve what I want to do or do I spend
much longer ripping everything apartto insert all the new stuff and maintain
the principles again,which is why sort of something like Cupid,
which takes much more sort of it'sa property, it's not a rigid thing,
it's kind of a guideline.
You should be aiming to try andget to the better end of the guideline,
(33:31):
but it acceptsyou're not there at the moment.
And then you movein that way. It just makes
it makes those it makes your life buildingthe software much easier, having those
guides, but not sort of an absoluterigid set of things that you can follow.
Yeah, every platform projectI've ever worked on, it inevitably becomes
the thing is like,what are our principles?
And I feel like it'skind of like a social contract exercise
(33:54):
where it's not so muchwhat you end up with.
You can have anything from kindergartnersto executives.
The list looks pretty similar in defininga social contract between a group,
but it's about having the discussion andreally embracing ideals for yourselves.
But I feel like this is a fantastic
starting pointand definitely want to dig into it.
So thank you for sharing it.
Excellent. Thank you. Very pleased to.
(34:14):
Well, Chris, I appreciate you having
given some of your very valuabletime to us here in closing.
And if you've ever listened to the podcastbefore, you'll know this is coming.
But we just talked abouta whole lot of stuff that for someone
who's just, you know, kind of setting upto look at the self,
evaluate their own situationmight go, that is overwhelming.
(34:35):
Where do I get started?
What do you think is the most kindof valuable thing to embrace, to start
turning a corner on either transformationor kind of starting from scratch?
And I probably can look definitely
the Q site because that just givesa good outline of that.
And there
there are lots of sort of really good sortof starting tutorials
(34:56):
on domain driven design.
So that's a, that's a good point.
And I've kind of like tried to summarizethose a little bit in my blog post
so you can potentially hunt down
those as a reading point,as a sort of starting point.
I've tried to keep them sort ofnot at a too technical level,
but yeah, I would definitely starthaving a look at just
touching into the domain driven designbecause there's a few basic concepts
(35:18):
like creating a ubiquitous languagethat the business understands,
separating stuffinto those separate concerns.
It just start playing aroundwith some of those ideas
and then the rest kind ofyou can build on gradually after that.
Yeah, So you tried to plug yourself there,but you got to tell us where
where do we goto find your things that you write?
(35:39):
Okay, that's on my
blog, which is softwareI don't ski Postcode UK.
Nice.
Well, Chris, thanks again for coming on
and giving us a little bit of a grimierhands on view of the world.
But I have to say it's it'snot really probably that much different
than the typical management typeswe get on here.
But by the way, thank you so much.
(36:00):
Thanks for listening.
If you have a question you want to ask,look in the description of whichever
platform you're viewing or listening onand there should be a link there
so you can go submit a questionand we'll do our best to find out
the right answer for you.
API Intersection Podcast listeners
are invited to sign up for Stoplightand save up to $650.
(36:22):
Is the code intersectiontend to get 10% off a new subscription
to stoplight platform starter or pro.
Take a look at this episode'sdescription for more details.
Popular Podcasts
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Therapy Gecko
An unlicensed lizard psychologist travels the universe talking to strangers about absolutely nothing. TO CALL THE GECKO: follow me on https://www.twitch.tv/lyleforever to get a notification for when I am taking calls. I am usually live Mondays, Wednesdays, and Fridays but lately a lot of other times too. I am a gecko.