►
From YouTube: API Vision working group #10
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
hello,
how
you
doing
andy
good
thanks?
How
are
you
doing
pretty?
Well,
it's
a
different
background
for
you,
yeah
yeah,
I'm
not
at
home,
I'm
actually
at
a
birthday
party.
Oh
really,
yeah!
It's
a
kid's
birthday
party,
but
I
just
sneaked
away
for
a
while
sure.
Hopefully
we
can
keep
it,
keep
it
quick
and
let
you
get
back
to
it:
hey
fabio
hi,
grant,
hi
hi,
handy
hello,.
A
A
I
think
we've
got
a
quorum
and
we
are
already
recording
also
it's
great-
that
the
the
calendar
invite
work.
This
time
I
went
and
tried
to
update
the
zoom
link
to
make
sure
that
we
had
no
issues
so
looks
like
it's
working
out.
B
A
Ahead
and
if
you
have
any
updates,
please,
please
do
add
them.
The
first
thing
I
want
to
share
is
that.
C
C
A
A
Think
you
know
we
will
have
arturo
back
soon,
but
it's
gonna
be
great
to
have
all
the
support
that
we
can
so
due
to
his
time
zone.
It's
a
little
bit
challenging
for
him
to
show
up
live
on
this
meeting,
and
I
think
this
is
the
time
that
works
for
the
most
people,
so
he's
going
to
continue
to
explore
how
to
how
to
facilitate
a
little
bit
more
asynchronously.
A
So
you'll
see
he's,
got
a
lot
of
comments,
he's
adding
to
issues
and
and
he'll
help.
You
know
provide
a
little
more
oversight
and
support
where
he
can
so
yeah.
If
anyone
else
wants
more
of
an
official
role
happy
to
have
more
more
people
joining
in,
I
by
no
means
mean
to
run
this
by
myself.
I
definitely
can't
do
that,
so
the
more
the
merrier.
A
Okay
next
item,
I
didn't
add
a
link
yet
but
api
gap
analysis
we
were
targeting
for
today.
It
may
be
something
to
revisit
if
we
need
to
have
a
little
bit
more
time
to
get
participation,
but
once
that,
once
we
hit
that
date,
I'd
like
to
go
back
in
and
evaluate
what
we've
learned
so
far
from
those
that
have
participated.
A
I
would
like
to
kind
of
understand
the
effort
to
start
to
address
some
of
these
gaps
and
then
think
about
how
to
how
to
share
this
analysis
out
to
more
of
git
lab.
Let's
get
more
of
a
comprehensive
analysis,
so
I'll
pause
there.
If
anyone
has
any
comments,
anything
that
you
think
that
we've
learned
through
this
process
so
far
opportunities
to
improve
how
he
how
we
could
just
go
about
identifying
gaps,
I
think
it
could
be
laborious
for
for
teams
to
do
this.
A
Well,
so
far
from
the
graph
analysis,
we've
done
on
the
catalyst
I
can
speak
for.
The
verify.
End
points
get
analysis.
We've
noticed
that
we
have
scenarios
of
force
where
we,
the
end
point
is
implemented
at
rest,
but
we
are
missing
either
limitation
or
the
querying
graphql,
or
we
also
have
the
other
way
around.
Sometimes
it
does
it's
like
intentionally
where
you
know
center
things
are
kind
of
considered
internal
apis
and
we
want
only
to
have
them
available
in
rest,
but
in
some
cases
it's
just
like
that.
A
The
way
I
implemented
originally
rest
that
we
never
had
any
use
case
to
convert
them
into
graphql
and-
and
that
could
be
because
the
the
front
end
is
still
using
data
passed
through
the
controller
and
and
if
we
had
reworked
that
using
new
components,
we
would
have
used
like
some
graphql
and
the
points
that
at
that
point
implement
also
the
graphql
queries
or
or
mutations
the
one
of
the
kind
of
popular
use
case
of
the
gaps
that
we
found
was
the
mismatching
implementation
between
rest
and
graphql.
C
Where
permission
checks
are
done
slightly
differently
among
the
two
endpoints
from
from
that
to
actually
using
different
logic.
In
one
case,
we
might
use
some
service
objects.
Another
casement
might
have
a
similar
implementation,
but
if
you
want
to
fix
a
bug,
it
might
not
be
fixed
on
on
both
sides.
So
this
is
a
problem
with
maintenance
and
it's
kind
of
a
more
subtle
because
it
looks
like
we
have
logic
in
both
graphql
and
rest,
but
in
reality
these
two
implementations
are
different.
C
So
thanks
for
sharing
that,
I
guess
one
one
idea
is-
is
that
we
could
kind
of
better
document
somewhere
what
we're
coming
across
when
we're
talking
about
like
identifying
gaps
and
like
these
are
common
patterns
to
be
looking
for.
It
seems
like
some
teams
who
have
come
across
this
issue.
They
don't
know
where
to
start,
so
I
think
a
little
bit
better
guidance
on
how
to
get
started
in
in
doing
this
analysis
and
who
you
need
on
the
team
to
participate,
to
be
able
to
really
get
something
useful.
C
Yeah
you
mean
like
how
to
get
other
teams
to
still
do
this
analysis,
yes
and
try
to
find
it
yeah.
We
could
probably
document
some
of
the
the
findings
that
we
have
made
with
some
examples.
This
kind
of
three
cases
that
we
found
so
far
and
then
encouraged
to
find
some
other
differences
and.
A
A
I
think
like
I,
I
was
kind
of
surprised
to
see
the
it
came
up
in
the
in
the
mr,
where
we're
trying
to
implement
the
graph
or
implement
the
rest
endpoints
as
graphql
queries
that
the
the
way
we
cache
rest
endpoint
responses
would
sort
of
be
incompatible
with
the
graphql
approach,
but
like
the
more
the
thing
that
was
more
interesting
to
me
was
like
how
that's
tightly
coupled
to
the
rest
layer
like
it
can't
really
like.
C
Like
we
have
this
sort
of
like
layer
that
the
services
interface
with
for
doing
both
like
the
fetching
of
the
data,
as
well
as
the
like,
the
auth
z,
part
right,
which,
like
I
haven't,
dug
into
like
how
the
graphql
resolver
stuff
is
implemented
too
much
but
like
it
seems
like
that.
Logic
is
just
completely
it's
not
like
shared
at
all
right.
So
I
think
that
to
fabio's
point,
it's
like
identifying.
D
These,
like
high-level
areas
where
we
could
consolidate,
makes
a
lot
more
sense
than
focusing
on
the
individual
points,
because
the
endpoints
are
going
to
change
after
this
analysis
is
done
right,
like
we
can't
there's
no
sustainable
way
to
keep
that
up
to
date,
so
figuring
out
like
where
the
opportunities
for
for
deep
consolidation
are
and
then
focusing
on.
That
is
the
side
effect
is
going
to
be
that
that
that
we
have
better
coverage
on
both,
I
think
yeah.
I
think
I
think
that's
absolutely
fair.
D
I
think
it
is
just
just
to
note
that
it's
not
that
the
logic
is
different,
we're
quite
good
at
least
encapsulating
our
authorization
logic
and
the
policies.
So
we
have
that
defined,
at
least,
but
it's
more
that
the
the
places
where
you
could
put
these
checks
are
different
same
thing
with
cap
with
caching,
you
you,
and
there
is
resolvers
and
endpoints,
just
have
fundamentally
different
phases
that
they
step
through,
and
so
the
places
we
where
we,
where
we
put
the
same
checks,
are
different.
D
Whatever
that
looks
like
and
so
like,
I
think
we
recognize
that.
There's
like
especially
we
take
that
like
fields
include
approach
that
that
fabio
pointed
to
in
the
json
api
specification,
like
that's,
going
to
give
us
the
opportunity
to
not
even
have
to.
E
Implement
a
lot
of
the
endpoints
that
we
have
on
the
rest
side
today,
because
you
could
query
the
relationships
to
some
extent
through
the
rest,
api
absolutely
and
that
maps
very,
very
cleanly
to
concepts
in
graphql
sets
the
edit
it's.
If
anything,
is
it's
kind
of
a
it's
a
special
case
of
graphql,
where
you
have
the
queries,
predefined,
that
you
can
use
fields
and
so
yeah.
All
that
to
say,
like.
I
think
that,
like
even
when
we
look
at
like
the
the
caching.
D
D
E
Understood,
okay,
I
guess
one
one
comment
I
would
make
is
the
intent.
I
guess,
of
the
the
analysis.
First
was
that
once
once
we
do
this
a
single
time
that
we
establish
some
type
of
potentially.
D
A
configuration
layer,
some
some
kind
of
programmatic
way
to
see
across
what
we
have
in
refs
versus
graphql,
but
also,
I
think,
somehow,
aligning
or
syncing
this
up
with
what
we're
actually
exposing
in
terms
of
features
like,
and
I
don't
think
there's
we've
talked
talked
about-
how
there's
not
really
a
good
way
to
do
that
today.
But
how
will
we
get
insight
into
features
that
we're
building
that
don't
have
apis
unless
we
start
with
the
manual
effort
and
then
start
to
just
like
define
this
like
it's.
E
You
know
thought
I've
had
on
this,
but
I
kind
of
see
where
we're
talking
about
like
we
could
fundamentally
be
changing
the
technology
and
how
we
approach
this
and
how
we
approach
development
so
yeah
they.
I
don't
see
the
analysis
as
intended
to
necessarily
go
piece
by
piece
and
fix
everything
in
v4,
but
that
we
kind
of
get
a
an
interpretation
of.
What's
there.
A
Programmatically,
so
we
don't
have
to
do
this
manually
again
in
the
future,
which
I
don't
know
what
that
might
look
like,
but
yeah.
I
don't
know
any
opinions
on
that,
or
is
that
just
going
the
wrong
direction?
We
should
be
really
thinking
about
a
v5
if
it
seems
like
there's
some
opinion
that
we
should
be
focusing
on
like
a
v5
version
of
api
and
updating.
A
I
think
we
can't
really
fundamentally
address
the
problems
without
looking
to
to
v5
right,
because
what
that
boils
down
to
is
that
people
want
to
be
able
to
use
the
rest
api
to
get
access
to
all
the
data
that
they
that
they
need
right
and
right
now
we
have
like
a
bunch
of
endpoints
that
exist.
D
And
relationships
that
they
need
to
fulfill
their
particular
use
case,
that's
a
much
more
general
solution,
but
certainly
not
something
that
we
could
ever
even
consider
implementing
in
in
v5,
because
it's
necessarily
a
a
breaking
change
in
v4
yeah
and
not
to
mention
the
fact
that,
like
I
think,
what's
more
important
than
like
the
endpoint
coverage
is
like
the
the
data
models.
Right
like
nobody
wants
to
have
to
deal
with
two
different
representations
of
what
a
merge
request
is
whether
they're
fetching
data
from
the
graphql
endpoint
or
the
rest
api.
D
They
want
that
that
that
data
model
to
be
the
same
and
and
certainly
it
would
be
much
easier
from
our
perspective
to
come
up
with
these
generic
endpoints
and
generic
solutions
rather
than
trying
to
go
through
piece
by
piece.
I
think.
D
We
can
make
a
lot
of
progress
on
v5
with,
I
think
very
few
endpoint
implementations,
especially
if
they're
the
types
of
endpoints
that
allow
people
to
specify
the
data
that
they
want
returned.
D
Got
it
well,
I
think
we
have
a
an
issue
for
this,
which
I
could
probably
hunt
down
pretty
quickly.
D
And-
and
I
think
like
from
from
our
own
perspective,
like,
I
think,
a
really
good
insight
here
is
the
fact
that,
like
the
front
end
calls
the
rest
api
for
certain
use
cases
like
we
don't
we
don't
have
equivalent
graphql
endpoints
right
so
like
to
me
when
we
say
that
we're
going
to
go
api
first,
that
that
should
not
only
mean
that
we're
not
doing
things
in
like
haml
templates
with
like
server-side,
rendering
and
stuff
like
that,
but
it
should
mean
that,
like
a
graphql,
endpoint
exists
first
and
foremost
for
every
single
thing.
D
Right
and
even
when
we
talk
about
internal
apis,
I
would
love
to
see
us
standardize,
the
graphql
endpoint
as
the
surface
area
for
all
internal
apis
as
well.
I
think
that
like
if
we,
if
we
went
down
the
path
that
we
were
talking
about
doing
in
that
one
issue,
discussion
where,
like
we
have
workhorse
act
as
the
proxy
for
how
these
graphql
requests
get
translated.
The
work
that
we
would
do
there
would
carry
over
to
things
like
italy
and
the
kubernetes
agent,
and
all
these
other
services
that
are
written
and
go
that.
A
D
And
stuff
like
that
by
using
the
the
graphql
api
instead,
so
I
think
I
think
like
I
would
like
to
say
that
when
we
say
api
first,
we
mean
like
graphql
first
and
we're
going
to
commit
to
using
the
graphql
api
for
everything
across
all
of
our
services.
I
think
that
would
be
a
good
definition,
yeah
and-
and
I
think
there's
so
there's
two
issues.
I'd
point
you
to
this.
One
is
start
v5
api.
D
And
the
other
one
I
would
point
to-
is
this
one
here
and
the
next
bullet
the
api
vision
prioritization?
This
was
my
initial
kind
of
stab
at
this.
My
my
initial
proposal
for
how
we
would
prioritize
work
based
on
what
we've
learned
from
customers
based
on
the
discussion
I've
been
hearing
here,
so
I
think
if
we
can
take
it
into
those
issues,
you
know,
I
think
definitely
an
api
vision,
privatization
issue.
I
talked
about
api
versus
graphql,
first
combined,
so
thinking
about.
D
If,
if
we
agree
on
that
and
then
also
how
we
execute
against,
that
is
some
somewhere
I'd
like
to
go
next,
so
maybe
we
can
kind
of
consider
the
options
and
approaches
for
how
to
how
to
move
that
forward
and
really
start
to
break
it
down.
Does
it
does
anybody
know
if,
like
for
new
features
like
what?
What
types
of
use
cases,
if
any,
we
have
a
tendency
to
to
do
the
like
hamel
pages
thing
like
what?
What
types
of
stuff
are
we
doing
that
for
like
when
it's
green
field
yeah?
D
I
think
I
can
speak
for.
A
In
code
that
I've
seen
and
we
tend
to
build
new
features
using
graphql,
first,
okay
and
yeah,
so
we
tend
to
say:
okay,
what
does
the
front
that
need?
And
then
we
need
this
kind
of
data.
So
let's
implement
mutation
or
graphql
query
and
then
frontend
is
building
new
js
and
directly
wherever
possible
or
would
be
a
hammer
but
like
with
some
view,
review
code.
That
calls
the
api
point
and
then
sometimes
we
might
be
able.
A
You
know,
especially
front-end
teams
might
be
able
to
schedule
some
some
time
for
to
work
on
technical
depth.
So
we
some
existing
handle
templates,
actually
converted
into
view
components,
and-
and
that
means
that
we
end
up
having
a
missing
graphql
endpoint
for
the
specific
thing
so
that
that
we
used
to
have
either
the
controller
data
or
or
rest.
D
Endpoint
and
now
this
is
the
preferred
you
know,
api
format
is
graphql
so
that
we
need
to
cover
that
gap
with
graphql,
and
so
that
will
be
like
what
the
backend
will
do.
D
C
Seen
unless
there's
some
problems
with
like
a
pro
emergency,
where
maybe
the
front
end,
doesn't
want
to
wait
on
backhand
to
implement
the
graphql,
so
we
might
just
do
something
on
the
controller
directly
for
for
the
urgency
perspective,
but
like
in
general,
that
would
be
the
preferred
way
to
just
use
graphql,
okay,
so
so,
basically,
like
all
the
hammel
stuff,
where
we
do
like
a
form
post
is
usually
just
legacy
like
it.
It's
usually
just
the
case,
because
that's
the
way
it's
been
yeah
from.
C
C
Might
get
some
feature
requests
like
from
smoking.
A
new
endpoint
request
will
be
more
from
community.
Contributions
could
be
either
add
a
new
field
to
an
existing
rest
and
the
point,
or
it
would
be
anything
an
endpoint
that
does
that
and
then
they
might
submit
like
a
a
contribution
adding
a
new
endpoint,
and
in
that
case
it's
more
like.
Should
we
tell
them
to
implement
the
graphql
first,
but
then,
if
they
need
that
feature
in
rest,
that
they
don't
care
about.
Graphql,
because.
D
It's
a
community
contribution.
How
should
we
deal
with
that?
This
could
be
maybe
kind
of
connected
with
my
the
other
point
like.
Should
we
use
the
you
know
the
poc
that
alex
is
working
on
like
once,
it's
proven.
D
D
A
different
mapping,
so
that
in
that
case,
will
be
easier
even
for
new
features
that
we
say:
okay,
implement
the
graphql
and
and
have
the.
C
And
we
kind
of
move
towards
like
anything,
new
has
no
gaps,
shared
implementation
and
it
has
this
wrapping
layer
and
anything
all
this
technical
that
we
have
to
solve
either
moving
things
into
v5.
Is
there
breaking
changes
or
they
might?
We
might
have
cases
where
something
is
implemented
in
a
graphql,
but
we
don't
have
a
already
implemented
graphql,
but
we
don't
have
a
rest
in
the
point
for
that.
C
So
maybe
we
could
use
the
same
technique
where
we
make
restful
in
that
specific
path
under
b4,
and
now
we
kind
of
cover
that
gap
without
moving
to
d5
yeah.
I
think
the
v5
might
be
more
when
yeah
I
mean
I
don't
know
absolutely
if
the
aim
is
to
cover
gaps
quickly.
C
That's
good,
that's
an
effective
strategy
for
moving
forwards
without
having
to
wait
for
something
yeah,
and
I
I
absolutely
agree-
and
I
think
that
like
if,
if
the
like,
we
can
imagine
a
future
where,
when
where
all
v4
endpoints
have
been
rewritten
to
be
like
graphql
rappers,
once
we
like
work
out
all
the
kinks
right
and
then
we're
not
really
having
to
maintain
all
the
like
the
separate
implementation.
C
All
the
all
the
rest
end
points,
and
it
becomes
like
much
easier
to
like
maintain
b4
for
the
next
couple
years,
because
we're
not
really
maintaining
anything.
That's
like
different
from
what
we
intend
v5
to
be
right.
It's
just
like
opinionated
wrappers
around
that
stuff
that
that
being
said,
like
I'd,
much
like
in
the
cases
that
are
challenging
and
like
for
high
utilization
endpoints
that
have
like
very
specific
performance
characteristics
that
are
difficult
to
meet
right
now.
D
I
mean
starting
with
with
porting
existing
v4
stuff
to
graphql
is
also
a
great
way
to
do
like
the
performance
testing
that
we
need
to
make
sure
that
it
works.
Well,
I
mean
a
big
thing
that
I'm
hearing
from
this
is
a
lot
of
these
assumptions
and
it
rests
on
us
verifying
that
this
is
a
viable
solution.
So
the
sooner
that
we
can
do
that,
I
think
the
better
I
mean.
Obviously
I
have
my
own
deliverables
and
stuff
to
do.
D
I
have
very
happy
to
work
on
on
this
as
a
proof
of
concept
to
try
and
get
something
that
we
can
test
production
out
at
some
point,
but
it'd
be
nice
to
verify
that.
That's
something
that
we
think
is
a
priority
and
to
prioritize
that,
as
as
as
a
key
to
unlocking
all
these
other
strategies,
because
if
that's
not
if
it
doesn't,
if
there
are
in
fact
other
things
that
are
problematic
there
and
that
will
change
all
these
other
discussions.
D
Yep,
that's
a
fair
point.
So
just
just
to
kind
of
summarize
it
sounds
like
of
course.
Let
me
say:
prerequisite
here
is
validating.
D
D
D
E
A
That
we
stop
the
bleeding
in
terms
of
the
divergence
of
the
two
implementations
right
yeah.
So
before
we
cut
b5
we
we
will
implement
new
endpoints
using
the
wrapper
in
v4.
As
you
see,
I
I'm
assuming
v5
will
have
some
kind
of
larger
considerations.
You
know:
do
we
use
sparse
field
set?
Maybe
would
we
implement
the
building
documentation
with
it?
This
is
a
kind
of
a
larger
kind
of
scope.
Yeah.
Absolutely.
D
D
Okay,
so
I
think
I
need
to
just
flip
it
around,
essentially
as
we're
adding
new
features
or
new
endpoints
make
sure
that
they're
added
to
graphql
first
stop
the
bleed.
We
gotta
validate
the
poc
to
make
sure
this
is
a
feasible
solution
and
then
we'll
continue
to.
C
Solve
explore
the
v5
approach
define
that
before
we
start
to
build
any
any
new
technology
there,
but,
but
I
think
also
like
we're
saying
after
we
validate
the
poc,
that
we
would
also
go
graphql
first
right
because
right
in
order
for
new
endpoints
and
v4
to
be
defined
on
top
of
the
graphql
api,
you
have
to
implement
it
in
graphql.
First,
okay.
I
think
this
aligns
largely
with
what
I
have
in.
E
C
D
C
In
that,
in
that
issue,
let's
retool
it
and
I
think,
what's
there,
we
could
start
to
push
into
a
blueprint
page
for
how
we
want
to
move
forward
in
terms
of
like
api
vision.
So
yeah
take
a
look
at
that.
I
think
that
lines
up.
A
A
I
think
we're
quite
close.
I
mean,
I
think,
the
same
ideas
keep
being
mentioned
again
right,
so
sparse
field
sets
being
able
to
include
related
related
relation
associations,
automatic
document
generation.
D
Json
api
conformance,
open
api,
schemas.
D
A
What
that
is,
and
then
we,
when
we
build
forwards,
everything's,
going
to
be
conformed
to
that
we're
going
to
have
nice
and
we
can
just
we
can
the
sooner
we
can
define
what
that
is
the
sooner
we
can
start
building
up
just
a
guy
endpoint
under
v5
yeah,
great
yep.
I
think
that
makes
sense,
so
I
wanted
to
jump
back
up
to
three
before
we
we
closed
out
today.
I
think
one
thing
I
am
seeing:
that
is
a
gap
in
this
issue.
Right
now
is
kind
of
how
we
go
about
executing
it.
A
You
know
what
are
some.
You
know
tactical
steps
we
need
to
take.
I
think
we
talked
just
just
a
little
bit
about
the
you
know
the
poc
for
rest
over
graphql
or
reason.
So
that's
that's
a
clear
actionable
step.
I
think
we
can
start
like.
E
You
were
asking
alex
to
see
how
we
can
get
those
prioritized
teams
to
participate,
so
I'll
make
note
of
that
and
see
how
we
can
how
we
can
start
to
to
get
some
engagement
there.
But
another
thought
too,
is
if,
if
we
are
looking
at
motivating
teams
or
defining
some
best
practices
for
being
api
first
or
graphql
first,
I
don't
think
that
we've
gotten
too
far
into
exploring.
How
do
we
actually
do
that,
which
is
where
I
was
asking
some
questions
and
marshall.
E
You
raised
the
same
question
as
like:
where
are
some
cases
where
we're
not
already
doing
that?
But
that's
something
I'd
like
to
explore
a
little
bit
further
is
how
do
developers
make
decisions
when
they're
building
new
features
and
what
cases
are
there
that
we're
not
using
apis
to
start.
A
With
or
when
do
we
choose
rest
first
and
how
do
we
start
to?
Actually,
you
know
make
some
changes
to
our
documentation
or
best
practices
or
are
there?
Is
there
tooling
that
we
need
to
provide?
I
think
this
poc
is
part
of
that,
but
is
there
more
that
we
need
to
provide
to
developers
to
essentially
define
like
a
golden
path
or
best
practice?
A
A
That
alex
has
created
on
on
the
graphql
query
right
like
we
should
get
to
a
state
where,
like,
if
you
you,
the
assumption
is
that
you
implement
the
graphql
endpoint
first
and
then,
if
you
just
follow
the
conventions
that
are
laid
out
in
that
poc
you're
you're
good,
like
that,
is
the
golden
path
and,
and
you
get
automatic,
open
api
schema
generation
and
you
get
a
wrist
layer
and
a
graphql
layer.
A
I
I
think
the
one
question
we
haven't
answered
is
like:
is
there
ever
an
instance
where
you
should
not
create
a
graphql
endpoint?
I
think
that
it's
probably
the
case
for
like
file,
uploads
and
stuff
like
that,
but
aside
from
yeah
well,
we
do
support
file
uploads
with
graphql
the
real
problems
that
you
file
downloads.
So
things
like
the
ci
trace
exports
so
streaming
large.
Large
binary
responses
is
actually
the
biggest
issue
yeah
but-
and
I
think
that's
intuitively
obvious
to
most
folks,
like
you
know,
there's.
D
D
Yeah?
That
was
basically
the
question
I
was
posing
to
fabio
and
and
and
generally
like
for
new
stuff.
Do
we
ever
see
that
pattern
taking
place
and
based
on
what
I've
seen
based
on
what
fabio
just
said,
the
answer
is
no
that
we
don't
develop
new
features
that
way
like.
I
think
we
just
need
to
say
that
we
don't
and
then,
if
there
are
cases
where
we
still
need
to
for
some
reason
like
we
handle
that
on
a
case-by-case
basis,
but
it's
pretty
safe
to
say
that
in
general
we
should
never
do
it.
E
It's
with
in
sort
of
the
medium
to
far
future,
I
know,
there's
talk
about.
Is
there
should
we
move
to
more
towards
the
rail
7
pattern
of
doing
more
of
the
sort
of
the.
D
Hot
wire
style
of
html
over
it's
more
more
static,
more
static,
html
generation,
also
also
for
rendering
more
hot
wire
based
communication.
A
Which
actually
ends
up
being
less
apis
stuff,
because
it's
all
it's
all
in
the
rainbows
app?
Oh,
and
if
you
move
towards
that
sort
of
that
embracing
that
rails
pattern
in
the
future,
that
might
there
might
be
some
tension
there
about
where
we
place
functionality.
D
I
mean,
as
marshall
mentioned,
I
think
you
if
you
can
actually
rewrite
your
internal
services
and
actual
operations
in
terms
of
graphql,
which
you
call
internally
anyway,
so
you
can
still
go
through
that
single
pipeline
if
you
want,
but
it's
worth
bearing
in
mind
that
that's
something
that
is
happening
in
rails
at
the
moment
yeah.
This
was
with
just
being
aware.
D
And
I
guess
one
last
question:
I'm
kind
of
curious
on
the
integrations
team.
Do
we.
E
One
area
that's
kind
of
intermediate
as
webhooks,
which
isn't
really
well,
because
it's
it's
high
structure,
as
it
is
something
we
post
about
to
other
people
and
other
people
to
us.
It
isn't
well
defined,
as
we
mentioned
previously
things
like
versioning
of
and
schemas
for
workbooks
and
things
like
that.
But
it's
not
entirely
sure
where
it
sits
in
this
framework.
E
It
okay!
Well,
I
know
we're
a
little
bit
over
time,
so
I
won't
go
much
further.
I'll
make
a
note
of
this
last
bullet
yeah.
I
think
there
are
a
number
of
issues
still
out
there
that
are
stale
would
be
great
to
have
some
more
participation
across
the
team
across
all
of
the
folks
in
this
group
in
the
working
group.
A
E
All
right,
if
we
didn't
touch
anything
here,
feel
free
to
read
through
the
notes.
There
might
be
a
few
bullets
that
we
didn't
dive
into
deeply,
but
thanks
everyone
for
your
time
and
participation.
This
is
great.