Direct API communication vs. API gateway | IT Depends

00:00 → 00:02

How should your front end communicate with the back end?

00:02 → 00:07

Is direct link with the service through an API always the right solution?

00:07 → 00:10

Or should you rather create something like a gateway that

00:10 → 00:11

will forward your request?

00:11 → 00:15

As always, it depends. Let me shed some light onto it.

00:21 → 00:24

Let's start with the pros and cons of direct communication

00:24 → 00:25

with the server.

00:25 → 00:26

Third party providers.

00:26 → 00:30

Direct communication through an API is a good choice when you

00:30 → 00:33

don't plan to develop your solution for a specific need

00:33 → 00:35

and rely on third party providers.

00:35 → 00:38

That's the case of the integrations with different

00:38 → 00:41

applications via an API such as Google services,

00:41 → 00:43

maps, or Gmail.

00:43 → 00:47

That's often an efficient solution for new businesses and startups.

00:47 → 00:51

It saves time and money and helps you focus on developing your business.

00:51 → 00:52

Small apps.

00:52 → 00:56

If you've developed a small microservice based application,

00:56 → 01:00

then sending requests directly to that service might be a good option for you.

01:00 → 01:04

It can work well especially when the client solution is a

01:04 → 01:06

service side web app.

01:06 → 01:08

This approach is also beneficial for your

01:08 → 01:11

developers that would like to have full control over the

01:11 → 01:13

requests sent to the server.

01:13 → 01:14

Coupling.

01:14 → 01:17

When a client's app communicates directly with the

01:17 → 01:19

microservices, they're coupled.

01:19 → 01:22

The client needs to know how the app is structured and

01:22 → 01:25

decomposed into microservices.

01:25 → 01:28

Its composition complexity can translate into serious problems

01:28 → 01:30

with the entire app maintenance.

01:30 → 01:33

Any major change or code refactoring introduced to your

01:33 → 01:36

back end will impact your app's performance.

01:36 → 01:39

This will force you to update your application more

01:39 → 01:41

often, slowing your business operations.

01:41 → 01:43

Bad user experience.

01:43 → 01:45

Nobody likes to use slow apps,

01:45 → 01:49

and if your application sends multiple requests to different services,

01:49 → 01:53

it can result into many round trips between the client and the server.

01:53 → 01:55

The outcome is simple.

01:55 → 01:58

Poor user experience caused by the network latency.

01:58 → 02:00

Okay. But what about the other option?

02:00 → 02:02

How does the API gateway work?

02:02 → 02:06

And what are the advantages and limitations of this approach?

02:06 → 02:08

Advanced applications.

02:08 → 02:11

When the application is based on microservices,

02:11 → 02:15

the client will need to handle multiple calls to the endpoints.

02:15 → 02:17

This workflow can be very time consuming,

02:17 → 02:20

especially when your app is evolving.

02:20 → 02:23

Sending requests from different clients like web apps,

02:23 → 02:26

mobile apps, or single page applications also causes

02:26 → 02:29

problem with direct communication.

02:29 → 02:33

In this case, implementing an API gateway is the right solution.

02:33 → 02:36

It stands between the client apps and the microservices.

02:36 → 02:40

Client apps connect only to a single endpoint, the gateway,

02:40 → 02:43

which sends requests to individual services,

02:43 → 02:47

gathers a response, and sends it back to the client.

02:47 → 02:48

Security.

02:48 → 02:51

An API gateway is also a good choice when implementing

02:51 → 02:54

advanced security functionalities such as

02:54 → 02:55

authentication.

02:55 → 02:58

Each microservice needs to know if the client is allowed to

02:58 → 03:00

retrieve data.

03:00 → 03:03

Implementing it to the API gateway will work well for all

03:03 → 03:06

microservices as the authentication process is

03:06 → 03:10

performed along with the request being sent to the gateway.

03:10 → 03:13

If the URLs of your requests are well structured,

03:13 → 03:17

the gateway will know if you're allowed to get the data from the service.

03:17 → 03:20

This solution is much more secure than direct

03:20 → 03:23

communication because the microservices endpoints are not

03:23 → 03:27

public and the space for possible hacker attacks is much smaller.

03:27 → 03:29

Downtime.

03:29 → 03:32

When your business grows, the architecture needs to

03:32 → 03:34

accommodate new clients, the demand grows,

03:34 → 03:37

and new requirements arise.

03:37 → 03:41

Over time, your solution starts to look like a monolith or speaking

03:41 → 03:44

more directly like an inflated balloon that's about to burst.

03:44 → 03:49

Remember that the API gateway is coupled with your microservices.

03:49 → 03:53

If this balloon bursts, the same happens to your application.

03:53 → 03:57

The optimal solution here is to stick to the back end for front end pattern.

03:57 → 04:00

It involves creating a few different API gateways,

04:00 → 04:05

each for every client that will try to send requests to the microservices.

04:05 → 04:06

Team capabilities.

04:06 → 04:10

The last thing you should consider is your team capabilities.

04:10 → 04:14

Building an API gateway requires a full time job of a

04:14 → 04:15

back end developer.

04:15 → 04:18

Sometimes a team of full stack developers can work too.

04:18 → 04:21

But if they all have the front end background,

04:21 → 04:24

the solution might lack some crucial back end logic.

04:24 → 04:26

And lastly, as I've mentioned before,

04:26 → 04:30

some developers would not be satisfied with the API gateway

04:30 → 04:34

solution as they would love to have full control over their work.

04:34 → 04:37

So these are the different factors you need to consider

04:37 → 04:39

before making a decision.

04:39 → 04:40

Summing up.

04:40 → 04:43

Your choice will depend on whether your application is

04:43 → 04:47

small and does not require many integrations or whether it's an

04:47 → 04:50

advanced microservice based application.

04:50 → 04:54

There are also risks of downtime related to both approaches,

04:54 → 04:57

so you need to think about which one is easier to avoid

04:57 → 04:59

for your development team.

04:59 → 05:01

So as always, it depends on your needs.

05:01 → 05:05

If you need any expert advice, you know where to find us.