►
From YouTube: A Million Messages a Minute - Tanmai Gopal, Hasura
Description
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. Get Started Here: https://graphql.org/
A Million Messages a Minute - Tanmai Gopal, Hasura
JW Marriott Austin, Room 402/403
Speakers: Tanmai Gopal
GraphQL allows for developers to “subscribe” to changes and has made the idea of building realtime and streaming applications much easier to reason about. In this talk, Tanmai will discuss patterns for a GraphQL API that will allow you to handle different types of realtime and streaming workloads: live-queries, streaming realtime changes and streaming large volumes of data. He will also discuss ways to handle such workloads on the frontend, with a focus on easy developer experience and scalability (backpressure, anyone?!).
A
A
That's
awesome.
That's
amazing!
So
so
happy
to
be
here,
I'm
going
to
talk
to
you
a
little
bit
about
some
of
this
recent
work
that
we've
been
doing
thinking
about
streaming
use
cases
and
using
graphql
subscriptions
how
we're
kind
of
approaching
the
problem.
Quick
demo
of
what
that
looks
like
this
is
super
early,
we'll
be
releasing
this
kind
of
experimentally,
it's
already
out
still
out
as
an
experimental
feature,
something
that
we've
been
just
thinking
about.
I
would
love
to
kind
of
hear
how
you
folks
are
thinking
about
that
problem
after
the
session.
A
A
So
whenever
people
have
data
and
they're
kind
of
thinking
of
how
they're
going
to
expose
that
with
an
api
or
there's
a
data
as
a
service
use
case
and
stuff,
like
that,
that's
kind
of
where
we
think
of
houston,
adding
value
we
use
graphql
as
an
api
to
deliver
that,
and
one
of
the
use
cases
that
we've
been
increasingly
encountering
is
kind
of
the
streaming
kind
of
use
case.
So
that's
what
I'm
going
to
talk
a
little
bit
about
so
just
to
motivate
the
problem
a
little
bit.
A
A
Stock,
ticker
type
things
messages
right,
stuff
like
that,
logs
and
metrics
on
a
page
or
just
blocks
and
matrix
data
that
needs
to
be
consumed
right,
I'll,
carry
out
this
in
a
little
bit,
but
so
that's
kind
of
one
use
case
where
the
data
is
just
fast
moving,
quote
unquote,
real
time
or
streaming
right.
It's
just
that's
the
nature
of
the
data
itself.
A
There
isn't
it's
not
like
all
data
is
necessarily
streaming
data,
but
that
amount
of
streaming
data
is
definitely
going
up
right
teams
wanting
to
share
that
with
other
people
over
an
api
stuff
like
that
or
whether
it
actually
makes
its
way
to
an
application
all
of
those
kind
of
things.
The
second
is,
and
the
second
place
where
people
think
about
streaming
is
when
there's
a
large
volume
of
data.
A
So
that's
a
little
bit
different,
it's
kind
of
more
optimized
for
incrementally
delivering
data,
especially
for
a
use
case
where
you
have
a
page,
that's
rendering-
and
you
do
want
that
first
byte
load
to
happen
quickly.
The
size
of
data
that
you
might
be
consuming
on
that
page
is
still
app
size.
Data
right,
you're,
not
like
looking
at
consuming
like
a
gig
of
data
and
using
an
ad
stream
directive
on
it
right.
So
I'm
talking
more
about
like
those
force
to
use
cases
and
not
really
therapies.
A
So
when
we
think
about
this,
when
we
think
about
this
kind
of
streaming,
there's
two
problems
so
on
the
consumption
side,
there's
two
problem
areas
right
from
the
consumption
side
and
people
who
want
to
consume
this
api.
They
want
http,
they
want
a
nice
stateless
protocol.
Http
has
security
around
it.
There's
lots
of
client-side
tooling,
so
that's
great.
A
They
need
an
ability
to
kind
of
manage
back
pressure
without
that
talking
about
streaming
is,
is
not
worth
it
for
substantially
large
cases
and,
of
course,
the
ability
to
recover
from
disconnects
and
not
miss
data
and
all
of
the
typical
kind
of
problems
that
you'd
want
as
on
the
client
side
right
and
so,
and
then
there's
kind
of
this
other
part
which
is
not
on
the
consumption
side.
But
when
you
think
about
serving
that
stream,
this
challenge
is
on
serving
that
stream.
A
Right,
which
is
all
of
you,
want
to
make
sure
that
your
service
can
provide
over
http
can
do
back.
Pressure
can
recover
from
disconnects,
can
be
stateless,
can
scale
out
horizontally
and
stuff
like
that,
but
what
you
also
want
to
ensure
as
a
service
that
is
providing
this?
Is
you
want
to
ensure
kind
of
authorization
on
what
bits
of
the
stream
are
being
sent
out
to
whom
increasingly
people
want
enrichment?
A
So
there's
an
example
of
what
I
mean
by
enrichment
there,
which
is,
for
example,
let's
say
streaming
messages
that
have
id
data
and
user
id.
You
want
that
to
be
enriched
with
user,
not
just
user
id
right
and
the
user
has
username
and
email
right
and
then,
of
course,
from
a
server.
That's
serving
this
stream,
not
the
persistence
layer
but
the
service
layer.
You
want
to
make
sure
that
that
can
also
scale,
preferably
can
scale
in
a
easy
container
scale
out
kind
of
way
right.
A
So
those
are
kind
of
some
of
the
challenges
there
now
talk
a
little
bit
about
kind
of
how
we've
been
thinking
about
approaching
this
at
hasura
right.
So
the
first
piece
when
you
think
about
graphql,
there
are
parts
of
graphql
that
make
this
really
nice
right.
One
graphql
is
a
nice
fit
because
http
and
json
subscriptions
is
a
mechanism
there's
several
ways
that
we
can
slice
this,
but
we
chose
to
use
subscriptions.
A
We
use
subscriptions
for
two
reasons:
one
websockets
and
the
fact
that
the
websocket
protocol
is
customizable
to
a
degree
right,
for
example,
if
you
want
to
handle
things
like
back
pressure
or
you
want
to
send
custom
directives
that
are
a
little
kind
of
at
the
protocol
level,
but
not
necessarily
at
the
graphql
level.
There
are
opportunities
there
to
kind
of
bake
that
in
between
this
graphql
server
and
the
graphql
client
right,
so
subscriptions
allow
for
a
little
bit
of
that.
A
The
second
and
the
way
that
we
think
about
this
right
is
that
we
want
to
reduce
the
streaming
problem
to
a
smaller
set
of
primitives
right,
and
the
key
part
of
reducing
this
to
primitive
is
to
say
that
we
want
to
be
able
to
solve
some
of
the.
We
want
to
be
able
to
solve
the
function,
problems
that
we
talked
about,
but
also
address
some
of
those
non-functional
issues
that
we
brought
up
right.
The
way.
A
Think
of
this
abstraction
is
that
producers
can
focus
on
just
producing
that
stream
data
and
consumers
can
focus
on
just
consuming
the
data
and
the
stuff
that
I
talked
about
in
the
middle.
The
problems
with
consumption,
the
problem
with
serving
that
that
piece
is
automated,
so
we
don't
want
to
interfere
with
the
way
the
stream
is
modeled.
A
But
we
do
want
to
automate
the
thing
that
does
the
streaming
and
how
that
streaming
happens
right.
So
that's
the
that's
the
point
at
which
we
want
to
take
care
of
the
problem
and
I'll
show
you
kind
of
what
and
how
we
thought
about
that
right.
So
now.
The
way
hustler
works
is
that
there
is
essentially
a
metadata
engine
right
and-
and
this
metadata
engine
captures
three
key
things
right.
It
captures
there's
a
modeling
layer,
so
the
model
layer
says
hey
here:
are
these
underlying
models
that
you
have?
A
How
do
you
want
to
map
them
into
the
models
that
you
want
to
expose
over
the
api
right?
The
second
is
the
authorization
layer
which
is
that
each
model
has
granular
authorization
rules
that
can
specify
who
gets
to
access
what
data
inside
that
model,
and
the
third
thing
is
that
multiple
models
can
have
relationships,
and
then
these
relationships
are
composed
into
an
api
right.
So
that's
kind
of
the
underlying
building
block
that
has
I'll
go
over
a
little
bit
of
that
talk
about
kind
of
where
this
point
of
attack
is
right.
A
A
I
don't
know
why
I
chose
to
use
this
example,
but
I
mean:
what's
done
is
done
so
I
have
this.
I
have.
I
have
a
model
called
color
which
I'm
using
to
model.
I
could
have
added
a
better
model
here,
so
I'm
using
this
to
model
a
channel
name.
So
the
color
that
you
see
is
the
name
of
a
channel,
and
the
message
that
you
see
is
the
actual
message
that
goes
inside
this
right.
So
it's
like
a
messages
model.
A
Each
messages
model
actually
has
a
color
name,
which
is
the
channel
name
and
the
message
name
right
so
at
the
hustler
layer-
and
this
is
not
with
subscriptions
or
thinking
about
streaming
yet
right.
The
way
that
we
think
about
it
is
the
first
piece
is
to
get
this
model
right,
and
I've
already
done.
This
work
is
to
specify
the
metadata
that
allows
us
to
take
this
underlying
model
and
bring
it
to
the
graphql
layer
right.
So
I've
already
done
that,
and
because
of
doing
that,
I
get
my
usual.
A
You
know
whatever
colors
go
and
get
a
thing
right
and
let's
just
send
this
to
them
right.
This
is
just
the
usual,
the
first
aspect
of
just
modeling
that
does
that
right.
The
second
piece
of
this
is
and
again
in
in
a
part
of
the
metadata.
I
just
have
the
ui.
The
underlying
metadata
json
is
the
permissions
layer
that
specifies
who
gets
to
access
what
data
right
now
this
this
bit
is
important
because
we
want
this
to
compose.
A
But
this
rule
says
that
if
a
user
is
trying
to
access
a
particular
message,
they
can
only
read
stuff
from
their
channel,
so
the
color
and
their
channel
name
should
be
mapped
together
and
they
can
only
read
stuff
that
is
in
their
channel
and
I
similarly
have
a
rule
for
a
mutation
as
well.
So
when
I
apply
this
authorization
rule-
and
I
turn
that
on.
A
A
I'm
only
going
to
get
greens
here
right.
The
reason
why
I'm
talking
about
this
is
because
the
way
this
works
underneath
it
is
that
this
predicate
is
getting
pushed
down
into
the
underlying
data.
Query
right,
so
the
technique
that
we
use
for
authorization
is
a
predicate
push
down
now.
Predicate
push
down
is
a
really
nice
technique
in
all
of
use
cases
where
it
works
right.
The
idea
is
that
each
model
that
has
this
authorization
rule
that
authorization
rule
is
converted
into
predicate.
A
That
predicate
is
combined
into
the
underlying
data
query
and
then
the
underlying
data
query
that
goes
out
actually
has
that
weight
loss.
This
is
kind
of
exactly
what
you
would
have
done
if
you
would
have
written
this
query
yourself
right.
So
these
are
predicates.
All
of
these
authorization
rules
are
predicates
that
are
being
pushed
down
right.
So
we
have
this
modeling
building
block.
Then
we
added
this
kind
of
predicate
push
down,
building
block
right.
A
If
you're
building
your
own
system,
you
can
visualize
how
this
maps
to
a
system
that
you're
building
as
well
right
same
same
concepts.
The
idea,
though,
is
that
we
want
the
same
predicate
push
down
capability
when
we
think
of
streaming
as
well
right.
We
want
this
same
building
block
to
kind
of
compose
when
we
think
about
that
too
right,
so
that's
kind
of
one
building
block
or
one
composable
block.
The
second
composable
block
is
relationships
which
then
comes
into,
which
which
then
becomes
important
when
you
think
about
enrichment
right.
A
So
what
I've
done
here
for
enrichment
or
for
showing
an
example
here
is
I've
created
a
relationship
between
the
color
model,
with
the
name
of
the
color
and
some
extra
information
about
this
color
right?
So,
as
a
part
of
my
metadata,
I've
created
a
relationship
because
of
creating
this
relationship.
I
can
now
do
things
like
this
right,
I
can
say
hey.
A
I
want
some
more
info
and
this
info
is
now
coming
in
from
the
other
model
right,
so
that
extra
piece
gets
added
because
of
the
relationship
that
I
created
right
so
again,
the
same
building
block
that
we
were
using
for
creating
relationships.
Whatever
mechanism
that
is,
in
our
case,
it's
a
metadata.
It
happens
at
the
metadata
layer.
We
want
that
same
composition
to
happen
when
we
think
about
bringing
and
and
having
this
when
you
think
about
streaming
right.
So,
ideally,
I
want
to
be
able
to
stream
messages.
A
So
that's
that
was
kind
of
that's
one,
important
piece
here
when
you
think
about
okay,
so
so
that's
kind
of
so
that's
kind
of
on
the
on
the
building
blocks
that
we
want
to
have
now,
if
you
flip
over
to
the
stream
consumption
side,
and
we
think
about
how
streams
are
consumed
in
general,
you'll
see
that
all
kind
of
streaming,
customers
and
clients
choose
streams,
choose
to
use
streams
in
in
a
variation
of
this
essential
concept.
That
applies
the
same
everywhere
right.
The
first
is
the
consumer
opens
a
connection.
A
The
consumer
quotes
an
offset
or
a
cursor
value
right.
So
if
you're
familiar
with
something
like
a
kafka,
client
or
whatever,
you
quote
a
value
of
your
last
known
offset
or
your
last
position
in
the
cursor,
so
the
state
is
maintained
by
the
client
in
in
kind
of
that
streaming
case,
the
streaming
backend,
whatever
the
service
that's
sending
out
the
stream,
is
it
sends
this
data
which
is
ordered
from
that
offset
right?
A
A
Wherever
they
do
it,
they
keep
storing
their
offset
at
checkpoints
to
ensure
that
data
is
not
lost
from
the
stream
right
and
you'll
see
the
same
id
and
the
variation
of
the
same
idea,
no
matter
what
you
stream
right,
so
whether
you're
doing
like
a
backend
thing
from
like
a
kafka
or
kafka
system,
or
even
if
you
think
about
discord,
had
a
really
nice.
The
discord
engineering
folks
had
a
really
nice
post.
A
It
was
a
little
dated,
I
think,
it's
a
few
years
now,
of
how
they
model
their,
how
their
model
messages
and
the
messages
model
on
cassandra
and
how
that's
kind
of
optimized
for
essentially
being
able
to
quote
letting
a
discord.
Client
quote
a
particular
offset
and
then
read
data
from
that
from
that
message:
model
right,
which
is
underneath
it
is
stored
in
cassandra.
A
That's
so,
if
you
think
about
what
a
stream
model
is,
a
stream
model
is
essentially
a
data
model
that
specifies
that
has
this
ability
to
specify
some
kind
of
sequential
ordering
and
then
say
that
the
method
of
consuming
that
incremental
range
is
extremely
efficient
and
works.
Well
right
and
that's
kind
of
what
this
problem
reduces
to
and
that's
how
we
think
about
the
underlying
primitive
right.
A
Non-Functional
problems
that
we
talked
about
a
few
slides
ago,
right,
okay,
so
the
way
that
we
approached
this
design
was
that
the
metadata
that
describes
the
streamable
model,
the
relationships
and
the
authorization
rules
which
I
just
showed
you
that's
fine
and
when
you
think
about
the
graphql
api,
the
first
is
that
we'll
add
a
streaming
field
to
the
graphql
schema.
This
streaming
field
will
support
two
things
right.
It
will
support
a
cursor.
The
cursor
is
something
that
will
start
the
stream
right
and
the
second
is.
A
It
will
support
a
batch
size
that
the
client
can
use
to
receive
the
results
right,
so
that
gets
added
and
that's
kind
of
the
way
it
shows
up
on
the
graphql
api
underneath
it.
What
we
do
is
we
back
that
with
this
ability
to
read
incremental
ranges
as
efficiently
as
possible
right
we
use
subscriptions
and
websockets.
I
already
talked
about
that
a
little
bit,
but
two
important
things
here
are
one
that
we
want
to
allow
for
connection
interrupts
whether
desired
or
undesired.
A
So
this
part
is
the
part
that
is
still
has
to
be
kind
of
worked
out
and
thought
about
a
little
bit
right.
So
connection
interrupts
can
always
happen
which
are
undesired,
so
connection
goes
off,
3g
4g
is
off
or
your
network
is
off
or
whatever,
but
sometimes-
and
this
is
the
part
where
the
back
pressure
piece
becomes
interesting-
is
that
and
currently
this
is
the
way
that
we
think
about
it.
The
client
has
to
manage
back
pressure
at
the
application
layer.
A
I
giggle
a
little
bit
because
that's
not
necessarily
great,
but
the
client
has
to
handle
backrest
of
the
application
layer
and
say
hey.
I
have
a
data
structure
and
I'm
ingesting
this
stream,
and
I
can't
ingest
anymore
right
and
when
the
client
can't
adjust
anymore
today,
and
this
has
to
go
through
a
round
of
designing,
but
today
the
client
can
just
disconnect
and
say
I'm
done.
I
cannot
continue
consuming
the
stream
anymore,
I'm
going
to
stop
here.
This
is
my
offset.
A
I
remember
this
offset,
but
I
am
done
right
and
this
is
the
way
that
back
pressure
kind
of
gets
communicated
to
the
upstream
service.
That's
serving
this
that
stream
right,
but
with
subscriptions
and
web
sockets
and
the
way
that
we're
delivering
it.
You
want
to
make
sure
that
it's
stateless
and
horizontally
scalable
as
well.
The
way
that
this
is
important,
because
when
we
think
about
web
sockets
or
streaming
kind
of
use
cases,
you
want
to
make
sure
that
the
nodes
that
are
serving
the
stream
they
are
swappable
right.
A
Otherwise,
you
have
to
get
into
things
like
trying
to
have
a
connection.
That's
persistent
all
the
way
from
the
client
to
the
load
balancer
to
the
actual
container,
that's
serving
it
out
to
the
actual
data
system.
That's
serving
out
that
that's
serving
out
that
stream
right.
So
you
want
to
make
sure
that
the
graphql
layer
is
stateless,
so
that
you
can
have
three
container
instances
that
are
running
or
10
or
100
or
whatever,
and
it
shouldn't
matter
right
so
that
contract
that
that
contact
has
to
be
stateless
right.
A
A
One
is
that
we
want
to
let
the
client
side,
client,
choose
kind
of
their
batch
size
and
just
put
in
five
here
and
their
cursor
value
right,
and
this
is
the
state
that
the
client
has
to
maintain.
So
we'll
start
off
with
an
id
of
let's
say:
I'm
going
to
run
a
load
script
so
that
I'm
ingesting
about
100
000
events
per
second.
A
So
that's
the
and
you
can
see
that
kind
of
streaming
in
with
that
appropriate
batch
size.
You
can
disconnect
and
connect
at
any
point
of
time,
and
all
that
you
have
to
ensure
is
that
you
continue
quoting
that
last
value
of
the
cursor
right
so
very
similar
to
kind
of
cursor
based
ideas
or
pagination
ideas
that
you
would
have
seen
otherwise
very
similar
api
with
the
ideas
that
you
can
keep
streaming
right.
A
A
A
A
All
right,
so
I
have
two
channels
here:
that's
the
authorization
kind
of
make
sure
that
you
have
access
to
only
one
of
the
channels,
so
I
randomly
choose
a
channel,
so
one
of
you
will
be
randomly
on
red.
One
of
you
will
randomly
be
on
and
what
you
can
do
is
whenever
you
enter
a
thing
here,
it's
gonna
show
up
on
either
of
those
two
right.
Whatever
message
you
put
in
so
yeah,
hello
from
you,
yeah
cool-
so
don't
please
do
not
use
this
for
nsfw
stuff.
A
Yes,
all
is
a
little
bit
scary,
so
fairly
low
latency,
while
a
huge
amount
of
ingest
is
happening,
and
this
is
just
running
on
a
single
container,
but
you
can
scale
this
out
to
you
know
that
the
scaling
is
more
kind
of
limited
by
the
range
and
effectiveness
of
the
range
stream
query
that
you
can
do
rather
than
anything
else,
good
good
idea
to
start
investing
in
bitcoin
when
it's
at
a
slump,
so
solid,
solid
ideas.
So
that's
that's!
A
I
think
on
the
yeah
now,
if
you
think
about,
if
you
think
about
streaming
right,
there
are
a
few
use
cases
that
you'll
have,
and
the
question
is:
how
do
those
use
cases
map
to
this
primitive
right?
So,
for
example,
three
that
I've
encountered
fairly
often
are
you
want
to
capture
and
stream
changes
that
are
happening
to
a
data
in
some
underlying
data
system
right?
What
is
the
method
of
capture?
What
is
the
measure
of
streaming?
How
does
that
map
to
this
model?
A
You
might
have
a
use
case
where
you're
thinking
about
streaming
data
from
data
is
being
emitted
from
another
service.
Another
team:
how
do
we?
How
do
we
take
care
of
that
or
the
third,
which
is
on
the
application
side?
How
do
you
model
an
application
where
you
have
changes?
You
have
snapshot
plus
changes,
something
that
is
similar
to
say,
google,
docs
kind
of
mechanism
we
use
crdts.
A
How
does
all
of
that
get
modeled,
so
the
primitive
that
we
have
in
place,
which
is
that
hasn't
an
opinion
or
in
this
case,
when
we
think
about
streaming?
We
don't
really
think
about
the
idea
of
we
just
think
about
the
idea
of
a
streamable
model.
The
streamable
model
has
to
either
be
something.
That's
like
a
val
of
changes
or
the
streamable
model
has
to
be
something
that's
saying.
Kafka
or
the
streamable
model
has
to
be
a
model
of
crdts,
but
that
streamable
model
has
to
be
that
domain.
A
A
Like
basically
being
able
to
stream
that
out
over
s3
and
then
get
that
that
makes
sense,
one
of
the
things
that
we're
working
on
is
being
able
to
do
that
with
athena
on
top
of
s3
on
on
aws,
so
that
you
can
layer
the
model
that
you
want
to
have
for
the
log
on,
and
then
you
can
start
streaming
that.
But
that's,
but
that's
that's
a
really
good.
That's
really
a
good
use
case
for
streaming.
You
probably
also
have
authorization
rules
where
you
want
to
think
about
who
gets
to
access.
A
A
Got
it
okay.
Is
that
more
of
a
is
that
more
of
a
live
query,
or
is
that
more
of
a
stream?
Do
you
want
to
see
all
of
the
point
in
time
changes
to
the
account
balance,
or
do
you
want
to
see
the
latest
account
balance
yeah?
So
so
that's
that's
interesting.
I
didn't
I
didn't
talk
about
that,
but,
for
example,
here
what
you
can-
and
this
is
the
way
that
when
we
think
about
subscriptions
right
what
we
and
what
we
did.
B
A
Is
when
we
thought
about
subscriptions,
we
were
like
there's
so
much
when
we
think
about
a
stream
there's
so
much
state
to
maintain
on
a
client.
If
we
think
about
it
from
the
live
query
point
of
view,
we
can
get
rid
of
state
that
needs
to
be
stored
in
the
client.
It's
just
that
life
queries.
Don't
work
well
for
cases
where
you
want
to
stream
data
like
you
can't
use
a
live
query
to
stream
logs
right,
because
the
result
set
will
keep
increasing
right.
So,
for
example,.
A
A
Right,
I'm
gonna
get
that
update
here
right,
so
this
is
kind
of
more
the
live
kind
of
use
case
right
the
this
this
this.
This
is
a
slightly
different
mechanism
of
thinking
about
kind
of
real
time
where
we're
looking
at
the
you're
only
interested
in
the
latest
snapshot
of
that
value,
you're,
not
interested
in
any
of
the
changes
that
have
happened
in
the
meantime.
A
A
A
A
Because
you
could
think
of
it
as
like:
a
live
query
model
as
well,
where
it's
like
a
result
set.
That's
continuously
updated
right.
It's
like
a
matrix
of
data
that
you
have
and
that
matrix
is
just
continuously
updated.
You
don't
care
about
like
changes
that
have
happened
in
the
middle.
You
just
always
get
the
latest
state
right.
It's
like
a
tic-tac-toe
kind
of
situation
right
where
you're
just
getting
the
latest
tic-tac-toe
board.
So
sometimes
you
can
model.
A
That's
one
style
of
modeling.
The
other
style
of
modeling
is
more
the
incremental
changes
that
you
want
to
keep
streaming
to
people.
I
think
one
of
the
most
interesting
things
there
to
figure
out
and
that's
something
that
we
want
to
think
about
best
practices
and
modeling.
This
as
well
is
there's
a
snapshot
plus
stream.
A
So
what
you
want
to
do
when
you
do
the
first
load
of
the
game
state?
Is
you
want
to
get
a
snapshot
of
the
current
game
state
which
might
be
a
large
piece
of
data?
Like
might
be
a
few
mb
right?
But
after
that,
there's
a
stream
and
those
changes
then
might
be
like
bite.
Size
they're,
like
20,
kilobytes,
50,
kilobytes,
100
kilobytes
of
changes
that
are
happening
after
the
snapshot
right.
A
What
you
don't
want
to
do
is
start
ingesting
the
stream
from
the
dawn
of
time,
to
have
to
replay
that
log
right
off
that
entire
game
state
to
get
that
right.
So
I
think,
like
that's
the
part
that
gets
very
interesting
to
model
when
you
think
about
like
how
do
I
model
a
snapshot
and
from
that
point
I
want
a
stream
and
then
you
want
that
to
scale
out
to
whatever
clients
you
want
right.
So
I
think
that's
the
that's
going
to
be
an
interesting.
A
It's
an
interesting
modeling
exercise
for
us.
It'll
likely
boil
down
to
saying
that
it's
a
combination
of
using
a
live
query
and
a
stream
so
use
a
live
query
to
fetch
the
latest
snapshot,
and
then
you
get
a
cursor
value
and
then,
from
that
cursor
value
onwards.
You
start
your
stream
and
then
you
start
replaying
that
to
ingest
that
on
the
game.
Those
are
really
solid
examples.
A
A
The
idea
is
that,
instead
of
instead
of
the
burden
of
the
work
happening
here,
we've
taken
a
deliberate
opinion
to
shift
the
burden
of
the
work
either
here
on
the
stream
production
side
and
that's
kind
of
where
the
stream
models
get
interesting,
but
with
the
core
set
of
primitives.
That
will
work
for
no
matter
what
streaming
use
case
you
have
on
the
client
side
right.
A
So
so
that's
that's
the
rough.
That's
the
idea
or
that's
the
end
vision
of
where
you
want
to
get
to
this.
All
right
so
would
love
to
get
your
feedback.
You
can
check
check
this
out
on
github
download
the
docker
image
point
it
to
open
point
it
to
a
database
that
you
have
start
streaming
or
do
it
via
cloud
still
very
early
design
stages
would
love
to
kind
of
hear
how
the
kind
of
different
streaming
use
cases
you're.
A
Thinking
about
the
underlying
design
itself,
we're
going
to
be
publishing
performance
benchmarks
and
and
the
way
that
this
is
architected,
so
that,
if
you're
thinking
about
building
a
streaming
use
case
yourself
and
how
you
can
how
how
you
can
approach
building
that
internally
for
for
whatever
system,
you're
building
to
handle
kind
of
a
graphql
stream
use
case,
but
would
love
to
hear
that
and
feel
free
to
reach
out
on
github
discord
or
to
me
on
twitter.
But
that
is
my
time.