D E M A N D D R I V E N A R C H I T E C T U R E K O VA S B O G U - - PowerPoint PPT Presentation

▶
d e m a n d d r i v e n a r c h i t e c t u r e
SMART_READER_LITE
LIVE PREVIEW

D E M A N D D R I V E N A R C H I T E C T U R E K O VA S B O G U - - PowerPoint PPT Presentation

Feb 05, 2023 311 likes •704 views

D E M A N D D R I V E N A R C H I T E C T U R E K O VA S B O G U TA & D A V I D N O L E N , Q C O N N E W Y O R K 2 0 1 5 C L I E N T S More and more clients everyday Internet of Things How to serve N clients with 1

slide-1
SLIDE 1

D E M A N D D R I V E N A R C H I T E C T U R E

K O VA S B O G U TA & D A V I D N O L E N , Q C O N N E W Y O R K 2 0 1 5

slide-2
SLIDE 2

C L I E N T S

  • More and more clients

everyday

  • Internet of Things
  • How to serve N clients with

1 service?

slide-3
SLIDE 3

R E S T S E R V I C E

  • Define logical “resources”
  • Client requests a resource
  • But client actually needs to present joined resources
  • Bloat resource? Multiple requests?
  • Incidental complexity? Mobile client latency?
slide-4
SLIDE 4

S U P P LY D R I V E N A R C H I T E C T U R E

  • “You can have anything you want as long as it looks

exactly like this”

  • Engineering team issues
  • Front end team must request changes
  • N front end teams attacking service team
slide-5
SLIDE 5

Our REST Service

slide-6
SLIDE 6

T H E P R O B L E M

  • Cannot predict what clients (especially future ones) will

actually need

  • Cannot put all clients into lockstep with a specific

version of the API (Synchronization is expensive)

  • Client applications are distributed systems (salad days

are over)

slide-7
SLIDE 7

“This has all happened before”

Author Jun 2, 2015, 6:59 PM database design hierarchical databases make sure clear not recommending storing data as tree

slide-8
SLIDE 8

R D B M S

  • Client specifies exactly what they need
  • Multiple clients not locked into same canned results
  • Batching (latency considerations)
slide-9
SLIDE 9

? ? ?

  • Can an endpoint provide a restrictive yet expressive

query language?

  • Can an endpoint evolve with clients?
  • Can an endpoint serve multiple tiers of demand from a

client?

Author Jun 2, 2015, 9:10 PM known unknowns

  • pen questions

we’re not just going to expose SQL but what are we going to do?

slide-10
SLIDE 10

D E M A N D D R I V E N

slide-11
SLIDE 11

T H E B I G I D E A

  • Represent client demand as data
  • Client describes demand, service fulfills
  • Variation captured in data, on the client
  • Contract between client and service
slide-12
SLIDE 12

P R I N C I P L E S

slide-13
SLIDE 13

Demand

slide-14
SLIDE 14

Composition

Author Jun 2, 2015, 7:17 PM We don’t want to decide what is a resource and what isn’t The payload includes a mixture of thing which are and aren’t resources (We should probably examine and respond to HATEOS)

slide-15
SLIDE 15

Interpretation

slide-16
SLIDE 16

D E M O

slide-17
SLIDE 17

[{:app/contacts [:person/first-name]}]

slide-18
SLIDE 18

[{:app/contacts [:person/first-name]}]

slide-19
SLIDE 19

[{:app/contacts [:person/first-name]}] ROUTER

slide-20
SLIDE 20

[{:app/contacts [:person/first-name]}] ROUTER QUERY

slide-21
SLIDE 21

ROUTER QUERY [{:app/contacts [:person/first-name :person/last-name :person/address]}]

slide-22
SLIDE 22

person address address first-name city zip-code street last-name

slide-23
SLIDE 23

[{:app/contacts [:person/first-name :person/last-name {:person/address [:address/zip-code]}]}]

ROUTER QUERY SUBQUERY

slide-24
SLIDE 24

S U M M A RY

  • Client specifies exactly what it needs
  • Batched
  • Details of demand are easily modified
  • Decoupled from service implementation
slide-25
SLIDE 25

U X I M P L I C AT I O N S

slide-26
SLIDE 26

U S E R I N T E R FA C E S

  • User interfaces are trees
  • Graphical clients that talk to traditional REST

endpoints general involve error prone reshaping code

  • Demand Driven Architecture can dramatically simplify

rich clients

slide-27
SLIDE 27

[:person/first-name {:person/address …}] ContactListView AppView [{:app/contacts …}] [:zip-code] AddressView

slide-28
SLIDE 28

D E M O

slide-29
SLIDE 29

[{:app/contacts [:person/first-name {:person/address [:zip-code]}]}]

slide-30
SLIDE 30

C AV E AT S

  • Doesn’t mean no backend
  • Security
  • Routing
  • Caching
slide-31
SLIDE 31

L E V E L I N G U P

slide-32
SLIDE 32

D AT O M I C

  • Queries work out of the box (pull syntax)
  • Caching (peers)
  • Evolvable schema (not migrations)
  • Query arbitrary points in time (without logs)
  • Client can trivially receive change sets (transaction

report)

slide-33
SLIDE 33

R E L AY / G R A P H Q L

  • FaceBook software layer over React
  • Monolithic application architecture
  • Relay/GraphQL deliver demand driven queries for

React user interfaces

slide-34
SLIDE 34

J S O N G R A P H / FA L C O R

  • NetFlix eliminated 90% of their networking code
  • Can now serve many different kinds of clients
  • Unlike Facebook microservices based design
  • Still, same benefits - phones, tablets, browsers, and

set-top boxes can get exactly what they need

slide-35
SLIDE 35

R E C A P

  • The pace of client innovation is only accelerating
  • Demand driven architecture guides us toward

evolvable systems

  • Can remove incidental complexity from client and

server by meeting on simple data

slide-36
SLIDE 36

R E F E R E N C E S

  • Relay/GraphQL (FaceBook)
  • JSONGraph/Falkor (NetFlix)
  • Datomic
slide-37
SLIDE 37

Q U E S T I O N S ?