Subscribe
Share
Share
Embed
Building a successful API requires more than just coding.
It starts with collaborative design, focuses on creating a great developer experience, and ends with getting your company on board, maintaining consistency, and maximizing your API’s profitability.
In the API Intersection, you’ll learn from experienced API practitioners who transformed their organizations, and get tangible advice to build quality APIs with collaborative API-first design.
Jason Harmon brings over a decade of industry-recognized REST API experience to discuss topics around API design, governance, identity/auth versioning, and more.
They’ll answer listener questions, and discuss best practices on API design (definition, modeling, grammar), Governance (multi-team design, reviewing new API’s), Platform Transformation (culture, internal education, versioning) and more.
They’ll also chat with experienced API practitioners from a wide array of industries to draw out practical takeaways and insights you can use.
Have a question for the podcast? DM us or tag us on Twitter at @stoplightio.
Every place you come across as a different
way of doing it and is definitely that.
If you have specific rules or principles
and you try to apply them,
they probably work.
The first time you build the software
because 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 principles
to achieve what I want to do?
Or do I spend much longer
ripping everything apart
to insert the new stuff and maintain
the principles again.
I'm Jason Harmon
and this is API intersection
where you'll get insights from experienced
API practitioners to learn best
practices on things like API design,
governance, identity, versioning and more.
Welcome back to API Intersection.
So I'm not going to say the thing.
I would say
that we're going to do something different
because it's always different, right?
It's I'm reminded every day lately
that 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,
joining me today is Chris Turner,
who's actually writes code for a living,
which I have to point out
is 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'm
I'm a software engineer in the UK and I'm
still 25 years into my career.
I still my main goal is writing code.
I love writing code and designing systems
and works across a range of domains
from everything
from sort of travel reservation,
telecoms, media, e-commerce.
GreenTech But currently I am working for
a really niche UK bank called Crown Agents
Bank, and we're sort of a
a specialist bank
that's very specialized in moving money
in between countries, particularly
moving money from the developed world
into developing countries,
particularly in Africa,
and using sort of computer systems
and joining up all the APIs
in the various systems
to actually make those these payments
into countries where that money
really makes a difference.
Yeah, that's super interesting.
And, you know, I couldn't help but notice
on your profile,
you've been working on this API stuff
for quite some time
and, you know, it's like I was saying,
they're everywhere now.
So yeah, you end up
learning a lot of different things.
I guess when you look back at all
these different domains,
all these different kind of industries,
where does that kind
of take in your thinking
when now you're in fintech and banking,
which I have some experience with,
and it's pretty different, but
do you feel like there are sort of
portable 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 through
so and all of those things and
still see this thing
that everyone sort of
kind of like creates their own API.
And each API is subtly different
to every other API, which is always makes
a, a fun integration challenge
and particularly sort of
what we're doing at Crown Banks.
We've got lots of legacy
banking systems, modern banking systems,
and we're also offering
integrating into banks and mobile
network providers in Africa,
which have again, a variety
of different levels
of sophistication on their APIs.
And just looking at that got
we think started to get us thinking around
how can we
how 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 diversity
and might spirits have years.
We've shown that it's
sort of try to create generic APIs
is never really worked.
I've always found that
what you end up with
is either a horrible giant mess,
which is really difficult
to deal with or something
which 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 domains
and then use some sort of
the software engineering techniques
that we use to build good software
and see how we can apply them into
that world of APIs that we're building.
Yeah, it's interesting because I feel like
when I look at the
you mentioned like aggregation
and the idea that you can come up with
like the perfect API for a given vertical,
you know, I'm old enough
and I guess you probably asked you
to remember
like the days of Oasis and Soap, right?
And we saw these industry
groups get together and say, Well,
let's all agree
between all these different huge companies
as 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.
But it's interesting to see these days
there's more
and more of these kind of aggregation
platforms
that are trying to make it easier
and that sort of thing.
But I'm kind of with you.
It seems like a fleeting goal
that is diminishing returns over time.
Yeah, I've definitely found
in particularly my previous dry work
settings of green tech energy,
and we were integrated
with a lot of energy APIs
and there were lots of developments
of standards for sort of grid management
and things like that.
But every new provider
that came in with something different
had a bit to add a bit to it
and you sort of end up with a core
and all these little extensions
that go off of their various profiles
and it actually becomes
such a big blob of stuff to try
and get your head around and implement.
It would have
it would have been so much easier
just to have half a dozen very simple APIs
that they understand ability
that I find would be a much greater.
So is easier to understand, easier
to build than trying to sort of create
something that requires
a massive amount of code
with lots of additional statements,
which is hard to test
and likely to have a lot more bugs in it.
Yes, it's an interesting facet
of what you're doing here
and having some prior experience
in fintech in my time at PayPal,
know, you know, one of the like American
perspective things that I learned was
the whole world
doesn't use credit cards to pay for stuff.
And certainly,
like I was more involved with Japan
but was aware of of Africa that like
mobile phone based payment is the way.
And so,
you know,
I would imagine connecting with all of
the different sort of telecom providers
and all that sort of stuff, which in that
market it's text based payment, right?
So super foreign
and seems like impossible to secure, but
so I'd imagine your your perspective
on consumption here is is somewhat
different too, which is partially the way
you're describing this problem.
Yeah. Yeah.
It's effectively
yeah every every single provider
that we potentially connect to has got a
that they're very similar because they're
all trying to do mobile payments of money
when we're moving sort of small amounts
into people's mobile accounts,
but they all do it
in a slightly different way.
And we, we, we still got some customers,
some providers that we integrate to
where are still using portals
and we actually have to web scraped them
so they're not even on the API.
I think they're
Yeah but but a lot of them are APIs but
there are lots of sort of an Excel
based APIs, I think.
So that and they're,
they're all very subtly different
in terms of exact ideas
and how they represent
sort of particular data.
So it's kind of quite hard to aggregate
all of those into a common approach.
So we do tend to end up with a core
but sort of specific
implementations
for each sort of each provider
that we're actually
connecting 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 representation
of how to aggregate those things
that, you know,
you only use for your own implementation.
But how do you look at sort
of 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 shakier
than in some other parts of the world.
Yeah, that's absolutely.
We have a, a lot of the core
implementation of us of our code is around
sort of strategies for dealing with sort
of retry mechanisms, back off mechanisms.
And we even have some providers
who, for example, we might have a
a single account
that we have to log in to.
So we can only make payments sequentially.
So therefore we've then got some back off
queuing mechanisms
and sort of a semaphores
in that we have to kind of create
that actually prevent access
at multiple payments.
Don't try and process that,
putting everything in queues.
So it's a whole sort of gambit
of different things that we have to
sort of think on top of rather than just
the 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.
I don't think I've ever heard anyone
mention it before.
CSS people ACA stuff
most people forget about.
Yeah.
They call those core techniques are still
they're still out there.
There's still they are under the covers.
Absolutely.
So on all this kind of resiliency stuff,
are there specific
sort of tools that you know you've used
that have made this easier to deal with
in 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 of
like the world of domain driven design,
one of the sort of concepts in there
after you may have sort of
come across these courts and seek you.
RS Command clear
responsibility, segregation.
So in this area you're having effectively
a stream of events, which is your event
event source,
which is your source of truth
and your timeline, and then you from that
you process the events and create
various 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
useful technology for like timing events,
setting retry events to trigger
at some point in the future so we can
sort of send off a message asynchronously.
Wait, and if it times out,
we can then schedule a retry event
to occur
at some point in the future to try again.
And we use that to also schedule
events around managing resources and
the back of that.
So kind of using that sort of that
old audit
trail of all the transaction history
through that, we can actually use that.
And then everything is
then an event coming back in to trigger
sort of the the next stage or the retry
or some kind of building
queuing mechanism to stack the up.
So it's sort of like a lot of bespoke,
but building on some standard core sort of
modeling practices that have been proven
over a number of years.
Yeah, I feel like that
it'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 halfway
and it's sort of like crass or curious
or something
like it's, you know, kind of halfway done.
But the dream is always that, well,
we can replay this stuff in
in tests, right?
So have you realized the dream
and 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 source
and we can replay the stream through.
But we probably still got
a little bit of work to actually do that.
And that the real challenge
is, is when with most of the systems
we're integrating.
So a lot of them are very unreliable
and unstable.
So they actually don't even have like test
instances that we can use.
So we can't replay those events
against live services.
And so a lot of the work we're working on
towards now is how can we actually create
a simulation of those services
that actually honors the same API contract
and then be able to replay the sequence
of events against the simulation
to test our software.
But then can we use the stream of events
then against the actual API to test
that their system is still behaving
in the way we expect it to.
So we've
definitely got a long way to go on that.
But it's it's going to be
a very good journey when we get there.
I think.
Well,
I'll say in our experience at a stoplight,
when we see folks
using marking like you're describing,
it's usually a good sign
of 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.
I'm curious and I suppose this is valid
for the API side too.
Are you using sort of suspect formats
to describe these things?
Yeah, we again, we just released
wanting to get into proper
sort of API contracts
and things and enforcing those.
So for particularly
for our sort of our synchronous HTP stuff,
we're starting to get sort of open API
contracts properly drafted for all those
so that we've got sort of something
to validate and,
and creating them as well
for the third parties
that we're integrating
because most of them don't have that.
They have some,
some very flaky documentation quite often.
So actually trying to sort of
build some contracts for those as well.
Getting those PDFs
in your email. Apps, I mean,
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 stuff
on the event side,
are you using anything
in 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 most
of the systems that we are integrating
with tend to be synchronous
and they tend to be fairly unstressed
excited and that we're polling them
because that's largely what they
they support.
And most of they are sort of converting
that sort of asynchronous events
happens within our own,
our own landscape
and our own microservices.
So we kind of largely in control of those,
but definitely
something we probably need to
look at a bit more is how we kind of
define those and contract
those events moving between the different
sort of the different bounded contexts
within our system.
Yeah, it's
it certainly seems to be a growing
trend of folks that are trying
a more event driven architecture.
And it's like in the same way
that you can kind of get this API sprawl
with the synchronous stuff where,
you know, you lose consistency as scale
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 stuff
you have to consume to operate,
but I guess if we shift back
to kind of that internal focus,
you know,
what do you do to kind of try
to gain some kind of consistency
with what sounds like a real patchwork
of external connections?
Yeah.
So so what we've been doing is we've
and it's very much going back to sort of
like 2004 actually, whereby sort
of journey on this started and there's a
and chuckled Eric Evans and he wrote
a book called Domain Driven design
which is it's one of it's
one of those classic books that
even though it's sort of almost 20 years
old, it's still,
if everything in it is still relevant,
just as relevant today
as it was when he wrote it back
all those years ago.
Unlike the books about various frameworks
which even become obsolete,
this is kind of like one of those
core books that I go back to all the time.
It's just got so much great material.
I definitely recommend it
for an investigation.
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 fairly
quickly is actually within our world,
there isn't just one domain,
there are lots of different domains.
And where we had
in previous versions of our architecture,
those domains that kind of overlaps
with each other a bit.
So concepts from one,
it's seeped into another.
So weird, weird, cryptic field values
or field names or data structures
from, say, the banking domain had sort of
seeped into the payments domain.
And then as the banking domain changes,
then the payments service
suddenly potentially breaks,
or you have those significant sort
of breaks in API contracts between them.
So what we've really been
focusing is not on this work
is actually looking at let's create
a proper bounded context for each domain,
define the domain model inside it
of how all the states is structured,
what it looks like,
how it integrates with all these services,
but then focus really clearly on the
the contracts
that that provides to other bits
in our infrastructure, other domains.
So have a very clean API model for that
and a really clean set of events
that we clarify.
And to document very thoroughly.
And that's the way
we trying to keep that separation so
we can build those two bits independently,
different teams, different speeds,
but without allowing 1 to 1
to cross-pollinate
too much in the other
into the other that causes that breakage.
Yeah, it's it's funny, I
think sometimes people get really wrapped
around the axle with DDT stuff
and 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 single
responsibility principle, right?
Build the thing to do one thing.
If it takes more than one word
to describe it, you're probably doing it
wrong, right?
If you've got the end or the slash
in 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 book
to understand that idea either.
So it,
it sounds like on kind of the
I'd imagine
you have a lot of legacy things here.
We were talking before
and you're saying this is like a 200 year
old company or something.
Yeah, Yeah.
It's originally a a sort of a
a British colonial era
era bank that sort of evolved
evolved over time from sort of
investing in these foreign countries,
sort of part of the British Empire legacy,
gone through lots of various changes
and now is sort of evolved
into much more of a
it's a fintech
with a banking history behind it.
So it has a nice network of correspondents
in Africa
and other countries all around the world.
But actually at the heart of the front,
it's becoming more and more of a fintech
embracing payments.
But there are legacy banking systems
in there with nice sort of XML based APIs
and a couple of systems that you have
to talk to where we actually just invoke
stored procedures on a database
because that's all that's there.
And we're trying to sort of
wrap those with APIs
to make that much more integrated.
Okay. But again,
keep treating them in their own context.
So the details of those systems
as they gradually move away and change
over time
and get replaced by newer systems
that we're trying to make sure that
we don't build our our new fintech stuff,
all that sort of foundation where we're
tied to whatever those old services were.
And that's
where the domain modeling really comes in.
Is this define a domain for that
that we don't necessarily worry
about exactly how it's implemented
at the moment.
We know we've got a domain
a new domain model
that's backed by an old legacy system
with a good public contract.
And then as we strip away one of those old
layers and replace it with a new layer,
hopefully if we've done the domain
modeling right, working with the business
to make sure we've captured
all the concepts that they want,
then we hopefully don't end up with that
change of back
end system having to impact on us.
FinTech Payment engine.
Well said.
Yeah.
You know, sometimes I see these threads
where, you know, it's like
Reddit or StackOverflow or something,
and some of these like, well, clearly
you'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 like
dressing up the order,
taking window because nobody wants to take
a tour in the kitchen, right?
Like, just make sure that that contract
is clean and then you can swap out
the underlying implementation
by 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 who
haven't seen it might have other ideas.
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 that
from a design perspective,
when you think about
scaling out the future of the platform
that you feel have been really powerful
from Didi?
Yeah, that definitely the
sort of the whole concept of context of a
bounded context that we've got isolation
and there are some really good patterns
in there sort of adapt to patterns,
which is how we're sort of managing sort
of talking to those systems.
This was a really good stuff
in there around
what they call an anti-corruption layer,
which is kind of quite good on the API
world, which is all about
rather than just take taking the concept
of taking the domain model
that you've got in your in one domain.
So say we've got a domain
about core banking,
so bank accounts and statement entries,
we could shift that
straightaway over into our payments
domain 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 bringing
the concepts of one domain inside another.
And that creates that sort of fragility
between the two.
So that's sort of the anti-corruption
there 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 payments
domain, but not its internal details.
And then when you bring that
into the payments debate,
we actually transform it from
that into a payment domain model world
and then manipulate it in there.
So it's a it's a transformation
between one domain and another,
rather than exposing the details of one
into another across the API.
And that then means that the two can move
at different paces and develop
as long as they as long as you maintain
that transformation from one to the other,
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 changes
in one place affecting another place.
So that that's something we've really been
focused on is what is the core.
Again, the single responsibility
of this domain to this other domain.
And let's just encapsulate
just the essence of that in those APIs.
Yeah, for sure.
I don't know.
Again, I feel like that whole
how do you take a big, you know, pile of,
you know, interlaced things
and 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 stuff
is this idea of this Cupid concept,
which I'll admit like news to me until
about 30 minutes before we got on here.
So tell me more. I'm intrigued.
Yeah.
So, yeah, there's a there's a software
engineer, sort of architect,
sort of thought leader based in this of UK
software development
community called Daniel North,
who's quite respected, written a few books
and he started,
he came up with this idea of beat
based on looking at the sort of
the original solid principles
which most anyone who's worked in object
oriented development should understand
the basic, solid principles.
But he started looking at it
a slightly different ways, how
those are great for an engineering
point of view, but they are sort of
they're almost like a set of rules where
you have to follow them and it's actually
why do you need a fixed set of rules
that don't always apply to everything?
So he started looking for a different set
of properties
that you could use to describe software
that's really good to work with software
that's actually joyful.
Hey, his word is joyful.
So software that's joyful to work with
and that we started looking at that
a bit more is actually can those apply
to 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 role
of the being principles or rules.
They're more
the more properties that you lose.
So that kind of you, you can evaluate
where you are along the line.
You don't have to be absolutely dived into
into this layer in the maximum detail.
You can start at the other end
and gradually move away,
move along the line of these properties
which is why they're
that they're so structured in that way.
But yeah,
so the five of properties of Cupid and
there's a if you have a look on his Cupid
dot dev website, it's
actually really good explanation,
but the first one is composable.
So this is about
rather than having an API one API
that does something and then another API
which has done something
so in a completely different way is mate
and so you can chain them together.
So the, the outputs and one API should be
with a small transformation, the inputs
to the next step in the workflows.
If you're building a work
for at most main points,
you can just call transform,
call, transform,
and then with a sort of a common error
handling pattern across them all.
So it's actually easy
to 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 need
and replace them with different endpoints
rather than having to rebuild the whole
lot with heavyweights of API from scratch.
Yeah, this is the
this is the legacy slide.
Everyone sticks in their API
talk, right? That this is.
Yeah that's that's
what it's about plug and play different
keep that common capabilities yeah.
Yeah yeah and the second one is
he's called it Unix like which is kind of
to make the Cupid's acronym.
But is that it.
That is the,
that's the single responsibility principle
and that whole sort of
like lining stuff together each,
each in each endpoint you do one thing
and what you're actually trying to
then do is build a workflow
by composing all these little bits
that do one thing together well.
And I have to call out
from like the to Cupid dev site, you know,
And for those not watching video of you
too, I'm tapping on my heart here
that it's described as Unix philosophy
which this is like a
if you look across software in the last
call it 50 years if you want
there's no single more
successful thing
than kind of the Unix philosophy of,
you know, if you try to write like a Linux
or UNIX command
line thing,
it's got to do one job real good.
And if you embrace that in design
perspective, when it comes to APIs,
it just fits, just makes sense,
but yet is still ultimately
single 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 pet
peeves on API is where you you call it
you call an API and it does one thing
and then you call it another time.
And depending on some kind of state
or some weird
cryptic field value that it does something
completely different
the next time you call it.
And that's kind of the,
the predictability.
It should do the same.
It should
you should know what it's going to do
and it should reliably do that for you
every single time.
Yeah,
I would argue that, like predictability
in software
engineering 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 door
a couple of years ago
says, we're going to get predictable
as an organization.
But that boils down through every layer
of what you do.
Like something should not have unintended
unintended side effects
as much as you can prevent it. Right?
So yeah, I love that one again.
And then the next next one is idiomatic.
So that's kind of just stuff.
Stuff should work in the way
you expect it to work.
And again, in the API world,
another one of my sort of tech pieces,
people are adding all these sort
of extra document elements to re
replicate the error handling that's
actually built into the protocol itself
or sort of re reusing
HP response code in unexpected ways
to mean different things
than they actually do mean.
It's like it's there's an idiomatic view
of how APIs should work
within particular protocols
or 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 together
for Chris, it just said Chris hates
GraphQL, so I'm going to leave that one
there 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 back
for that one joke.
And then the final element
is sort of going back to the domain
driven design, which is domain based,
so that the API is the stuff
that the names of your APIs,
the data structures in your APIs
should be in a meet, have a meaningful
domain structure that's understandable
to the business and particularly
understandable to the client.
And that's one of the things
we'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 you
failed on the purpose
of making that joyful
for 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 way
that the client can do with it
rather than just the sort of the engineers
who built it.
Understand.
Yeah, I think it's part of why I like
I tend to have a bit of an allergy to
sometimes folks can be real ideologues
with the TDD stuff because they're looking
at it in this very modularity
technical perspective.
But like when I talk to product folks
who are learning APIs, it's
like this is about customer centricity.
That's all it really is, right?
If we had to describe our platform on a
marker board with a roomful of customers,
would they be able to go,
Oh yeah, that's my stuff.
I understand that, right?
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 world
is and of sanctioned screening
so that we have to do like
for a lot of these payments
in some countries we have to check for
that we're not sending them to people
who are doing money
laundering and things like that.
And that's a whole other
sort of that's a world of expertise.
And actually you could do that two ways.
You can actually expose all the details
of sanctioned screening into our payments
domain and make it really complex that
unless you're an absolute expert in that,
that you can't really understand
or we kind of ship that into its own
bounded context rapidly
tweet traffic behind some APIs
and actually the payments
domain just needs to effectively know, oh,
we send this for screening,
did it pass or not?
And then that's something
that the business
and the clients of that
can actually understand
without having to deal
with all that sort of those nuances of
of all the various different scenarios
it can fail in.
Yeah, it was honestly one of my single
biggest learnings about my couple of years
in FinTech
is that the real hidden game in that space
for people who get all, you
know, zealot, excited about,
Oh, we're going to solve this, it's
going to be easy.
So you've got to be good at risk
and compliance if you want to go global.
And it takes at least a decade
to figure out all those different markets
and like especially in developing markets,
I mean, you're talking about like
go into a window
with paper to get stuff done sometimes.
So yeah, I totally get that.
Yeah.
I want to reflect real quick though,
on this Cupid thing.
I'm totally enamored.
That's probably just because it said
Unix philosophy and it sucked me in, but
I want
to reflect on you started with Solid,
which for listeners who maybe
aren't familiar with this from a software
engineering perspective
and I'm going to go down this list
and it's not going to be fun
I'm sorry, listeners, but we got to do it
because I want to show you the contrast
single responsibility principle.
We talked about that one a lot.
It's easy to understand
open, closed principle.
I don't have time to explain it right now,
but list of substitution principle.
I definitely don't have time
to explain that
interface segregation principle
and dependency inversion principle.
So, you know, for hardcore software
engineers are going to go, yes,
that sounds great.
But I do think that the computer
science world sometimes doesn't translate
well into a design context.
And when you're just looking
at designing something, it's,
you know,
designing a platform in particular,
you need a set of principles
that are understandable that everyone
can can kind of grok
not 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 structure
because every place is different, right?
And I'd imagine you've been in enough
different shops to know this too.
Yeah. Yeah.
If every every place you come across
as a different way of doing it
and is definitely that
if you have specific rules or principles
and you try to apply them,
they probably work
the first time you build the software
because 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
what do I do?
I break the principles
to achieve what I want to do or do I spend
much longer ripping everything apart
to 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's
a property, it's not a rigid thing,
it's kind of a guideline.
You should be aiming to try and
get to the better end of the guideline,
but it accepts
you're not there at the moment.
And then you move
in that way. It just makes
it makes those it makes your life building
the software much easier, having those
guides, but not sort of an absolute
rigid set of things that you can follow.
Yeah, every platform project
I've ever worked on, it inevitably becomes
the thing is like,
what are our principles?
And I feel like it's
kind of like a social contract exercise
where it's not so much
what you end up with.
You can have anything from kindergartners
to executives.
The list looks pretty similar in defining
a social contract between a group,
but it's about having the discussion and
really embracing ideals for yourselves.
But I feel like this is a fantastic
starting point
and definitely want to dig into it.
So thank you for sharing it.
Excellent. Thank you. Very pleased to.
Well, Chris, I appreciate you having
given some of your very valuable
time to us here in closing.
And if you've ever listened to the podcast
before, you'll know this is coming.
But we just talked about
a whole lot of stuff that for someone
who's just, you know, kind of setting up
to look at the self,
evaluate their own situation
might go, that is overwhelming.
Where do I get started?
What do you think is the most kind
of valuable thing to embrace, to start
turning a corner on either transformation
or kind of starting from scratch?
And I probably can look definitely
the Q site because that just gives
a good outline of that.
And there
there are lots of sort of really good sort
of starting tutorials
on domain driven design.
So that's a, that's a good point.
And I've kind of like tried to summarize
those 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 of
not at a too technical level,
but yeah, I would definitely start
having a look at just
touching into the domain driven design
because there's a few basic concepts
like creating a ubiquitous language
that the business understands,
separating stuff
into those separate concerns.
It just start playing around
with some of those ideas
and then the rest kind of
you can build on gradually after that.
Yeah, So you tried to plug yourself there,
but you got to tell us where
where do we go
to find your things that you write?
Okay, that's on my
blog, which is software
I don't ski Postcode UK.
Nice.
Well, Chris, thanks again for coming on
and giving us a little bit of a grimier
hands on view of the world.
But I have to say it's it's
not really probably that much different
than the typical management types
we get on here.
But by the way, thank you so much.
Thanks for listening.
If you have a question you want to ask,
look in the description of whichever
platform you're viewing or listening on
and there should be a link there
so you can go submit a question
and we'll do our best to find out
the right answer for you.
API Intersection Podcast listeners
are invited to sign up for Stoplight
and save up to $650.
Is the code intersection
tend to get 10% off a new subscription
to stoplight platform starter or pro.
Take a look at this episode's
description for more details.