Building APIs for Scalable Client-Side Applications · 2019-10-28 · © 2019 TWILIO INC. ALL RIGHTS RESERVED. Building APIs for Scalable Client-Side Applications Steve Kinney Senior

© 2019 TWILIO INC. ALL RIGHTS RESERVED. © 2019 TWILIO INC. ALL RIGHTS RESERVED.

Building APIs for Scalable Client-Side Applications Steve Kinney Senior Principal Engineer & Frontend Architect

© 2019 TWILIO INC. ALL RIGHTS RESERVED.

An Overly Brief History of

Applications on the Web

From thick-client desktop applications to server-rendered web applications.

From server-rendered web applications to thick-client JavaScript applications.

The rise of mobile, tablets, etc.


Microservices considered harmful.*


That’s not really fair.

Microservices are great for a number of reasons.

You can reuse services across multiple business needs.

The API of each service creates a well-defined surface area.

¸You can rewrite a single piece of your architecture, if needed.

Each component of your architecture can be deployed separately.


Microservices considered harmful—for client-side applications, sometimes.


The problem with a lot of technical choices is that reality has a nasty habit

of changing underneath our feet.


Microservices do create some

problems for client applications.

(Don’t worry. We’ll talk about some solutions.)

We've accidentally shifted a lot of complexity over to the frontend applications.

The data we need for a particular view might be split across multiple microservices.

Caching computed data is no longer an option.

The client-side application still has to feel like a cohesive experience—regardless of how many services back it.








The Cost of JavaScript


https://samnewman.io/patterns/architectural/bff



Potential Problems

Too much data

Not enough data



One Gateway to Rule Them All?

What are some problems with this current approach?

Different platforms are going to have different needs.

You separate the team who needs an endpoint from the team who can create it.

Breaking changes.

Deployments aren’t free.

Prioritizing the requests from multiple teams can be tricky on an organizational level.

It can get bloated.


Maybe microservices are good after all.


That’s not really fair.

Microservices are great for a number of reasons.

You can reuse services across multiple business needs.

The API of each service creates a well-defined surface area.

¸You can rewrite a single piece of your architecture, if needed.




What about duplicated logic?

(Because that’s not already happening in your organization, right?)

You can break things out into shared libraries.

You can abstract out additional services.

Does that logic belong in your middle tier at all?




Guidance

As much as you need and as little as you can get away with.

Use technologies that support non-blocking or concurrent technologies.


{

"posts": [

{

"id": "1",

"title": "A Very First Post",

"content": {

"href": "/posts/1/content"

}

},

{

"id": "2",

"title": "An Apology for the First Post",

"content": {

"href": "/posts/2/content"

}

}

]

}


{

"posts": [

{

"id": "1",

"title": "A Very First Post",

"content": "We're excited to announce…"

},

{

"id": "2",

"title": "An Apology for the First Post",

"content": "It has come to our attention…"

}

]

}



Benefits of an Adapter Layer

Changing API contracts.

Breaking out additional services.

Stubbing out data for new features.


Graduate-level Advantages

Server-side rendering.

Caching for shared data.



206 Partial Content

503 Service Unavailable

What if things go wrong?




query {

posts {

title

author

summary

}

}


query {

posts {

title

author

}

}


What are the trade-offs that you need to consider?


In conclusion…

THANK YOU

Documents

Building APIs for Scalable Client-Side Applications · 2019-10-28 · © 2019 TWILIO INC. ALL RIGHTS RESERVED. Building APIs for Scalable Client-Side Applications Steve Kinney Senior