So let's start for an example here.
Let's say we have a fictitious
e-commerce storefront, Indie's
Custom Threads.
And in this store, and you can order
customized t-shirts kind of like my
nifty API Tateway t-shirt here.
So let's walk through the scenario,
right. We have our users here.
And then they would make the
purchase and look at the t-shirts
on the website through these
different clients, right.
So you have your web application
here, which would be a standard web
browser.
We'd have our mobile client as well,
could be iOS could be Android.
And then we also have a third party
API integration service, right.
So this could be if you want to
integrate your website with say
something like Facebook
or in our case, we have a review
API that's integrated through a
third party. So say, you
see, someone makes a comment about
the t-shirt and they're like
"man..the t-shirt fit
comfortable...but the 50 percent
polyester really gave me a bad skin
rash." That would all be possible
through this third party integrated
service.
So that we establish our users
and our clients,
now, let's take a look at the actual
product detail UI.
So there's a lot of different
functionality, a lot of different
tasks that we've broken down
into these microservices here.
And this originally would be
a monolithic application like we
previously talked about, but we've
broken it apart and segmented
it into different services.
So as you can see,
the first one here is the product
info service.
This would be stuff like, you know,
looking at the t-shirt, what kind of
color is the t-shirt, is it black,
red?
The size of the t-shirt, large,
medium and so on.
And then we have our pricing
service.
We have our order service, if you
want to look at your purchase
history. You got the inventory
service and review service and
so on.
And this is just a handful of
different microservices here.
We could have many more.
So just for this presentation,
we're going to keep it pretty
simple.
OK, so the first
architecture pattern that we could
operate, where we could have users
communicate with these microservices
would be without an API Gateway,
and this would be a
Direct...Client...to...Microservice,
I'm just going to put "svc" for
short, Communication.
So in this approach, in this
architecture pattern, we
have our clients speaking directly
to our microservices, right.
So, say
that this user here
goes to the product detail UI
and wants to look at the product
info, right, and see what kind of
shirt they have.
So it would talk directly
to this service right here.
And then so on, if it will see the
pricing right.
There's another click on the UI.
It would go to this microservice and
so on. So, this
client is speaking to all these
individual services right here,
and this is completely fine and this
operates really well for like a
small application, but has you start
to grow and add more functionality
and more services to your product
UI page, you're going
to have many more calls, right, API
request.
And this is not ideal for
that once you start to grow.
So trying to scale
something like this can be very
cumbersome and be very problematic,
both for the user and the
development team.
So let's take a look at some of
those pitfalls that you may run
into.
The first one
is,
too many round trips.
You're probably wondering what the
hell is round trip, right?
Well, round trip,
in this instance,
is discussing
going from the client all the
way to the product info service,
right? So again, say you don't
want a black t-shirt, you want a red
one.
And maybe instead of large,
you want to get one for your child
who's a youth size
and the price goes
down.
So this service will need to
communicate if this service,
but it'll have to go all the way
back, all the way back to the client
and then go all the way back to this
pricing service and then all the way
back and so on.
So as you can see,
there's a lot of traffic going
across the network here, and
this causes a major significant
latency issue.
So the page loads very
slow.
You're going to have to wait.
It's not very user friendly.
And then again, the development
experience is not great for
developers because you've got to
maintain all this traffic and
there's just so much room for error
using this model.
So another issue to think about
is cross-cutting, right.
So by cross-cutting,
this would be the issues dealing
with the actual
internet protocols that your clients
are using.
For the most part, it's most likely
you will being using HTTPS, where
the "S" would be a security
credential that you've got to get
certified.
But every now and then you're going
to have some server side protocols
say something like AMQP,
which is Advanced Messaging
Queuing Protocol, and
you're not able to do that with this
model because you have
to be consistent, have the same
common functionality of all these
services, right.
So you're very limited with your
resource, right, your resource pool
as far as who can operate and make
a purchase on your site.
Another issue is security,
and this is a big one, especially
nowadays, as we're seeing more and
more, you know,
large enterprises being hacked and
so on.
So, in this
model, all these microservices
are exposed externally, right.
They're all public facing so they
can operate with these clients
here. So there's a lot
of room getting hacked right here.
So you have a larger footprint
that's susceptible to getting
hacked. And ideally,
you would have a central
hub that can manage that for you'd
have like a layer, a barrier
to block you from all that.
But again,
this is just in this model.
And the last real quick
pitfall that I just want to cover
briefly is coupling, right.
So again, as we talked about
previously about the whole
monolithic to microservice
architecture, right.
So you're taking this large
application and you're segmenting
it into smaller microservices,
which is great and we've done that
here. But microservices
over time can start to become more
tightly coupled and reliant upon
each other. So that's something you
want to be mindful of, especially
in this architecture pattern,
because you have so many
communication channels going back
and forth. And again, like the
product info service, right was
relying upon their pricing service
in certain instances.
If this product info services be
maintained and updated, that
could be contingent on
this other pricing service if
it's operating and they could affect
each other. So if one
goes down another one go down, it
could have s cascade effect
where you know your services are
operational.
And then again, it's all about
your user experience.
It's not ideal for a user if one
service goes down and they're not
able to operate and then another
service goes down.
So you really want to try to
mitigate that.
So a is another thing to be
mindful of in this architecture
pattern. So I hope this quick
overview of Direct
Client-to-Microservice Communication
architecture has been helpful for
you.
Again, it's not a bad option if
you're going to have one single API
that's only read only.
However, if you're going to scale
out your application in the future
and you're going to have much more
functionality and features added,
as well as having more API requests
come in, then you really want
to consider implementing an API
gateway to help mitigate all these
issues. We went over in the video.
So again, thank you so much for
watching, and please don't forget
to hit that subscribe button.
As always, thank you.
If you have questions, please drop
us a line below.
If you want to see more videos like
this in the future, please like
and subscribe.