►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Design Choices Behind Making gRPC Available on Web Platforms - Wenbo Zhu, Google
In this talk, we will go through the challenges faced by making gRPC available on Web platforms and discuss the design choices we made in order to strike the balance between reachability and complexity of the solution. Since its GA (Oct 2018), grpc-web has been widely adopted by OSS users (https://github.com/grpc/grpc-web), and we have also seen a rapidly growing ecosystem support for gRPC-Web, such as Dart, Angular, Swift, Reactive-Native etc. Web technologies will continue evolving and we will present the road-maps of gRPC-Web and how we plan to deliver a seamless development experience for designing highly-responsive Web applications against gRPC based microservices or APIs.
https://sched.co/ZeoJ
A
So
in
this
talk,
I'm
look
I'm
going
to
go
through
the
design
choices
we
made
for
grpc
web,
so
I
started
with
a
quick
introduction
of
the
jrpgc
web
in.
What's
so
unique
about
web
platforms
and
now
I'll
do
a
deep
dive
on
the
different
design
choices,
we
made
the
process
of
the
design
choices
they
are
really
just
about.
You
know
making
the
trade-offs,
which
you
hope
will
be
right
over
time,
as
you
know,
as
time
proves
I'll
end.
A
A
Currently,
the
rpc
use
http
2
as
the
underlying
transfer
protocol,
the
key
to
grpc
is
really
the
service
definition,
which
is
which
is
using
protocol
buffer.
So
the
service
definition
provides
two
things:
one
is
the
a
strict
contract
between
the
client
and
server.
In
terms
of
you
know,
what
are
the
input
or
the
output?
What
are
the
message?
A
A
The
next
slide,
I
want
to
talk
about
what's
unique
about
the
web
platforms.
If
you
want
to
extend,
you
know
this
kind
of
rpc
model
to
web
clients,
and
now
I'm
going
to
skip
the
detail.
The
details,
which
are
specific
to
the
ipc
web
and
just
started
with
the
fgp
http,
was
actually
designed
as
an
rpc
protocol,
strictly
speaking
as
well.
So
the
things
that
are
really
unique
about
webcams
are
two
things.
A
A
In
most
cases,
the
clients
will
talk
to
proxy
first
there's
a
forward
proxies
which
provide
some
kind
of
firewall
support.
There
could
also
be
a
reverse
proxy
that
provide
load,
balancing,
support
or
actual
protection
for
untrusted.
You
know
external
traffic
and
behind
the
proxies
there
could
also
be
gateways
that
will
do
critical
translation
in
the
case
of
jrpc
web.
We
actually
allow
envoy
the
have
open
source.
You
know
proxy
to
translate
jobs
to
web
to
grpc,
so
this
translation
is
a
completely
transparent,
rpg
service.
A
A
That's
not
really
the
case
for
webcams
because
of
the
nature
of
the
security
models,
the
sandbox
security,
sandbox-based,
3d
models
and
the
web.
You
know
the
javas,
the
javascript
implementation
for
the
obviously
runtime
have
to
rely
on
whatever
apis
to
access
android
networks,
which
is
typically
a
much
restricted
and
typically
just
a
subset
of
features
that
are
allowed
to
access
from
the
browsers
and,
for
example,
you
you
can't
really
control
which
hp
version
the
clients
want
to
want
to
talk
to
the
server
right.
A
A
A
How
do
you
want
to
evolve
and
design
the
overall
solution
because
of
the
constraints
enforced
by
the
web
platform
and
the
winner
died
at
the
very
beginning?
You
know
we
have
to
have
a
different
protocol.
That
is
not
a
grpc
for,
for
the
you
know,
foot
for
product
clients,
for
example,
to
talk
to
at
the
rp
server.
So
there
are
different
choices.
We
can
use
different
protocols,
but
we
end
up
choosing
protocol
design
protocol
dots
that
will
maximize
the
compatibility
between
jrpc
web
and
the
grpc
right.
A
Only
because
those
concepts
are,
you
know
are
very
web
specific
right
that
doesn't
really
cause
any
overlapping
with
grpc
particles,
such
as
the
cost
support,
which
is
a
very
unique
concept
that
only
concerns
the
web
clients.
So
the
takeaway
from
here
is
that
when
it
designs
a
system
like
that,
what
we
try
to
do
is
try
to
minimize
the
overall
complexity
of
the
system,
not
only
on
the
client
side,
but
also
the
whole
current
server
communication
path,
and
I
sometimes
want
to
be
the
solution
to
be
future
proof.
A
There
are
certainly
also
there
are
the
concerns,
but
overall
we
think
that
is
they
know
what
we
don't
want
to
give
you
just
an
rpc
solution
which
by
itself
is
not
really
going
to
solve
all
your
problems,
so
so
overall,
the
key
here
is,
you
know,
try
to
not
invent
anything
that
we
may
regret
that
we
have
to
support
like
for
five
or
15
more
years
right.
So
keep
it
simple.
A
The
next
principle
is,
you
know,
since
we
have
already
made
all
the
tradeoffs,
so
I've
tried
to
minimize
overall
complexity,
then
we
decided
hey.
You
know
we
made
all
these
sort
of
sacrifices
and
we
do
think
that
is
we're
at
a
better
position
at
this
point
to
make
the
solution
work
act
generally
like
everywhere,
and
we
try
to
very
hard
to
make
sure
the
job
see.
Web
accounts
can
work
from
anywhere
platform,
and
this
turns
out
to
be
really
important.
A
We
don't
have
the
story
from
external
clients,
but
internally
we
now
have
over
100
google
applications
so
using
grpc
web
right.
So
we
believe
that
you
know
with
in
this
regard.
We
made
the
right
choice.
We
limited
complexity.
At
the
same
time,
we
are
at
a
much
better
position
to
provide
solution
that
just
can
work
from
everywhere.
A
A
We
believe
that
the
true
value
of
the
jvc
web
is
to
enable
the
developers
to
give
them
a
seamless,
developer
experience
when,
after
they
have
already
decided
to
use
grpc
to
build
a
service
server
side,
stacks
and
grpc
web
will
enable
that
to
use
the
same
kind
of
development
model,
the
same
kind
of
schema
and
the
data
model
on
both
client
side
and
server
setup.
We
think
this
is
really
powerful
again,
if
you
know
if
the
developers
have
already
decided
to
adopt
a
grpc.
A
The
second
thing
is
we
want
you
know,
because
of
this
benefit,
we
want
to
make
sure
that
when
you
use
javascript
web,
the
kind
of
experience
you're
getting
is
not
like
a
secondhand
experience.
You
will
get
kind
of
like
you
know,
you're
using
a
solution,
that's
forced
on
you
by
the
choices
the
server-side
stack
developers
make
right.
We
want
you
feel
like
this
is
really
first
class
web
development
experience.
A
As
a
result,
we
tried
very
hard
to
make
sure
that
you
know
the
grpc
web
really,
you
know
fits
into
the
web
development
development
experience.
We
we
want
to
focus
on
things
like
api
code
generation,
build
and
also
in
terms
of
alignment
with
the
node
and
support
of
the
typescripts
and
all
those
things
and
we'll
do
that.
This
is
very
important,
then
try
to
optimize
the
so-called
communication
protocols,
so
yeah
so
overall.
A
All
that
the
thing
to
really
I
want
to
point
out
here
is
that
you
know
grpc
web
is
not
really
there
to
replace
rest
there's
a
humongous
kind
of
frameworks,
ecosystem
that
has
been
created
over
more
than
10
years
that
to
really
make
the
last
model
very
successful,
and
we
want
to
leverage
all
those
ecosystems,
we're
not
there
to
reinvent
things
or
the
place.
What
makes
rust
so
easy
to
use
develop,
but
the
key
here
is
as
a
principle
you
needed.
A
A
So
this
last
second,
so
this
concludes.
You
know
all
the
design
choices
I'd
like
to
highlight
to
me.
Like
I
know
I
really
wanna
highlight
the
the
purposes
of
you
know
going
through
those
design
choices
with
you.
Firstly,
I
want
to
give
you
a
little
bit
more
background
about.
You
know
how
grpc
and
jrpc
web
works
if
you're
in
the
process
for
using
grp
so
whether
adopting
to
work.
I
hope
this
will
help
you
and
understand
better
or
more
about
the
job.
So
I
have
to
give
you
more
background.
A
The
second
thing
is,
I
you
know.
I
hope
that
you
know
these
five
five
design
choices
were
made
kind
of
represent
a
lot
of
the
general
deadline,
principles
which
can
also
be
applied.
You
know,
if
you
happen
to
have
I
happen
to
be
in
the
process
of
designing
something,
a
new
solution
or
in
your
system.
That
is
basically
minimize
complexity,
think
about
the
future
and
also
try
to
you
know,
be
more
developer,
friendly
and
thinking
about
the
target.
You
know
deployment
environment,
so
I'll
conclude
talks
to
talk
about
it
quickly
about
the
roadmap.
A
So
obviously
you
know
we
still
want
to
give
you
better
future
support
and
try
to
have
a
feature
parody
with
jrpgs
itself,
and
so
we
are
very
actively
working
with,
for
example,
the
the
web
platform
teams,
the
chrome
team
developers
to
try
to
evaluate
how
to
support
request
streaming,
which
will
also
enable
how
to
practice
by
that
stream
right.
You
can
do
it
request
streaming,
basically
upload
and
then
do
a
download
after
the
upload
is
finished.
That
itself
is
not
a
bad
thing.
A
That's
not
of
you
know
the
so-called
footage
by
their
stream
for
the
food
duplex
pilot
streaming.
We
don't
really
have
an
answer
which
we
like
or
comfortable
with
that
we
would
like
to
support
it
for
a
long
time
to
come.
At
this
point
we
just
like
to
think
about.
You
know
some
kind
of
very
easy
workaround
that
not
just
give
you
a
buy
that
kind
of
supporter,
but
also
it's
easy
to
maintain
and
easy
to
scale
so
we'll
keep.
A
You
know,
keep
the
github
updated
with
the
grassroots
progress
as
we're
making
at
the
same
time,
you
know
we're
adding
more
support
in
the
so-called.
You
know
gateways
guys,
so
you
can
you
can
you
know
if
you
choose
to
support
the
grpc,
but
without
your
amboy
you're
able
to
do
that
today?
There's
already
swift
and
network
donaire
support
using
this
swift
and
donatis
native
http
web
frameworks
seems
to
work
really
seamlessly.
We
like
that,
and
we
want
to
extend
this
support
into
more
languages.
A
Also
things
like
security
features.
We
really
want
to
rely
on
the
languages,
specifically
specifically
the
web
platforms,
to
provide
such
a
sport
and
then
last
thing
is
photo
buffer
improvement
and
performance,
and
you
know
I
would
summarize
this
is
all
those
efforts
are
really
basically
a
continuation
of
the
same
kind
of
denial
tradeoffs.
We
just
discussed-
and
I
think
that's
very
important
for
us
to
stick
with
those
principles.
A
We,
you
know,
really
appreciate
all
the
help
we're
getting
from
the
community,
especially
in
the
gateways,
as
well
as
the
sort
of
ecosystem
support.
You
know
try
to
launch
our
pc
web
from
different
environments,
different
frameworks,
and
they
also
reported
success
report
issues.
We
see
a
lot
of
you
know
contributions
or
activities
on
github.
So
thanks
for
the
contributions-
and
you
know.
Lastly,
we
really
want
to
hear
your
deployment
experience.
If
you
have
been
using
grpc
web
and
jpc
very
successfully,
you
build
your
entire
web
application
student
jobs
to
web.
A
B
Thanks
hi,
hello,
everyone
yeah,
I
think
I'm
on
the
air
right
now.
I'm
gonna
take
questions
and
I'm
gonna
publish
each
question.
I
I
got
on
the
platform
and
I'll
read
the
first
question
I'm
getting
so
macintosh
is
asking.
Is
it
like
usgrpc
for
inter-service
communication
in
my
in
microservice
world?
I
would
have
if
I
understand
the
question
correctly.
B
To
server
side
the
kind
of
micro
service
deployment
right,
so
you
can
imagine
that
when
you're
doing
the
micro
service
you
have
different
applications
talking
to
each
other
you're,
you
know
from
vm
to
vm.
Now
with
jpc
web,
you
can
have
your
mobile
clients
also
talking
to
those
applications
kind
of
in
the
same
kind
of
micro
service,
world.
Now,
of
course,
because
the
clients
are
on
your
internet,
there
are
different
security
constraints
of
things,
but
fundamentally
I
would,
I
would
think
of
this.
B
I
would
look
at
this
as
extension
of
the
microservice
world,
as
opposed
to
inter-service
communication,
now
inter-service
communication,
if
I
understand
this
correctly,
you're,
probably
talking
about
like
apis
public
apis,
those
are
provided
by
api
gateways
that
could
still
support
a
user,
a
jpc
web
or
grpc
as
a
transport.
But
there
are
you
know
there
are
those
public
api
specifications,
things
like
there's
more,
you
know,
kill
playing
functions,
things
like
billing
and
different
of
those
things,
authorization
feel
free
to
add.
B
You
know
if,
if
I
didn't
answer
this
question
clearly
feel
free
to
submit
a
follow-up
question,
otherwise
I'll
go
to
the
next
one.
So
so
john
john
is
asking
is
jrpc
web
faster
than
last
apis,
grpc,
so,
okay,
so
the
question
is
at
the
networking
layer,
the
latency
of
which
of
using
grpc
web
is
really
decided
by
the
broader
apis
right.
B
All
the
networking
apis
provided
by
broad
and
also
the
server
side
stack
so
job
is
the
web
will
be
faster
than
rest
api,
not
because
of
the
network
stack,
but
because
the
the
protobuf,
because
pro
bus
is
more
compact-
and
you
know
it
was
basically
received
then
with
in.
If
the
link
is
it's
not
it's
not.
The
bandwidth
of
the
link
is
not
very
high.
Potentially
the
japanese
level
can
be
faster.
However,
the
cavity
here
is
the
the
pull
buffer,
the
clinton
pro
buffer
library.
B
We
probably
should
always
open
source,
only
support
this
kind
of
binary
encoding
format
within
google,
we're
using
a
more
like
a
json
encoded,
protobuf
format.
But
it's
not
exactly
json
change.
You
know
it's
not
the
put
above
translated
json
messages,
but
encoding,
it's
more
like
text
encoding,
so
that
that
format
is
far
more
efficient
than
a
binary
format
as
it's
been
currently
implemented.
B
B
The
next
one
is
also
from
banking
touch,
asking
about
upload
support
fire
update,
support
now,
potentially
because
there's
the
existence
of
the
a
proxy
or
gateway
between
the
between
the
broader
and
the
grpc
sub
endpoint.
But
actually
I
would
can't
support
something
like
that,
but
as
as
what
I
talked
about
on
the
slide,
we
want
you
don't
want
to
limit
to
the
scope
of
the
jbc
web
instead
of
trying
to
do
all
kinds
of
things
whatever
allows
you
to
do
so.
B
So
I
think
this
is
a
good
feature
for
sun
ecosystem
to
provide,
for
example,
there
is
a
popular
a
bit
of
kanji
rpc
gateway
right,
so
this
gateway
does
support
kind
of
different
things.
I
think
that
would
be
a
very
useful
feature
for
the
gateway
to
support,
but
the
rpc
web.
The
value
of
the
japanese
web
is
providing
the
client-side
developer
experience.
You
know
the
same
conclusion
as
the
same
apis
node,
and
all
that,
for
that
I
I
don't
feel
like
this
is
the
future
jack
swaps.
Your
support.
B
We
publish
a
java
and
gateway.
The
intent
is
that
it
will
be
compatible
with
all
the
webs
that
java
ee
provides
by
java
ie.
Here,
I'm
just
referring
to
the
server
respect.
You
know
not
everything
else.
That's
probably
not
related
to
jr27,
but
if,
if,
if
you
have
other
questions
related
to
e,
I'm
happy
to
answer
and
just
drop
a
follow-up
question
there.
B
B
But
you
know
all
the
things
have
been
deployed
in
production,
but
the
number
of
projects
that
are
actually
actively
using
grp2
web
is
over
100
right.
So
that's
part
of
the
sort
of
the
the
reason
we
are
very
cautious
about
what
to
support
will
not
support
google.
We
want
google,
the
own,
you
know
the
app
web
apps
are
it's
also
using
their
piece
of
web,
so
yeah,
it's
definitely
stable
and
robust
for
product
production
use,
and
you
mentioned
that
you
know
I
tried
to
you
know
since
this
is.
B
This
is
the
one-way
discussion.
If
you
are
thinking
about
things
like
you
know,
this
you
know
have
no
compatibility
problems.
You
know
if
you're
talking
about
on
server
side,
you
know
on
the
proxy
side
of
things.
Yeah
jrpg
is
not
compatible
with
http
and
for
the
purpose
of
hp
rust.
You
know
you,
you
shouldn't
you
shouldn't,
you
know
if
you
can't
actually
rest,
you
know
for
your
environment
and
then
you
should
be
able
to
do
that
as
well.
I
would,
I
would
say
you
know.
B
A
Okay,
I
guess
the
audio
is
working.
Sorry,
yeah!
We
have
some
problems
with
the
audio
and
the
next.
The
next
question
is:
what
is
the
recommended
tech
stack
with
grpc
web?
I'm
not
yeah,
I'm
not
too
clear
what
exactly
you're,
referring
to
as
tech
stack,
but
generally
crpc
web
on
the
client
side.
It's
just
a
javascript
libraries.
You
should
be
able
to
use
it
from
any
like
web
frameworks
on
the
server
side,
the
jpc
endpoint,
the
jfp
server
itself,
shouldn't
know
about
any
difference
about
you
know.
A
A
For
all
those
processes,
you
will
be
using
the
the
standard
web
frameworks
to
come
into
the
javascript
web
requests.
What
that
means.
It
will
be
using.net.
You
know
swift
and
java
simulator
and
all
the
standard
web
frameworks
to
terminate
the
requests
on
the
server
side,
which
means
that
they
should
be
able
to
integrate.
You
know
if
you
have
like
your
own
auth
wrappers
across
original
apps
securities
security
filters,
so
things
those
modules
should
be
able
to
work
on
top
of
the
grpc
web.
A
That's
that's
our
that's
our
design
goal
so
I'll
try
to
go
back
to
the
some
of
the
questions
I
already
answered,
since
the
audio
has
some
issues
yeah.
So
one
of
the
questions
about
the
ee
ee
support,
the
java
e
support
and
yeah
we're
gonna,
publish
we're,
gonna,
publish
your
support
on
server
side
to
have
the
simulated
framework.
A
Then
there
was
one
more
question
about
the
fire
upload
support,
and
my
answer
is
that
this
is
the
future,
maybe
more
suited
for
the
grpc
gateway,
which
is
another.
It's
a
community
contributing
project
and
for
grpc
web.
We
like
to
sort
of
be
aligned
with
all
this
sort
of
micro
service
languages.
Second
node,
which
will
not
support
file
or
something
like
fire
load,
but
for
upload
and
that's
what
was
questioning
about
its
jobs
well
faster
than
rust
apis.
The
answer
is
not
really.
A
The
the
latency
or
performance
is
mostly
decided
by
the
protobuffer
messages
versus
json.
We
will
publish
a
better
above
javascript
libraries,
which
will
be
able
to
encode
the
pro
buffer
message
just
in
a
more
efficient
format-
and
you
know
google
is
doing
this
format
for
many
many
years,
but
it
just
takes
a
little
bit
time
for
us
to
open
source.
This
library.
A
A
There's
a
question
about:
where
can
I
find
the
latest
documents
and
reference
examples
for
java,
so
everything
will
be
published
on
the
drc
web
github
report?
We
will
yeah.
We
will
make
some
kind
of
announcement
I'll
write
a
publisher
blog
about
this
once
once
everything
is
finished,
we're
still
developing
this.
The
javascript.
A
A
A
I
think
here's
my
sort
of
opinionated
views
about
this.
It's
a
good
question.
I
think
that
depends
on
a
few
things.
First
is
how
grpc
will
be
evolving.
The
way
I
see
it
is
jrpc
has
a
lot
of
adoption.
Many
language
support,
so
the
bar
to
introduce
portable
change
or
anything
like
that
is
very
high
to
assume
that's
the
case
for
the
ipc
that
you
know,
jbc
itself
is
very
stable.
A
Like
I'm
talking
about
why
project
with
that,
without
really
depending
on
the
web
platform,
hardware
performance
is
going
to
heading
so,
for
example,
I
am
working
on
this
thing
called
clone
origin
trial
to
decide.
How
do
we
support
the
client
streaming
using
fetch
streams,
the
things
that
we
cannot
decide
is
we
limited
the
fetch
streams
to,
for
example,
only
hd
1.1,
because
the
general
web
community
believe
that
you
know,
because
web
browser
doesn't
support
certain
features
in
hdp
chances
are
a
lot
of
you
know,
servers
boxes.
A
I
I
don't
know
if,
in
five
years
we
will
jrpc
web
or
web
clients
where
necessary
have
a
way
to
talk
to
trpc
directory
using
the
exact
grpc
http
2
protocol,
but
it's
certainly
a
possibility,
and
then
we
were
working
with.
You
know
the
broader
vendors
on
that
as
well.
On
the
flip
side,
you
know
whether
it's
also
evolving
there
are
certain
technologies
where
we
will
be
available
on
web
first.
I
think
the
best
example
is
like
http
3
http
and
all
those
things
actually
become
available
on
the
web
on
browsers.
A
A
A
B
A
B
A
A
The
next
question
is
tool
to
test
and
debug
grpc
yeah.
We
do
see
people
start
to
get
verified,
like
chrome,
extensions
to
debug
the
obviously
web
little
things.
So
I
think
we
will
try
to
publish
those
tools
or
or
those
contributions
over
time
and
also
therapies
to
work.
You
know
when
we
start
to
work
on
japanese
level.
A
We,
our
belief,
is
that
you
know
people
using
grp.
You
know
people
tend
to
like
use
web
web
or
browsers
as
a
way
to
develop
jobs
itself,
because
when
mobile
probably
is
more
popular
than
web
in
some
cases,
but
you
know
for
debugging
for
troubleshooting.
If
you
want
to
have
something,
as
you
can
see
it,
you
know
you
can
easily
interact.
You
know
with
a
server
endpoint
yeah.
Typically
you
want
to
use
web.
A
So
I
you
know
we
do
have
thoughts
about
making.
You
know,
for
example,
have
have
built
some
kind
of
form
forms
that
you
can
directly
input
photo
buffer
messages
on
broader
and
to
then
to
invoke
a
japanese
standpoint.
I
believe
those
kind
of
features
will
be
very
useful
for
debugging
jrpc.
You
know
just
jackson
web,
but
those
you
know
it's
a
lot
of
work
and
yeah.
If
you
know,
if
you
have
anything,
you
want
to
contribute
to,
let
us
know,
but
it's
something
we
are
our
room.
A
The
next
question
is
any
example
of
where
jrpc
web
use
their
issues
in
google
to
relate
so
so
in
google.
We
so
in
google.
The
way
things
are
going
is
very
much
sort
of
match
what
we
want
people
to
use
grpc.
So
basically
the
web
development
becomes
more
and
more
api
driven.
You
know
I
want
us
to
categorize
those
apis
as
internal
apis
are
what
you
call.
The
first
question
refers
to
as
the
micro
service
apis,
not
exactly,
but
basically
it's
the
thin
party
access
right.
A
So
it's
like
a
gmail
application
talking
to
a
gmail
server.
That
kind
of
use
case
and
the
grpc
is
the
standard
api.
You
know
rpc
just
the
apis
for
google's
apis
like
internal
apis
for
for
applications.
You
know
mobile
applications
or
web
app
issues
so
yeah.
I
think
in
overtime
most
of
the
google,
especially
the
new
web
applications
suburb
using
japanese
and
the
japanese
web.
Basically
they
will
all
be
using
grpc
on
server
side.
A
A
A
A
The
javascript
performance
and
and
also
make
it
a
more
secure
to
do
grpc
from
the
browsers,
but
because
generally
sending
binary
data
you
know,
involves
some
securities
compared
to
a
text
text
format,
data
so
yeah.
So
this
is
definitely
our
roadmap
to
publish
a
more
efficient
protobuf
library
for
for
web
for
web
applications,
and
when
that
happens,
I
do
believe
that
the
depths
of
you
know
not
necessarily
it
will
be
faster
than
the
if
you
do
just
unrest,
mostly
because
the
messages
will
be
a
lot
more
compact,
smaller,
basically
in
size,
competitors.
A
And
the
problem
is
this
format
so
internally
we
have
multiple
formats,
so
we
kind
of
have
to
unify
the
format
before
we
publish
it.
The
problem
is
once
we
publish
the
client,
we
have
to
support
the
format
and
also
we
have
to
figure
out
what
to
do
on
the
server
side,
because
the
transcoding
is
involved,
it's
a
different
format.
A
Another
reason
we
are
not
in
a
rush
to
publish
basis,
so
we
also
actively
try
to
improve
the
binary
performance
in
the
case
of
the
binary
performance
can
actually
beat
or
match
the
text
encoding
format
we
may
I
mean
I
want
to
publish
the
text
from
a
text
encoding
format,
because
it's
a
different
protocol
format.
That's
only
used
to
buy
brother
cards.