the next challenge for api real-time on the edge management · real-time on the edge the next...

Real-Time on the Edge The next challenge for API

Management

© 2019 Push Technology Ltd

Peter Hughes

Head of Cloud Development

Push Technology

@peterhughesdev

phughes@pushtechnology.com

© 2019 Push Technology Ltd

“30% of all data consumed will be Real-Time by 2025” Source: IDC

• Growing demand for real-time experiences

• Event-streaming being mixed with REST

• Data sources located on-prem, in cloud, or

remote • Architectural complexity & time to develop

• Scaling for volume of data / connections

Real-Time over the Internet

© 2019 Push Technology Ltd

“The right data at the right time. When

data changes, users are informed instantly”

© 2019 Push Technology Ltd

We live in an event-driven world

Apps, devices, users:

everything is generating events

© 2019 Push Technology Ltd

Could be a firehose

(thousands of events a second to everyone)

Or instantaneous updates, when it matters

© 2019 Push Technology Ltd

Rapidly changing data

(stocks, sporting events, vehicle telemetry, multiplayer

games)

User-specific data

(order status, driver’s location, collaborative editing)

© 2019 Push Technology Ltd

More data

More events

More immediacy

© 2019 Push Technology Ltd

“Conventional” API Management

Acts as meeting point for data sources and consumers

Consolidates access

Decouples systems

Easy integration

© 2019 Push Technology Ltd

Conventional API Management: Hub

Consumers API Layer

Endpoints

Security

Processing

Analytics

Data Sources

© 2019 Push Technology Ltd

The changing landscape

IoT: inbound data from millions of devices

Stream-oriented backend: Kafka, MQTT, ESB

Multi-channel, responsive applications

© 2019 Push Technology Ltd

Real-Time API Management: Relay

Consumers API Layer

Streams

Security

Monitoring

Analytics

Data Sources

© 2019 Push Technology Ltd

Challenges of the future

Interactive applications

More data over the same network

Scaling for data volume & connections

© 2019 Push Technology Ltd

Challenges of the Edge

Connectivity can be variable

Bandwidth can be constrained

Connections from anywhere, on anything

© 2019 Push Technology Ltd

What we have today

Communication: REST

Transport: Polling

© 2019 Push Technology Ltd

What we have today

Communication: REST

Transport: Polling

© 2019 Push Technology Ltd

Lack of immediacy

Consumers API Layer

/foo

Data Sources

Foo = xyz

Get “foo”

Response: xyz

T1

T2

© 2019 Push Technology Ltd

Volume and overhead

Consumers API Layer

Handle request 1

Handler request 2

Handle request 3

…

© 2019 Push Technology Ltd

“Are we there yet?”

Give me “A” [1, 2, 3, 4]

Give me “A” [1, 2, 3, 4]

Give me “A” [1, 2, 3, 4]

Give me “A” [1, 2, 3, 4]

Give me “A” [1, 2, 3, 4]

Give me “A” [1, 2, 3, 4, 5]

© 2019 Push Technology Ltd

Request-oriented design

Poll too slowly = outdated data

Poll too quickly = excessive request volume

Server must wait until consumers request data

Consumers need visibility of changes

© 2019 Push Technology Ltd

Stream Oriented

Push instead of poll when data changes

Real-time data is (almost always) event-based

Logical and temporal relationships between

changes

© 2019 Push Technology Ltd

Streaming for the web

WebSockets, WebRTC, SSE etc

More efficient than HTTP Requests

Supported (mostly) everywhere, web native

© 2019 Push Technology Ltd

Just add WebSockets?

Communication: REST

Transport: WebSockets

© 2019 Push Technology Ltd

Just add WebSockets?

Communication: REST

Transport: WebSockets

© 2019 Push Technology Ltd

Just add WebSockets?

Communication: REST

Transport: WebSockets

© 2019 Push Technology Ltd

Practicing RESTfulness

Resource oriented

HTTP Based (usually)

Stateless operations

© 2019 Push Technology Ltd

Requests

Headers (URI, Authentication, Format)

Payload

Streams

Headers (URI, Authentication, Format)

Headers (URI, Authentication, Format)

Payload

Payload

Payload

© 2019 Push Technology Ltd

Scaling with stateless requests

Instance 1

Load Balancer Connections API Servers

Instance 1

Instance 1

Instance 1

© 2019 Push Technology Ltd

Scaling with streams

Instance 1

Load Balancer Connections API Servers

Instance 1

Instance 1

Instance 1

© 2019 Push Technology Ltd

Implications of streaming

Long-lived connections

Maintain state per connection

Scaling / Resiliency has new trade-offs

© 2019 Push Technology Ltd

Oh, by the way…

WebSockets / SSE / etc are just “dumb”

pipes

Developers need higher-level

communication

© 2019 Push Technology Ltd

Just add Pub/Sub?

Communication: Pub/Sub

Transport: WebSockets

© 2019 Push Technology Ltd

REST vs Pub/Sub

Endpoints

Request endpoint

Receive response

Topics

Subscribe to topic

Receive updates

© 2019 Push Technology Ltd

Pub/Sub Streaming

Consumers API Layer Data Sources

Topic A

Topic B

Topic C

…

Subscribe to “A”

Updates for “A”

© 2019 Push Technology Ltd

REST vs Pub/Sub

Security

Publishing

Caching

Two-way interactions

?

?

?

?

© 2019 Push Technology Ltd

Pub/Sub is just the start

Real-world interactions are more complex

than just sending messages

Developers need even higher-level

communication

© 2019 Push Technology Ltd

Just add Pub/Sub?

Communication: Pub/Sub+

Transport: WebSockets

© 2019 Push Technology Ltd

Requirement: Securing streams

What happens when your token expires?

Are errors sent as messages or out-of-band?

Security is both topic and connection based

How do we use existing solutions for real-

time?

© 2019 Push Technology Ltd

Requirement: Publishing streams

How do you discover available streams?

Does versioning happen at the server, topic or event level?

Topic paths, event types and message formats are necessary

information

What if we had a “Swagger for Streams”?

(Check out AsyncAPI)

© 2019 Push Technology Ltd

Requirement: Querying resources

APIs need to be responsive

Resources aren’t singular entities

Applications need to parameterize

selections

What if we had GraphQL for topics?

© 2019 Push Technology Ltd

Example: Requests over Streaming

Some interactions need requests

(e.g. “Place my order” )

Using multiple communication channels is error-prone

Developers don’t / can’t convert everything to streams

What if we could do req/res over a stream?

© 2019 Push Technology Ltd

Example: Smarter delivery

Not all consumers can receive as quickly as

updates are produced

And sometimes you only want the latest update

(e.g. “current price”)

What if our stream could filter queued

events?

© 2019 Push Technology Ltd

Example: Event History for Social Apps

Streaming makes sense for active chats

But, chats usually have a long history

Important for both new and returning

connections

What if our stream remembered past

events?

© 2019 Push Technology Ltd

Example: What’s the difference?

Consumers care about what’s changed

Messages usually contain entire JSON objects

Scaling costs come from infrastructure + bandwidth

What if our stream only sent diffs for topic

updates?

© 2019 Push Technology Ltd

More data

More problems

© 2019 Push Technology Ltd

More data

More problems opportunities

© 2019 Push Technology Ltd

Paradigm shifts

State is necessary

Current approaches are insufficient

Several wheels may need to be redesigned

© 2019 Push Technology Ltd

What the future looks like

Industry standards for real-time APIs

New and exciting applications

Real-Time data, everywhere

© 2019 Push Technology Ltd

Stream.emit(‘end’)

Let’s chat: phughes@pushtechnology.com