►
From YouTube: Contributor-first at AsyncAPI #13 - Parsers API
Description
6th of December 2021
A
C
D
E
A
A
B
B
This
is
completely
different
from
other
approaches
like
you,
you
usually
have
like,
for
example,
the
current
parser
gs.
Does
everything
all
the
functions
are
mapped
one-on-one
with
the
document
right
like?
If
you
need
to
get
messages,
you
have
to
know
where
the
messages
are
in
which
channel
which
operation
etc.
B
B
That
means
to
have
a
global
api
that
all
partial
implementation
can
follow.
Based
on
that
intent,
driven
api
approach,
where
we
can
also
add
some
guidelines
on
development
for
those
parsers
like
we
do
have
now
parts
rgs,
but
we
also
want
to
have
part
set,
go
which
it's
already
there
in
a
repository
in
a
working
working
process
thing
and
some
other
implementations
right.
So
this
will
act
as
a
guideline
and
some
kind
of
enforcement
for
developers
to
follow.
Follow
this
api
again,
we
will
see
more
about
that
later.
B
Especially
when
I,
when
I
joined
the
initiative,
so
it
was
very
hard
for
me
working
with
the
parser
because
I
didn't
know,
I
would
have
a
strong
background
on
the
spec,
and
this
is
something
it
seems.
It
happens
also
for
other
users
right,
so
the
need
of
having
a
deep
knowledge
of
the
spec
for
doing
basic
operative
and
with
basic
operative
again,
we
can
use
the
same
example.
B
It's
get
all
the
messages
my
application
receives
if
you
can
move
jonas.
Okay,
thank
you.
So
this
is
a
real
example,
a
code
example
for
making
that
operation
right
now
that
operative
sorry.
So
in
order
to
get
all
the
all
the
messages
my
application
receives,
I
will
have
to
filter
all
the
channels
based
on
a
operation.
In
that
case,
publish
then
get
all
the
messages
that
operation
could
have
and
then
just
return
right,
as
you
can
see
in
this
picture,
so
you
have
to
know
first,
what
publish
what
subscribe
means?
B
B
B
B
This
is
right
now
not
possible
to
do
with
the
current
implementation
in
in
the
password.
So
the
previous
example
that
I
showed
will
completely
don't
work
because,
as
operations
were
previously
inside
channels,
like
literally
inside
channels,
you
won't
you.
You
cannot
do
that
anymore
again,
so
you
cannot
get
messages
from
an
operation
that
it's
inside
the
channel
because,
as
I
said,
the
parcel
is
mapping
the
spec
with
functions
that
extracts
data
from
the
document.
B
Yeah,
you
can
pass
to
the
next
slide
please.
So
this
is
basically
what
I
was
explaining.
It's
not
anymore
channel
polish
and
messages,
because
operations
are
in
the
root
of
the
of
the
document,
so
it
would
be.
Let's
say,
operation,
publish
messages
right.
It
will
change
the
api
completely.
So
my
application
that
uses
this
parser,
like
templates,
will
have
to
be
updated
for
ensuring
the
new
changes
are
applied.
A
A
It
could
also
be
that
one
of
the
parsers
implements
one
of
these
functions
with
different
meaning
from
one
another.
One
of
these
examples
could
be
that
has
servers
returns
false
if
it's
an
empty
object,
for
example,
or
in
an
empty
array
where
others
define
it
as
well.
Servers
are
defined
like
it's.
It
returns
an
empty
array
that
is
not
considered.
A
One
of
the
other
pain
points
is
in
order
to
implement.
The
viruses
sometimes
require
a
deep
knowledge
of
the
specification
itself,
and
one
of
these
examples
could,
for
example,
be
how
do
you
handle
dereferencing,
because
one
of
the
key
points
is
that
we
like
to
use
reusability
in
a
lot
of
places,
for
example
using
rifts
to
reference
external
messages.
A
B
B
B
B
If
I
use
that
it
will
be
always
the
same,
no
matter
what
the
meaning,
if
the
meaning
change
of
what
is
published
or
what
is
subscribe,
because
we
see
application
prefix
there.
So
you,
as
application
always
will
have
your
messages
there.
It
doesn't
matter
if
the
implementation,
if
the
spec
changes
right.
So
if
you
move
to
the
next
slide,
you
will
see
the
example.
B
B
E
B
B
And
yeah
here
we
go
so
we
try
to
be
brief
enough.
So
there
are
a
lot
of
djs
for
some
of
you,
maybe,
but
I
would
really
like
to
to
start
some
discussion
and
gather
some
feedback
from
you.
So
we
enable
a
url
there
that
it's
a
hackindy.org
thing
where
we
can
write
some
pros,
cones
or
whatever
you
you
think
should
be
there.
B
E
E
E
Yeah,
so
I've
literally
so
yeah,
I'm
literally
come
from.
You
explain
something
at
the
start.
You
said
you
had
a
little
knowledge
of
the
spec
and
you're
trying
to
use
the
parser
parser
js.
You
have
to
understand
the
spec
to
use
the
parser,
and
this
is
literally
my
experience
I
had
like
a
month
ago
when
I
was
doing
the
visualization
stuff.
I
was
trying
to
use
the
parser.js
library,
but
I
was
kind
of
like
okay.
E
I
have
to
know
after
you
know,
as
you
said
earlier,
I
have
to
know
that,
and
I've
definitely
felt
that
so
going
going
from
an
intent
api
and
seeing
what
you
seeing
what's
been
some
of
the
things
on
here
like
yeah,
I
think,
personally,
I
think
most
of
them.
Well,
I
guess
the
details
will
come
out
later,
but
I
think
the
whole
principle
makes
sense
for
me.
I
don't
from
consumer
point
of
view
right.
I
don't
want
to
know
how.
E
If
I
want
to
get
all
the
messages
for
this
file,
I
don't
really
know.
I
don't
really
want
to
know
personally
anyway,
you
know
I
don't
really
want
to
know
the
implementation
of
that
yeah.
I
just
want.
I
just
want.
I
just
want
it
and
say
I
think
the
same
goes
to
a
lot
of
when
you
look
at.
I
think
I
think
anyway,
I'm
trying
to
think
of
sort
of
top
of
my
head,
but
I
think
a
lot
of
mature
apis,
a
lot
of
mature
sdks
and
everything
else
like
that.
E
Have
that
kind
of
pattern
right
as
a
consumer,
it's
like
it's
like
the
developer
experience
as
the
consumer.
You
kind
of
just
want
to
just
say:
okay,
here's
some
api.
If
you
want
to
get
all,
for
example,
you
showed
an
example
earlier.
If
you
want
to
get
all
the
messages
that
subscribe,
I
have
to
do
some
at
the
moment.
E
I
have
to
use
the
parser
and
do
this
mapping
stuff
and
then
how
subscribe
has
published
and
then
fill
them
out
based
on
if
they're,
subscribed
or
published,
whereas
in
a
new
way
you'll
be
like
give
me
just
give
me
all
the
subscribe
messages
or
give
me
all
this.
Give
me
all
that
which
is
in
which
is
yeah
from
an
api
point
of
view,
a
lot
better.
E
I
guess
I
guess
they're
still
gonna
be
I'm
looking
for
the
spec
now
or
the
version
one
document,
but
I
guess
there's
still
going
to
be
some
coupling
right.
That's
what
you're
trying
to
get
rid
of
is
the
tight
coupling,
but
you
always,
I
guess,
we're
always
going
to
have
some
coupling.
For
example,
what
happens
one
day
if
the
word
publish
was
gone?
E
Otherwise
subscribe
was
gone,
then
your
api
is
like
okay.
What
does
that
mean
anymore?
I
guess
you
could.
I
guess
you
could
do
things
like
non-breaking
changes,
so
deprecate
the
functions
as
we
go
forward.
I
think
that
would
be
cool
and
introduce
new
functions,
but
there
is
still
no
matter
what
we
do.
E
E
If
I,
if
I
was
to
join
another
call,
if
I
was
talking
to
talk
about
ace
and
kpis
someone
else,
we're
talking
the
same
language
right,
we
talk
about
operations
and
and
messages
and
channels,
and
everything
else
like
that.
So
I
think
I
think
that
make
I
think
that
makes
sense
what
you're
saying
there
has
to
be.
There
has
to
be
a
language
that
has
to
be
a
base.
C
What
are
the
limitations?
We're
really
missing
that
I
did
check
out
the
docs
directory
markdown
docs
that
you
folks
already
have
in
your
github
repo,
and
it's
amazing
I
mean
it
can
tell
that
you
have
been
really
doing
a
good
job,
maintaining
it.
So
I'm
kind
of
thinking
that,
basically,
I
guess
I
don't
know
that.
I
have
feedback
for
you
and
more
felt
that
I
have
some
take
away
points
of
action
items
of
things
that
I
can
add
to
the
docs
board.
C
So,
for
example,
now
that
I'm
aware
of
this,
I
want
to
create
another
issue
for
the
async
api
community
docs
and
our
github
board
that
we
have,
which
I
can
share
in
the
link
in
a
second
and
then
I'll,
create
that
issue
and
tag.
You
folks,
and
you
can
tell
me
more
information
about
what
you
think
is
needed
from
the
dock
side.
E
Yeah,
just
just
on
the
docks
there.
Actually,
I
guess
I
guess
with
intent,
api,
it's
kind
of
like
user
user
focused
or
user
driven.
So
I
want.
I
want
publish
messages.
I
want
subscribe
messages
and
I
think
would
be
quite
interesting
in
the
future.
With
this,
if
it
went
forward,
is
there
there
are
going
to
be
common?
I
don't
know
10
or
20
functions
that
most
people
will
use.
I
think,
anyway,
you
know
the
most
common
one
being
get
the
messages,
get
the
published
messages
whatever.
E
So
you
know
get
give
me
application.
Publisher,
publishable
messages,
that's
a
mouthful,
but
you
know
returning
these
messages.
Okay,
what
is
a
message
and
all
that
stuff?
So
I
don't
know
I
can
just
already
envision
it'd
be
nice.
Just
have
that
you
know
even
to
the
point
where
you
can
just
run
it
and
get
get
the
messages
up
in
the
documentation
code
themselves
and
have
a
play
around
with
it,
and
things
like
that.
Be
really
cool.
B
B
If
no,
is
it
worth
to
invest
time
at
some
point,
or
is
it
even
worth
to
invest
in
on
an
intern
api?
So
how
can
we
answer
those
questions?
It's
not
something
we
have
to
decide
now
and
we
won't
do
it,
but
we
have
to
gather
all
the
feedback
from
from
all
of
you,
so
we
see
spread
yeah
go
go
for
it!
Jonas,
you
wanted
to
say
something.
B
It's
fine.
No.
I
just
wanted
to
say
that
the
benefit
seems
to
be
like
clear.
There
are
more
benefits
that
we
wrote
somewhere
in
some
issues
already
and
and
it's
fine,
but
I
think
we
have
to
find
the
really
like
the
negative
sides
or
the
things
we
have
to
take
care
about.
Look
at,
for
example,
right
now
wrote
like
I
don't
think
there
can
be
any
negative
sides
on
the
internet's
driven
api
as
long
as
we
do
it
right.
B
Something
that
that
will
cause
introducing
this
change
is
that
we're
gonna
add
a
new
layer
right
of
extraction,
so
agree.
Users
won't
need
to
completely
understand
or
go
deep
into
the
spec,
but
user
will
need
to
understand
the
engine
driven
api
as
well,
so
they
try
to
pronounce
these
application
publishable
messages,
whatever
you
know,
so,
whatever
we
do
there,
it
should
be
taken
in
consideration
from
the
user
experience
or
developer
experience.
Point
of
view
should
be
easier
than
learning
the
whole
spec,
but
I
don't
think
it
should
be
like
close
to
that.
E
Yeah,
it's
interesting.
I
just
had
a
random
thought
too.
So
you
you
defined,
I
don't
know,
there's
a
hundred
functions
here,
right,
maybe
more
functions,
but
where
could
you
start
off
as
an
mvp
or
or
initial?
You
know
x
version.
So,
as
I
said,
get
get
the
top
ten
get
some
feedback,
maybe
get
the
top
ten
and
then
just
release
it.
You
know
and
see
yeah
and
that
would
be
truly
kind
of
intent,
driven
because
users,
hopefully
users,
will
make
pull
requests
or
suggestions.
E
Okay,
I
need
to
get
x
by
y
somehow
or
I
need
this
kind
of
api
that
you're
not
exposing
me
to,
rather
than
coming
out
with
the
whole
api
up
front,
because
I
guess
the
risks
of
coming
up
with
the
api
up
front
is,
I
don't
know
it's
a
whole
coupling
thing
again.
It's
like
is,
it
is
80
of
what
what
we're
about
to
do.
You're
gonna
be
in
quotes,
useless,
not
useless,
but
you
just
don't
mean
no
one's
gonna
use
that
as
much
as
the
other
stuff.
A
E
B
A
A
A
A
A
E
E
Integration
with
the
spec,
so
I
think
the
abstraction
makes
sense.
I
can
just
kind
of
foresee
the
developer
experience,
hopefully
being
a
bit
better,
which
is
which
is.
I
don't
have
to
be
an
expert
yeah.
I
want
to
use
the
spec,
but
I
don't
want
to
be
an
expert.
I
don't
want
to
spend
hours,
learning
the
spec
or,
for
example,
maybe
my
co-workers
throwing
me
over
a
speck
and
I
want
to
buy
some
toilet
or
something,
and
I
just
they're
there
they'll
be
level,
I
think
there'll
be
levels
of
yeah.
C
I
basically
think
that
a
good
developer
experience
is
letting
the
developer
use
the
tool
the
way
the
developer
wants
to
use
it.
So
if
you
don't
want
that
obstruction
layer,
because
you
really
love
to
deep
dive
and
feel
very
comfortable
with
the
spec,
you
should
not
be
blocked
from
doing
that.
But
if
you're
not
that
developer-
and
you
don't
really
want
to
suffer
and
feel
very
comfortable
with
the
spec,
you
should
be
able
to
be
empowered
via
that
layer
of
abstraction
so
as
to
still
be
able
to
build
things
and
that's
why.
C
B
Alejandra,
so
you
mean
that
the
implementation
should
also
respect
that
users
can
do
whatever
they
want
right
like
if
they
want
to
go
in
hard
mode,
let's
say
or
got
mode.
Let's
move
on
that
right,
like
you,
can
access
the
the
raw
object
or
the
raw
data.
Whenever
you
want,
you
don't
have
to
go
through
the
intense
right.
C
Yes,
that's
right,
you
know.
If
I
were
to
be
a
responsible
person,
then
you're
correct.
I
agree
I
would.
The
documents
would
have
both
versions
like
how
do
you
want
to
build
this?
Do
you
want
to
just
use
the
label
abstraction?
Then
you
can
do
this
or
option
b.
You
can
do
this.
So
absolutely
the
user
should
know
by
going
to
the
documents
that
they
have
these
two
amazing
options
to
pick
from
and
that
they
get
to
pick
the
one
that
works
best
for
them.
A
E
Yeah,
I
guess,
depending
on
how
you
access
it,
I
guess
so
some
libraries
out
there,
the
one,
the
ones
that
I
think
get
a
lot
of
traction
and
get
a
lot
of
use
is
is
is
is
when
it's
key
to
the
developer
experience,
just
as
you
you're
saying
so
you
start
off
at
the
layer
at
the
top.
You
know
this.
What
we're
talking
about
here,
the
intent,
api
right
and
and
most
people
probably
are
happy
like
yeah.
E
You
know
I
can
do
what
I
want,
but
you
do
have
the
use
cases
where
you
need
to
go
deeper
and
some
you
know
I'm
trying
to
think
some
examples
like
react
might
be
one.
For
example,
some
libraries
are
really
good
where
you
can,
you
do
have
apis
to
dive
in
deeper
and
they
have
documented
apis
to
differ
from
deeper.
This
is
like
you,
20
of
developers.
E
Right,
don't
want
to
write
plugins
when
I
write
this
one
want
to
do
this,
but
the
downsides
to
that,
I
guess
is:
we've
got
to
maintain
both
if
we
were
to
do
it
like
that.
You'd
have
to
maintain
this
deeper
api
that
you
don't
really
know
what
the
use
base
is
there
and
and
the
other
one.
So
I
guess
just
maintenance.
If,
if
we
decided
to.
C
Have
it,
I
think
you
also
want
to
do
the
extra
I'm
sorry,
I
didn't
mean
to
drop
dave,
but
I
think
his
point
is
really
important
and
we
should
not
forget
it,
and
so
the
maintenance
pain.
How
do
we
know
it's
worth
it,
so
we
also
need
to
do
a
community
survey
to
confirm
from
the
community.
Do
you
need
both
options.
C
E
I
thought
I
think
I
think
I
don't
know.
I
think
the
key
is
just
to
start
start
at
the
top
layer.
Let's
just
scratch
it
off.
I
would
anyway
and
then
otherwise,
if,
if
we
start
by
releasing
both,
you
know,
here's
the
final
product,
here's
our
you
know
these
these
apis.
That
we
think
is
really
good.
I
think
it's
the
80
20
rule,
as
I
mentioned
earlier.
I
think
you
will
probably
find
that
people
might
not
want
to
deep
dive
right
and
what's
the
point,
what's
the
point
in
writing.
That
code
was
point
maintenance.
C
You
really
need
to
do
better
with
this
and
then
to
play
devil's
advocate
on
dave's
plane
cause
like
dave,
keeps
bringing
up
really
interesting
points,
and
that's
why
I
keep
replying
to
them
to
play
devil's
advocate.
If
I
remember
what
we
were
talking
about,
I
think
that
how
do
we
know
specifically
20
is
the
actual
number
of
developers
who
like
to
deep
dive.
C
A
I'm
just
going
to
add
this
point
up
here,
just
to
remember
it
that
we
need
more
data,
or
at
least
a
way
to
get
data
on
the
usage.
What
is
being
used?
How
is
it
being
used?
I
said
I
think
we
already
have
some
of
the
issues,
at
least
in
the
javascript
parser,
so
it
is
something
that's
laying
in
the
back
mind,
but
it's
a
good
point.
C
C
There
could
be
a
marketing
person
who
is
getting
up
to
speed
on
the
tool
so
that
they
could
do
marketing
about.
Why
they're
using
a
sync
api
for
a
thing,
so
just
remembering
that
the
layer
abstraction
also
benefits
people
that
still
need
to
understand
technical
products
or
technology
without
being
themselves
the
developer.
C
A
E
Yeah
no
yeah,
I
didn't
think
I
didn't
think
about
that,
but
it
totally
makes
sense
as
again,
I'm
kind
of
just
like
I
kind
of
just
vision
of
the
other
projects
like
you
know,
they
get
a
lot
of
traction,
but
you
know
like
they
have
like
super
bass,
for
example
how's,
the
landing
page.
The
first
things
you
see
are
like
apis
right,
but
the
apis
aren't
like
crazy.
It's
just
like
a
two-liner
and
it'll,
be
like
async
api.
E
E
It's
kind
of
getting
that
message
across
right
is
this
is
how
easy
it
is
once
you
have
once
you
let
people
do
the
spec
and
invest
in
the
spec.
This
is
how
easy
it
is
to
get
value
from
the
spec,
with
two
lines
of
code,
one
line
of
code
or
whatever,
whatever
whatever
you
know
so
yeah,
I
yeah.
I
didn't.
I
didn't
think
of
that
at
all.
So
it's
good
shout
out.
C
I'm
feeling
pretty
good
about
myself
right
now
and
I
think
that's
exciting,
because
then,
if
anyone
can
have
a
better
understanding
of
the
tool
by
you
know
things
like
this,
then
it'll
be
easier
to
spread
the
world
of
this
open.
The
word
right
of
this
opposite
community,
because
then,
if
more,
if
this
is
easier
to
learn
to
understand,
then
more
people
will
join
and
want
to
check
it
out
and
that's
how
you
get
that
person?
That's
not
in
developer.
C
Job.
Sorry
word
in
english,
I'm
forgetting
that's
how
you
get
someone
in
your
company
or
organization
or
community
who
is
not
specific,
a
developer
to
maybe
like
maybe
they
land
on
this
and
they
go.
This
is
really
cool.
This
sounds
similar
to
what
I
heard
my
developing
team
talking
about.
I
bet
this
is
useful
to
us,
and
so
then
they
can
grab
this
and
say:
hey.
C
Have
you
guys
heard
about
a
sync
api
and
then
you
know
we're
assuming
that
only
developers
will
be
the
first
to
land
on
our
website
or
to
hear
about
this,
but
that's
not
always
the
case
right.
There's
a
lot
of
lateral
stock
stakeholders,
stalkers
stakeholders
and
lateral
teams
and
communities,
people
that'll
be
googling
just
like
us
and
find
out
things
and
say
I
should
share
this
with
my
developer
team
or
my
developer
community,
so
we're
also
like
shooting
ourselves
in
the
foot.
A
B
Before
starting
to
think
about
this
indian
drive
and
blah
blah
blah,
we
spent
some
time
analyzing
our
current
code,
like
in
all
the
repositories
we
have
that
are
using
the
parser
currently
like
all
the
templates,
the
generator
and
some
other
and
all
those
intents
are
based
on
that,
which
is
something.
So
this
is
important
to
know
that
they
are
based
on
really
useful
or
real
use
cases
or
real
intents
anyway.
I
agree.
B
A
That's
a
good
point,
and
actually
I
actually
forgot
everything
about
that.
We
did
that.
So
all
the
intents
and
dave
this
is
goes
hand
in
hand
with
your
minimal,
viable
product.
Right
is
that
all
of
the
intents
that
are
currently
present
is
based
on
templates
and
other
usages
of
the
parser
that
we
currently
have.
A
A
I
want
to
ask
the
question:
is
it
a
good
and
bad
thing
to
decouple
the
parser
against
the
specification,
because,
in
terms
of
this
breaking
changes,
for
example,
how
far
can
we
stray
the
parser
api
or
the
intent
driven
api
from
the
current
spec,
because
the
the
the
further
away
we
are
from
each
other,
the
more
abstract?
Will
that
also
be
for
users
in
a
sense?
If
that
hope
that
makes
sense.
E
E
Come
over,
I
was
going
to
say
now,
but
but
I
think,
you're
right.
I
think
it's
something
to
be
considered
for
sure,
because
the
last
thing
you
want
to
do
is
write
an
abstraction
on
top
and
then
someone
people
got
to
learn
the
abstraction
on
top
and
they're
like
okay,
you
know
the
async
api
respect
talks
about
operations,
but
this
this
this
thing
might
somehow
interpret
that
somewhere
differently.
You
know
how
I
guess:
how
opinionated
can
it
be
and
the
opinions
might
hurt
you
right
or
they
might
guide
you.
B
E
I
think
this
no,
I
wrote
down
when
you
came
through
earlier.
I
think
I
I
don't
know
if
you
thought
about
this
or
if
this
is
a
crazy
thing
to
do
or
what,
but
if
you
can
enforce,
if
you
have
the
api
and
it's
well
documented
and
you
can
enforce
that
stuff,
like
you
have
let's
say,
version
one
and
go
parser
javascript
parser,
php,
parser
or
whatever
you
could
in
theory.
E
I
don't
know
if
you
thought
about
this,
or,
as
I
said,
but
you
could
in
theory,
I
guess
test
parsers
against
the
spec
right,
so
you
could
say:
okay,
php
passes,
someone
comes
along
and
writes
one
and
it's
like
you
could
run
these
somehow
run
these
spec
files
or
this
spec
or
this
test
to
make
sure
that
all
functions
were
implemented,
that
an
opera
that
it
returned.
Given
this
file
that
when
I
called
to
get
this
operation,
it
returns
kind
of
what
I
expect.
What
is
an
operation?
What
is
an
operation
model?
E
E
E
You
know
if
you
want
to
write
an
async
api
parser,
an
official
one,
then
these
are
enforced,
and
that
brings
benefits
because
we're
kind
of
okay.
If
we're
enforcing
that,
that
means
we
can
standardize
that
that
means
we
can
talk
about
the
same
language,
the
domain,
language
and
operation,
all
this
kind
of
stuff.
When
we
make
breaking
changes,
we
can
easily
go
and
do
that
across
if
they're
guidelines
and
it's
yolo
land,
you
know,
then
it's
like
well
good
luck
to
you
all
right!
Good
luck
to
your
go
parser
because.
B
As
you
may
remember,
one
of
the
goals
on
a
sync
api
roadmap
was
to
decrease
the
time
from
a
user
to
implement
something
based
on
the
on
the
spec,
since
we
are
going
to
unify
experience
for
users
that
are
using
the
parsers,
these
aligns
totally
as
well
with
this
goal.
Basically,
so,
having
known
one
api
you
can
you
can
reduce
the
time
on
implementing
whatever
tool
on
top
of
the
parser
one,
because
it's
based
on
an
intent,
driven
api.
B
E
Yeah,
it's
good
shout
out,
I
think
it
you
know.
Ultimately
I
guess
I
guess
from
my
point
of
view.
I
think
it
would
be
nice
if
you
had
official
parsers,
that
they
followed
the
same
api
and
they
followed
the
same
language.
I
think
for
me
the
key
is
the
language
and
like,
if
I'm
asking
for
a
message
or
an
operation,
I
get
an
operation.
E
Okay,
what's
an
operation,
you
know,
let's
define
that,
because
if
that's
the
same
in
php
and
mode
and
go
and
everything
else,
then
I
think
it's
like
it's
like
rest
right.
It's
like
what's
a
post
request?
Okay,
we
all
kind
of
kind
of
get
that,
what's
you
know,
there's
a
lot
of
terminology
in
in
rest
and
apis
that
we
understand
there's
a
lot
of.
I
think,
there's
a
lot
of
newish
terminology
here
that
coming
to
async
api
new.
E
Is
I'm
in
node
right,
I'm
a
developer,
I'm
writing
some
stuff,
I'm
doing
some
stuff
and
then
there's
another
team
over
there
doing
some
go
stuff
and
they're
using
the
part
and
then
we're
all
using
18
kpi,
and
now
we
we
go
away,
and
we
talk
about
what.
Why
have
you
done
it
like
that?
Why?
Why
is
your
operation
like
that?
Oh
because
that's
what
an
operation
is,
and
it's
like?
No,
no!
No,
the
the
the
node
library's
given
me
like
this.
Oh
no,
the
go
library
is
opinionated.
A
So
yeah,
thank
you,
everyone
for
participating.
We
are
out
of
time.
Unfortunately,
so
we
are
unable
to
talk
or
to
continue
the
discussion,
but
if
you
have
any
extra
comments,
positive
size,
negative
sides
for
the
introduction
of
these,
please
do
let
us
know,
I
think
you
all
have
access
to
the
document
as
well,
and
otherwise
just
ping
us
on
slack
and
yeah.
Thank
you,
alejandra
and
dave
for
joining
us
and
see
you
around
cool,
see.