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

[email protected]


“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


“The right data at the right time. When

data changes, users are informed instantly”


We live in an event-driven world

Apps, devices, users:

everything is generating events


Could be a firehose

(thousands of events a second to everyone)

Or instantaneous updates, when it matters


Rapidly changing data

(stocks, sporting events, vehicle telemetry, multiplayer

games)

User-specific data

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


More data

More events

More immediacy


“Conventional” API Management

Acts as meeting point for data sources and consumers

Consolidates access

Decouples systems

Easy integration


Conventional API Management: Hub

Consumers API Layer

Endpoints

Security

Processing

Analytics

Data Sources


The changing landscape

IoT: inbound data from millions of devices

Stream-oriented backend: Kafka, MQTT, ESB

Multi-channel, responsive applications


Real-Time API Management: Relay

Consumers API Layer

Streams

Security

Monitoring

Analytics

Data Sources


Challenges of the future

Interactive applications

More data over the same network

Scaling for data volume & connections


Challenges of the Edge

Connectivity can be variable

Bandwidth can be constrained

Connections from anywhere, on anything


What we have today

Communication: REST

Transport: Polling


Lack of immediacy

Consumers API Layer

/foo

Data Sources

Foo = xyz

Get “foo”

Response: xyz

T1

T2


Volume and overhead

Consumers API Layer

Handle request 1

Handler request 2

Handle request 3

…


“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]


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


Stream Oriented

Push instead of poll when data changes

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

Logical and temporal relationships between

changes


Streaming for the web

WebSockets, WebRTC, SSE etc

More efficient than HTTP Requests

Supported (mostly) everywhere, web native


Just add WebSockets?

Communication: REST

Transport: WebSockets


Practicing RESTfulness

Resource oriented

HTTP Based (usually)

Stateless operations


Requests

Headers (URI, Authentication, Format)

Payload

Streams



Payload

Payload

Payload


Scaling with stateless requests

Instance 1

Load Balancer Connections API Servers

Instance 1

Instance 1

Instance 1


Scaling with streams

Instance 1

Load Balancer Connections API Servers

Instance 1

Instance 1

Instance 1


Implications of streaming

Long-lived connections

Maintain state per connection

Scaling / Resiliency has new trade-offs


Oh, by the way…

WebSockets / SSE / etc are just “dumb”

pipes

Developers need higher-level

communication


Just add Pub/Sub?

Communication: Pub/Sub



REST vs Pub/Sub

Endpoints

Request endpoint

Receive response

Topics

Subscribe to topic

Receive updates


Pub/Sub Streaming

Consumers API Layer Data Sources

Topic A

Topic B

Topic C

…

Subscribe to “A”

Updates for “A”


REST vs Pub/Sub

Security

Publishing

Caching

Two-way interactions

?

?

?

?


Pub/Sub is just the start

Real-world interactions are more complex

than just sending messages

Developers need even higher-level

communication


Just add Pub/Sub?

Communication: Pub/Sub+



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?


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)


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?


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?


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?


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?


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?

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

Documents