►
Description
Service Interoperability With gRPC - Varun Gupta & Tuhin Kanti Sharma, Salesforce
This session will talk about the need for standardization for service to service communication at Salesforce and a solution that is implemented using gRPC across polyglot systems. We will share the implementation of our framework for Last Known Good [Artifact] service using gRPC. We will discuss how we used Java Spring Boot to implement a gRPC call framework and integrated it with a standard authentication protocol used at Salesforce. We will also share our future plans of moving to reactive streams for our gRPC service in Java.
A
A
Before
we
jump
into
the
cool
stuff
a
bit
about
myself,
I've
been
very
lucky
to
be
with
salesforce
for
10
plus
years
and
have
had
opportunities
to
learn
from
the
best.
I've
always
considered
myself
to
be
a
learner,
whether
it
is
engineering
or
other
things
in
life.
There
is
something
you
can
learn
every
day.
My
current
learning
journey
outside
of
work
has
been
piano
and
music
theory
and
I've
been
surprised
on
how
closely
it
relates
to
engineering.
A
A
A
Salesforce
services
are
interconnected
so
as
to
allow
our
users
to
have
a
360
view
of
their
customers
developers.
Building
these
services
need
a
way
to
set
up
their
environments
with
a
combination
of
these
services
to
build
and
test
their
integrations,
and
that
is
when
they
use
our
environments
platform.
A
It
probably
wasn't
a
surprise
if
the
answer
was
that
they
will
be
able
to
consume
it
sometime
next
year.
Well,
using
grpc,
we
were
able
to
develop
idiomatic
client
and
service
stubs
that
allowed
us
to
enhance
our
service
dynamically,
without
having
to
ask
our
clients
to
update
their
implementation
with
native
mtls
integration.
It
provided
us
capability
to
build
a
secure
and
authenticated
communication
setup
and
we
were
able
to
achieve
a
high
degree
of
consistency
and
reliability
through
features
like
speculative
retries,
as
well
as
achieve
low
latency
for
requests
and
responses.
A
B
B
B
B
B
B
B
B
The
clients
which
were
using
the
earlier
version
of
the
service
continue
to
ignore
this
field,
and
now
we
can
have
the
new
clients
which
can
now
start
consuming
this
new
field.
This
enables
us
to
have
to
ship
versions
without
breaking
clients,
existing
client,
and
this
helps
us
in
in
having
a
consistent
experience
for
our
customers.
B
You
would
notice,
in
the
service
definition
that
it's
again
language
agnostic-
it
is
talking
about
and
strongly
type
it's
just
talking
about
the
service
methods
it
has
return
types
in
stream
and
grpc
enables
us
to
have
a
very
simple,
martial
link
protocol.
It
helps
us
enable
streaming
which
gives
us
better
availability
and
works
with
well
with
mtls
authentication,
so
we
get
authentication
and
encryption.
B
B
B
We
will
be
talking
about
the
unitary
streaming
here.
There
is
bi-directional
streaming
too.
We
used
unary
streaming
in
this
code,
fragment
find
enable
configurations,
will
stream
its
response,
as
you
will
notice
that
there
is
a
return
type,
but
instead
we
use
the
stream.
There
isn't
a
return
type,
I
beg
your
pardon
and
instead
we
use
the
stream
observer
as
one
of
the
method
parameters.
B
This
response
observer
on
next
starts
streaming.
The
response
and
on
completed
you're
notified
that
the
rpc
is
complete
streaming,
enables
the
service
to
stream
response
elements
as
they
become
available
and
is
a
much
more
efficient
way
than
the
traditional
request,
weight
response
which
could
cause
us.
Several
timeouts
bi-directional
streaming
further
enhances
this
by
having
even
the
client
stream
request
elements
and
and
the
server
stream
response
element.
So
it
becomes
a
bi-directional
communication.
B
And
here's
where
we
would
like
to
talk
about
another
offspring,
sales
forces,
springboard
open
source,
libraries,
the
reactive
grpc
reactive,
rpc,
further
improves
our
availability
by
providing
flow
control.
In
addition
to
streaming,
the
float
control
enables
the
clients
and
servers
to
implement
back
pressure
and
I'll
talk
a
bit
about
that.
B
If
there
are
very
fast
clients,
they
do
not
overwhelm
the
server
and,
if
there's
a
very
fast
server,
it
doesn't
overwhelm
slow
clients.
So
flow
control
is
an
additional
benefit
over
availability,
which
enables
fastens
the
fast
servers
in
fast,
slow
or
any
amount
of
speed
lines
and
servers
to
communicate
with
each
other.
B
B
B
Client
strips
can
be
auto
generated
from
from
the
prototype
of
message,
the
entire
message
you
could
use
to
generate
the
client
stubs,
which
can
then
be
used
by
a
service
for
with,
but
the
clients
to
communicate
with
the
service.
Let's
look
into
how
we
generate
that
in
the
in
the
examples
here
we're
generating
the
client
stubs
in
java,
using
the
plugin
and
in
python
doing
the
same.
This
plugin
accepts
the
dot
proto
file
as
input
once
we
have
generated
these
stuffs.
B
B
So
there
are
two
kinds
of
communication
paradigms:
synchronous
and
asynchronous,
and
the
auto
generated
stubs
come
in
in
those
flavors.
They
are
generated
in
three
types,
but
semantically.
There
are
two
kinds:
one
is
for
synchronous
and
there
are
two
kinds
which
are
in
asynchronous:
I'm
going
to
talk
about
one
two
of
them,
the
blocking
stuff,
which
is
the
synchronous
one
and
the
is,
and
the
asynchronous
stuff,
which
is
the
new
stub
in
the
second
second
of
code,
fragment
in
the
presentation.
B
The
blocking
stub
preserves
the
same
semantics.
It
lets
you
have
the
request,
weight
response
for
format.
So
if
there
are
clients
which
cannot
function
with
streaming,
they
can
continue
to
use
that
the
non-blocking
async
stop
uses
the
great
streaming
features
of
the
protocol
and
can
let
you
have
better
availability.
B
B
B
Now,
let's
summarize
this
entire
life
cycle
of
the
service
we
talked
about,
so
we
talked
about
the
message
format.
The
protocol
of
message
format,
which
was
language
agnostic,
which
enabled
us
to
do
code
like
language,
agnostic,
implementations
for
java
and
python.
We
talked
about
the
salesforce
open
source
spring
boot
libraries,
which
helped
us
do
the
grpc
service,
as
well
as
a
reactive
grpc
service.