►
From YouTube: Why Your APIs Should Fly First Class
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
So
a
little
bit
of
an
agenda
who
I
am,
what
is
an
api
first
mentality,
how
we
build
apis
first,
a
build
for
two
concept
that
I
have
kind
of
worked
out
myself
over
my
engineering
career,
some
tools
and
tricks
for
api
first
mentality,
and
then
we'll
finish
this
up.
We'll
answer
some
questions
so
who
am
I
my
name?
Is
robert
ross
people
like
to
call
me
bobby
tables?
I
am
the
co-founder
and
ceo
of
fire
hydrant.
A
We
are
an
incident
management
platform
and
tool,
I'm
bobby
tables
on
twitter,
bobby
tables
on
github
tables.
You
know
every
pretty
much
everywhere,
with
sometimes
a
hyphen
and
sometimes
an
extra
underscore.
A
So
an
api
in
this
talk
is
going
to
be
a
rest
api
accessed
via
http
application,
programming
interface,
we're
not
talking
about
like
the
low
level
abstractions
within
code
and
how
you
know
our
software
talks
to
itself
and
then
we're
also
going
to
be
using
the
word
actor
quite
a
bit
throughout
this
conversation,
and
that
is
going
to
refer
to
a
person,
an
integration
or
really
just
anything,
doing
anything
in
our
application
performing
actions
and
finally,
a
front
end
is
a
javascript
application
that
is
talking
to
your
api.
A
So
we
live
in
a
world
where
we
have
angular,
ember
react,
redux
and
a
whole
bunch
of
others
out
there.
Still
that's
what
we're
talking
about
we're
talking
about
that
that
javascript
app
that's
talking
to
a
backend
api,
so
with
the
terms
all
set
up
here.
Let's
talk
about
the
front
end.
First,
the
front
end
matters
more
than
ever
actually
in
in
many
ways,
so
dynamic,
front-end
experiences
are
extremely
valuable
and
expectation
from
customers.
A
It.
We
think
that
it
comes
from
experiences
with
facebook,
netflix
and
other
large
tech
firms,
the
fangs
of
the
world,
with
the
resources
to
really
be
able
to
invest
in
these
complex
front-end
architectures.
It
is
not
easy
to
build
what
what
facebook
has
built
and
what
google
and
netflix
have
built.
It's
it's
a
single-page
application
in
many
ways
with
heavy
javascript
usage
talking
to
these
back-end
apis,
graphql,
json
grpc,
and
that's
a
really
really
heavy
investment
that
they
have
made
into
these
technologies.
A
Facebook
released
react
based
on
these
experiences
and
it
that
a
dynamic
front-end
experience
gives
the
same
sense
of
quality
that
a
good
thud
of
a
car
door
gives,
if
you've
ever
you
know,
closed
the
door
of
an
expensive
european
car.
It
has
a
really
nice,
like
bassy
thud
to
it,
and
it's
what's
interesting.
This
is
actually
a
science.
A
It's
actually
faked
in
many
ways
for
a
lot
of
cars,
so
in
the
1980s
cars
were
built
and
they
had
that
natural
thud
and
it
gave
people
the
sense
that
that
car
was
safe
and
and
high
quality,
and
now
they
a
lot
of
companies
actually
have
audio
scientists
working
on
the
thud
sound
of
a
car
door,
and
it
makes
it
gives
the
perception
of
a
sturdy
valuable
car.
A
No,
I'm
not
saying
on
a
front-end
experience
can
needs
to
be
faked
or
a
front-end
experience
can
give
the
sense
of
a
better
experience,
but
it
can
in
some
cases,
and
it
can
be
perceived
as
a
much
more
valuable
and
well
thought
out
product.
A
It's
kind
of
a
sad
reality.
If
you
think
about
it.
If
your
website
just
doesn't
have
a
particular
type
of
fancy
sizzle
to
it,
customers
may
think
that
it's
cheap.
So
a
website
like
this
might
provide
a
ton
of
value
six
ways.
My
parents
taught
me
financial
independence,
that's
super
valuable,
but
if
we
look
at
this
website
and
like
the
wordart
logo,
it
you
know
you
kind
of
lose
that
sense
of
value
of
value
and
quality.
A
A
dynamic,
front-end
experience,
however,
is
a
risk
and
fire
hydrants.
My
my
goal
is
to
not
speak
too
much
about
fire
engine,
but
we
will
use
ourselves
as
an
example.
We're
a
young
company
we're
about
two
and
a
half
years
old,
and
we
you
know
we
were
thinking.
A
Do
we
move
this
chess
piece
early
do
do
we
go
and
invest
in
a
dynamic,
front-end
experience
in
the
earliest
days
of
our
business
and
after
two
and
a
half
years
and
after
working
at
companies
like
digitalocean
and
namely
I've
come
to
the
conclusion
that
you
should
move
this
chess
piece
early.
It
is,
you
should
always
start
building
an
api
first
with
a
dynamic
front
end.
A
So
the
better
we
made.
We
made
a
bet
in
the
first
days
of
fire
hydrant
to
build
an
api
for
everything.
Since
then,
we've
amassed
over
130
public
api
endpoints
in
just
over
two
years.
That's
a
lot!
That's
a
lot
of
api
endpoints.
We
we
built
a
react.
Redux
front
end
from
day
one
we
we
have
some.
You
know
html
rendered
views.
We
are
rooted
on
rail
shop.
There
are
a
few
that
are,
you
know,
choice,
but,
for
the
most
part,
all
of
our
application
is
a
react.
A
Redux
application,
every
feature
that
that
fire
hydrant
exposes
in
the
ui
actually
has
an
underlying
api
that
our
customers
can
integrate
with
as
well
so
said
differently.
Our
customers
can
use
all
the
same
apis
that
we
use
for
ourselves,
and
that
was
a
very
conscious
decision
that
we
made
as
a
business
for
the
long
term
of
our
platform,
because
an
early
goal
of
fire
hydrant
was
to
be
an
integration
platform,
and
what
that
means
is
that
everything
our
platform
can
do.
A
Our
customers
can
also
programmatically
integrate
with
us
and,
if
you're
building
an
api
really
is
you
want
people
to
be
able
to
programmatically
integrate
with
you
unless
you
have
some
like
weirdos,
that
want
to
read
json
instead
of
like
a
beautifully
architected
page,
but
I
doubt
that
that's
not
that's,
usually
the
case,
but
it
also
meant.
It
also
meant
that
we
had
to
consider
our
api
design
earlier
apis.
A
They
can't
change.
If
someone
programmatically
is
interfacing
with
your
api,
you
can't
pull
it
out
from
under
them
and
change
the
schema
or
remove
it
or
you
know,
do
certain
things
to
it
that
would
break
their
implementation.
They've
spent
a
ton
of
time
integrating
with
you,
don't
don't
do
that
to
them
and
that's
actually
challenging
as
a
startup,
because
we're
moving
fast.
We
want
to
move
fast.
How
do
we
move
fast
with
an
api
that
can't
change?
A
It
actually
means
you
have
to
consider
a
lot
of
things
very
early
in
the
application
design
of
the
company
and
then
another
thing
that
it
actually
changed
is
our
database
design.
Our
api's
first
mentality
meant
that
we
had
to
start
accompanying
for
different
actors.
So
remember
person,
thing
integration,
all
types
of
actors
that
can
integrate
with
our
api.
Our
database
had
to
change
just.
A
In
the
earliest
days-
and
we
also
again,
we
built
a
front
end
accessing
our
api
from
the
start,
this
created
the
need
for
a
well-defined
engineering
roles
early
on
fire
hydrant.
While
we
have
people
that
can
operate
full
stack,
we
actually
don't
hire
full
stack
engineers.
We
explicitly
hire
people
for
the
front
end
or
the
back
end,
and
for
some
companies,
that's
scary,
it
is
you
want
that
person
that
can
do
everything,
but
we
want
those
specialists.
A
A
Initially,
the
benefit
actually
of
having
that
api
early
will
almost
always
exceed
the
initial
cost
by
orders
of
magnitude.
Yes,
you,
you
are
going
to
spend
more
money,
building
it
back
and
building
a
front
end
separately
that
talk
to
each
other,
that
that's
not,
I'm
not
a
ignorant
to
that
fact.
But
if
you
want
to
build
a
mobile
app
and
then
release
it
and,
let's
say
you're
thinking,
this
is
two
years
away.
A
Well,
do
you
want
to
build
the
api
in
two
years
separately
and
like
staple
it
on,
or
do
you
just
want
to
have
it
now
have
people
integrating
with
it
and
then,
when
you
go
to
build
your
mobile
app,
it's
it's
there,
customers
that
integrate
with
you
are
also
way
less
likely
to
churn
and
from
a
business
pure
business
point
of
view.
That's
that's
very
valuable.
It
is
hard
to
it's
much
harder
to
get
new
customers
and
to
retain
existing
ones.
A
There
is
a
lot
of
reasons
why,
like
building
an
api
and
saying
it's
expensive,
is
just
not
a
good
argument
in
the
long
run,
it's
time
consuming,
it
is,
but
for
us
we
kind
of
sat
down
and
we
said
like
well.
We
we
have
a
lot
of
faith
that
this
is.
A
This
thing
is
gonna
work
and
these
features
and
this
product
and
this
company
are,
is
gonna
work,
let's,
let's
add
to
our
risk,
we're
gonna
increase
our
risk
profile
and
just
you'll
spend
more
time
we're
going
to
spend
more
time
we're
going
to
build
an
api.
If
this
doesn't
work
out,
you
know
it
doesn't
work
out,
but
we're
around
we're
two
and
a
half
years
old.
A
We
are
here
to
stay
and
because
we
made
that
bet
early
on
where
we
have
so
many
people
that
now
integrate
with
us
and
are
happy
with
those
integrations
that
we
can
actually
say
that
that
was
that
was
the
right
move
to
take
so
api.
First,
I've
said
it
a
couple
times:
what
what
does
that
mean,
and
literally
it
means
don't
build
a
user
interface
until
you
have
an
api
literally,
that
sounds
insane
right.
How
can
you?
How
could
you
possibly
do
that?
A
Well,
here's
here's
a
to
kind
of
think
of
this.
Your
api
should
be
a
bin
of
legos
on
the
right.
This
is
a
pretty
awesome
lego
ad
from
years
ago,
print
ad,
where
it's
you
know
it's.
It's
kind
of
using
like
the
child's
imagination,
like
sure
it's
two
lego
bricks,
but
to
the
child.
That's
an
airplane
and-
or
you
know
adult
like
me,
who
still
has
legos
and
still
plays
with
them.
A
But
the
point
here
is
that
when
you
provide
an
api
with
all
these
really
really
well-defined
api
endpoints,
that
can
you
know,
attach
to
each
other
really
nicely
and
have
nice
standards
and
are
very
sturdy
and
solid.
You
can
actually
start
building
that
airplane
and
have
the
imagination
to
build
whatever
you
want
with
the
given
ingredients,
and
one
of
the
problems
that
you
kind
of
have
to
avoid
here
is
when
you
start
mixing
your
ui
with
your
behavior.
A
Your
application
should
have
your
application
will
have
a
very
hard
time
becoming
a
platform
for
others
to
integrate
with.
If
you
have
this
mixed
mindset
of
behavior
and
ui,
there
are
fundamentally
different
things
and
when
behavior
is
exposed
via
an
api
actors,
internally
or
externally
can
start
to
imagine
a
ui
for
themselves.
A
I
know
that
that's
what
I'm,
maybe
that
could
be
interpreted,
but
really
it's
a
breakdown
of
how
we
build
an
end
result
for
our
customers
and
I'd
wager
that
if
you're
in
this
talk
that
you
know
you're,
probably
one
a
part
of
a
company
that
does
something
similar
to
this
workflow-
and
you
know
if
you're
part
of
agile,
scrum
extreme
programming
whatever
it
is.
You
have
some
level
of
product
planning,
your
future
specification,
wireframes
acceptance
criteria
and
the
why
you're
building
it
if
you're,
actually
at
a
very
mature
organization.
A
That's
a
really
important
thing
to
include
writing
a
story.
Kind
of
comes
next
might
come
from
you,
a
project
manager,
product
manager.
It
goes
in
clubhouse
or
jira,
and
you
know
it
goes
there
to
be
planned.
And
then
you
have
an
iteration
planning
meeting.
You
have
some
assignment
given
when
then
and
then
engineering
goes
and
builds
that
feature
and
after
engineering
has
taken
wireframes
design
the
acceptance
criteria,
they
write
a
bunch
of
code,
they
ship
it
and
then
marketing
delivers
to
customers.
We
get
an
announcement,
you
move
on.
A
A
So
some
of
the
subtle
differences
in
the
process
break
down
here
to
build
an
api.
First,
you
have
to
have
a
different
feature
to
composition,
so
we
have
feature
teams
at
fire.
Hydrant
and
one
of
them
is
our
integrations
team.
We
have
ux
ui
design,
we
have
jax,
we
have
front
end
engineering,
we
have
hillary,
we
have
product
manager,
dylan
and
we
have
back
end
engineering
justin,
and
then
we
also
have
a
concept
of
we
have
our
our
site,
reliability,
engineers
and
they
kind
of
float
around
between
the
teams
they
have.
They
have
mixed.
A
You
know:
responsibility
of
site,
reliability
as
a
whole,
and
so,
with
this
composition
of
a
team,
what
we
do
is
we'll
have
jax
work
with
fun
and
jax
will
make
a
great
design,
and
this
is
from
a
real
feature.
This
is
an
actual
breakdown.
These.
These
are
real
screenshots
from
how
we
broke
down
a
feature
of
ours,
recently
called
run
book
templates
and
what
jax
did
is
she
used
figma
to?
Basically,
this
is
this
is
what
the
information
is
going
to
be
displayed.
This
is
how
it's
going
to
be
organized.
A
You
know
this
is
the
beginnings
of
the
feature
and
you
can
use
a
sharpie
right.
You
could
do
this
on
a
whiteboard,
that's
okay,
just
presenting
the
information
in
some
way,
at
least
like
with
the
information
that
you're
going
to
display.
That's
the
most
important
piece
of
this
because
once
you
know
what's
going
to
be
on
the
page,
you
can
start
to
kind
of
figure
out.
Okay,
well,
that
starter
template
over
here,
that's
going
to
need
an
api.
A
A
Is
we
created
a
ticket
in
clubhouse
to
basically
represent
the
information
and
the
api
that
would
need
to
be
created
to
build
this
page
so
dylan
and
justin
and
another
one
jp,
were,
you
know,
wrote
this
out
and
worked
on
it,
and
what
happened
is
that
back-end
engineering
was
able
to
deliver
a
api
endpoint,
so
the
api
endpoint
actually
came
asynchronously
to
the
front-end
work,
and
this
is
nothing
mind-blowing,
but
this
is
really
just
how
we
think
of
our
apis
and
how
we
build
them
and
why
we
do
it
because,
what's
going
on
while
this
api
was
being
built
is
the
front
end
was
also
being
built,
and
so
hillary
is
working
on
the
you
know
the
starter
template
page,
where
she
knows
that
I'm
about
to
have
an
api
once
the
api
has
released,
we're
able
to
kind
of
mesh
the
gears
together
and
then
we
lo
and
behold,
we
have
a
create
new
runbook
page
with
templates.
A
Then
obviously
there's
a
whole
bunch
of
other
api
endpoints
that
go
into
this,
but
you
get
the
general
idea
of
how
we
break
down
our
our
builds.
A
So
why
is
this
better?
It's
not
much
different
right.
Why
is
it
better
building
an
api?
First,
it
is
a
forcing
function
if
this
process
would
never
work.
Unless
every
person
on
that
team
is
on
the
same
page,
things
would
break
down
very
quickly
because
you're
trying
to
mesh
gears
here,
you're
trying
to
measure
backhand
and
a
friend
amongst
many
people,
it
forces
you
to
all
be
on
the
same
page,
pointing
in
the
same
direction.
A
Now
we
designed
our
featured
teams
to
be
very
tight-knit
in
order
to
ship
back-ends
and
front-ends
asynchronously.
We
do
use
storyboard
out
of
airbnb's
engineering
team
that
allows
us
to
kind
of
plug
in
what
the
the
shape
of
the
api
will
be
early.
So
we
can
actually,
you
know,
continue
the
progress,
even
if
an
api
isn't
actually
done
yet,
and
this
points
every
one
of
the
feature
team
in
the
same
direction.
That's
very
important.
A
It
also
creates
interfaces
that
your
customers
can
now
interface
with
a
platform
that
people
can
integrate
with
means
tighter
customer
bonds.
Again,
if
you
have
someone
that
has
spent
the
time
to
programmatic,
like
write
code,
paying
that
high
high
salaried
employee
to
write
code
against
your
api,
that
customer
is
much
more
likely
to
hey,
be
happy
and
be
like
less
likely
to
leave
you
it's
just
a
better
way
of
you
know:
delivering
value
to
customers
that
are
really.
You
know,
forward
thinking
and
willing
to
integrate
with
you.
It
generates
conversations.
A
We've
also
noticed
this
amongst
the
team
that
would
never
otherwise
happen.
You
really
have
to
start
thinking
about
the
information
on
that
screen.
It's
really
easy
for
someone
to
go
off.
If
it's
an
individual
full
stack,
that's
going
to
be
the
front
end
and
the
back
and
our
ui.
A
A
Api
is
meant
for
computers.
So,
while
a
user
will
make
a
request,
your
api
from
your
front
end,
you
must
account
for
other
actors.
So
that
means
that,
typically
in
an
api,
you
you
make
a
request
to
the
api.
Maybe
it
creates
some
data,
a
note,
a
comment
whatever
it
might
be:
that's
usually
associated
to
a
user
and
a
user
only
that's
how
a
lot
of
apis
work.
That's
how
jira's
api
works.
That's
how
salesforce's
api
works.
A
It's
a
very,
very
common
pattern,
but
that's
a
problem
actually,
because
when
you
act,
when
you
only
have
access
to
your
api,
like
that
it
actually
changes,
it
really
restricts
the
the
integratable
way.
A
You
have
to
accommodate
for
multiple
types
of
actors
against
an
api,
and
you
have
to
build
in
authentication
and
authorization
modes
that
allow
for
both
people
in
programs
to
you
know,
have
a
merry
world
together.
Your
underlying
data
model
needs
to
change
to
support
this
idea,
so
some
considerations,
your
data
model
when
you're
building
apis
first,
your
data
model
needs
to
support
the
idea
of
multiple
actors
creating
and
modifying
data.
It
has
to
do
this
most
systems
in
my
career
and
out
in
the
wild.
They
have
this
concept
of
a
god,
object,
the
user.
A
Everything
has
an
association
to
the
user
that
needs
to
change.
If
you're
going
to
build
an
integratable
platform,
because
not
users,
people
creating
data
all
the
time
now
we
have
integrations
creating
data.
How
do
you
associate
to
an
integration
when
your
entire
data
model
is
only
pointed
at
the
user
record?
It
it's
not
possible.
You
have
to
break
this
down,
so
what
I
recommend
is
you
can
use
polymorphism
or
a
single
entity
with
a
type
key
on
it
to
achieve
this.
So,
let's
break
those
down.
A
This
is
firehegen's
data
model.
Again,
we
have
multiple
concepts
of
vectors
users,
integration
spots
and
what
we've
done
is
we've
made
our
database
schema
heavily
polymorphic
heavily
heavily
heavily
polymorphic.
This
allows
us
to
store
multiple
actor
types
on
records,
such
as
an
incident.
We
are
an
incident
management
platform,
so
this
is
a
snippet
from
our
database.
A
Actually,
this
is
you
know
if
you
want
to
build
part
of
the
incidence
table
for
fire
hydrant,
here's
here's
part
of
it,
so
this
is
creating
a
table
called
incidents
in
post
press
and
at
the
bottom.
Here
you
can
see
these
orange
bolded
keys,
columns
created
by
type
and
created
by
uid.
A
Now.
The
difference
here
is
that,
on
a
lot
of
databases,
you
would
only
have
created
by
user
id
and
that's
a
single
id,
and
that
ties
to
a
user
record.
But
what
we're
doing
is
we're
actually
having
this
type
column,
to
be
able
to
say
it's,
the
id
of
an
integration,
an
id
of
a
bot
or
an
id
of
a
user.
A
So
when
someone
creates
an
incident
against
our
api
post
v1
incidents,
maybe
they
are
acting
on
our
api
as
a
bot
and
what
we
do
is
we
say?
Oh,
it's!
It's
the
bot,
that's
authenticated
against
the
api
right
now
and
they're,
creating
an
incident,
and
when
we
create
the
incident
we
say
well,
the
bot
created
it,
not
this
user,
and
that
is
you
know.
This
is
one
way
that
you
can
start
to
introduce
multiple
actors
in
that
concept
of
build
for
two.
A
When
you
start
to
build
for
two,
you
get
to
build
for
many,
it's
just
a
way
of
thinking.
You
don't
have
to
build
it
explicitly
for
two.
That's
that's
not
what
I'm
saying,
but
I'm
saying
break
out
of
the
idea
that
items
are
associated
to
only
one
thing
is:
it
is
a
change
that
will
fundamentally
make
your
software
more
flexible
in
the
future.
A
I
wanted
to
present
an
alternative
data
model
so
at
fire
again,
we've
been
doing
this
data
model
for
a
long
time
and
we've
had
some
ideas
on
you
know.
What
would
we
do
different
and
I'd
actually
propose
this
nowadays
hindsight.
I
I
think
this
is
actually
better.
You
know,
there's
trade-offs
to
both,
but
and
they
both
work
and
accomplish
the
same
thing,
but
for
the
purposes
of
a
talk
and
making
sure
that
people
come
away
with
something
interesting,
I
would
do
it
this
way
now.
A
I
would
actually
have
an
actor's
record
in
my
database,
that's
extremely
simple,
and
then
what
I
would
do
is.
I
would
actually
make
all
of
my
other
associations
point
to
the
actor
and
then
what
I
would
do
is.
A
I
would
make
the
actor
record
a
polymorphic
thing
and
the
reason
you
would
do
that
is
that
it
actually
cleans
up
your
database
to
the
point
where
incidents
instead
of
having
two
columns,
they
can
have
actor
id
runbook
can
have
created
by
actor
id,
and
if
you
need
to
know,
if
you
really
need
to
know,
was
it
a
user
that
created
or
bought
or
an
integration
you
you
still
have
that
foreign
key
association,
so
it's
a
little
simpler,
a
little
bit
more
flexible
because
you
can
continue
to
add
different
types
of
actors
up
here
easily.
A
So
you
know
just
a
proposal
if
you
are
getting
something
out
of
this
talk
so
far,
I
would
I
would
actually
build
it
this
way
now,
if
I
were
starting
over,
but
both
of
these
unlock
say
the
same
things
so
on
the
right
side.
This
is
a
view
from
our
application.
It's
a
timeline.
We
store
a
timeline
during
an
incident.
So
when
you
go
into
a
retrospective,
it's
just
readily
available
for
you,
so
you
can
now
separate
the
type
of
actors
in
your
application
with
these.
A
Not
everyone
is
a
user
anymore
and
that
unlocks
some
cool
things.
So,
if
you
see
we
can
this,
I
represent
that
daniel
conomitti
is
a
fire
hydrant
user,
but
this
information
was
actually
added
by
a
slack
user,
so
different
types
of
actors
integrating
in
the
same
feature
because
of
this
data
model.
It
supports
this.
A
If
our
data
model
associates
everything
to
a
user
via
the
api,
what
happens
when
that
person
leaves
the
company?
This
is.
This
is
a
caveat
right.
All
of
your
integrations
that
you
built
with
that
user's
account,
also
break
if
you
think
like.
Oh,
if
we
have
a
software
engineer
that
built
all
of
our
integrations
and
that
software
engineer
gets
an
offer
to
know
the
company
and
they
leave,
we
deactivate
their
account,
and
that
means
all
the
integrations
down
here
also
break
because
the
api
is
requests.
A
A
Another
concept
that
comes
in
the
build
for
two
arena
theory
is
you
want
to
allow
for
many
and
constrained
to
one,
and
what
I
say
here
is
like
think
two
features
ahead.
It
doesn't
mean
that
you're
gonna
over
engineer
something
or
over
plan,
but
it's
okay
to
entertain
a
feature
that
could
plot
like
plausibly
be
built
in
the
future.
Possibly,
I
think
that's
a
word,
but
a
golden
rule
is
it's
okay
for
an
array
to
have
one
element
in
it
in
your
api.
A
I
know
that
sounds
crazy,
but
if
you're
building
an
api-
and
you
have
one
association-
and
you
go-
I
just
I'll
just
have
the
one
association.
You
just
add
it
to
your
api.
Keep
in
mind
your
api
can't
change
it's
okay
to
have
an
array
with
one
element
in
it
and
I'll
show
you
an
example
of
how
that
has
bitten
me
in
the
past.
A
But
it's
a
common
mistake
to
restrict
your
json
schema
to
a
singular
object
and
then
later
on,
you
add,
you
need
to
add
another.
It's
much
easier
to
constrain
the
one
in
code,
but
allow
for
multiple
in
your
database.
Databases
are
very,
very
very
hard
to
change
it's
hard
to
change
a
database
schema.
It
is
way
easier
to
allow
for
many
in
your
database
and
constrain
to
one
of
your
code
code
is
way
cheaper
to
change.
A
A
I
was
responsible
for
all
types
of
apis
internally
externally,
a
lot
of
responsibility
for
how
people
integrated
with
with,
namely-
and
this
is
a
story
about
where
build
for
two
would
have
saved
me
a
headache
at,
namely
so,
if
you
work
at
a
company
today,
you're
sitting
there,
you
probably
have
a
manager
and
logically
you
think
I
only
have
one
manager
and
you
would
be
right
most
of
the
time.
A
A
So
you
know,
if
you
think
about
it,
namely
hr
company.
We
store
your
manager,
your
dotted
line
reports.
We
store
all
this
information
and
started
the
api
that
exposed
who
a
person
reported
to
so
api
endpoint
of
the
profile.
So
we
can
see
here.
This
is
an
id
of
a
profile,
the
email
of
that
person
and
who
they
report
to
so
id122.
A
A
Well,
what
happens
if
we
would
have
built
this
for
two,
so
the
json
only
supports
one
reports,
two
field,
even
though
the
product
now
supports
multiple
reports
to
be
adopted
line
managers-
maybe
my
colleague
dan,
is
also
requires
my
attention
and
is
holding
me
accountable
to
things.
He
is
a
dotted
line
manager
of
mine.
A
How
do
I
report
that
in
my
api,
so
the
situation's
a
worst
case
scenario,
because
if
our
json
apis
can
change,
we
built
this
api
and
people
started
integrating
with
it
almost
immediately
and
we
can't
change
it
without
a
heavy
notice
or
complete
deprecation
of
that
key
in
that
api
endpoint.
It
is
a
lot
of
work
and
time
to
do
that.
A
We
could
have
avoided
this
if
we
just
thought
like
a
couple
of
features
ahead.
If
we
just
had
a
discussion
about
reporting
structures
and
all
that
like
we,
we
could
have
potentially
avoided
this
reports
could
have
been
an
array
it
could
have
been
okay.
The
first
element
of
this
array
is
dylan
and
then
the
second
element,
if
if
this
happens,
is
daniel
with
a
type
key
called
dotted
line,
the
this
is
better
because
it
means
that
people
that
integrated
with
our
api
don't
have
to
change
their
clients.
A
It
works
the
same
exact
way
and
and
that's
why
I
think
people
really
should
start
considering,
like
think
two
features
ahead.
You're
you're
not
gonna
over
engineer
something
to
the
point.
If
you
think
two
features
ahead
with
some
level
of
credibility
that
something
will
be
coming
up.
A
So
what
have
we
built
for
two?
I
mean
these
opinions
are
mostly
from
putting
my
hand
on
a
hot
stove
over
the
last
10
years.
I
know
I
look
like
I'm
a
teenager,
but,
like
this
is
a
lot
last
10
years
early
decisions,
don't
always
have
to
be
gonna,
go
fast
mentality,
they
don't.
You
can
often
build
a
model
that
will
last
you
for
years.
If
you
think
two
features
away
I.e
what
if
we
may
have
users
now,
but
will
we
have
companies?
A
There's
a
really?
I
don't
know
if
it's
still
out
there,
but
github
has
a
story
about
this.
Github
used
to
be
only
users,
and
then
they
introduced
the
concept
of
organizations.
It
took
github
nearly
a
year
to
support
that
concept,
not
because
creating
organizations
was
hard
but
being
able
to
associate
users
to
organizations
was
hard.
A
A
So
some
tools
and
tricks
to
deliver
great
apis
document
in
tandem.
So,
while
we're
building
your
apis
at
fire
hydrant,
we
actually
document
our
apis
in
the
code
that
is
powering
them.
So,
while
you're
building
your
api,
please
oh
please
document
it
as
you
go.
No
one
wants
to
go
back
and
document
100
api
endpoints.
No
one
use
the
open
api
specification
too.
So
swagger
swagger.io
it
will
allow
you
to
standardize
your
documentation
as
well
as
generate
clients
generate
documentation.
A
It's
just
it's
a
good
standard
to
just
kind
of
follow,
also
called
the
open
api
initiative.
Again
we
are
a
ruby
ruby
on
rails,
core
application.
We
have
some
go
applications.
You
know
scattered
around
too,
but
use
something
that
plugs
into
your
framework
that
can
generate
open
api
specs
for
you.
We
use
great,
been
using
grape
for
a
very
long
time.
A
It
is
the
api
endpoint
framework
that
we
use,
and
then
we
use
great
swagger,
which
can
read
our
api
document,
read
our
api,
specs
and
grape
and
actually
generate
beautiful,
open
api
spec
compatible
json.
So
really,
you
know
try
to
do
this
early
if
you're,
not
if
you
have
an
api
already
like
please
take
the
time,
go
back
document
those
api
endpoints
with
with
swagger.
A
It
really
will
be
a
better
experience
for
and
even
yourself.
Actually,
if
you
integrate
your
against
your
own
apis
so
getting
towards
the
end
here,
documentation
hosting
so
light,
stop
lights,
actually
sponsoring
this
conference.
They
are
not
sponsoring
me.
There
are
a
few
options
out
there
for
api
documentation,
but
I
personally
I
recommend
stoplight
and
prefer
it
they
can
read
open
api.
Spec
they've
done
a
nice
job
of
that
they've
been
doing
it
for
a
long
time,
use
it,
namely
as
well.
A
They
can
generate
nice,
try
it
pages
for
every
endpoint,
it's
just
a
really
kind
of
nice
product.
It
does
what
it
does
very
very
well.
There
are
a
few
others
out
there.
If
you
type
in
api
hosting
service,
I'm
sure
you'll
you'll
find
budge.
A
So
it
you
know
kind
of
tying.
All
together
apis
have
fire
hydra.
They
are
a
first
class
feature.
They
are
not
an
afterthought.
It's
we
are
apis
all
the
way
down.
All
of
our
customers
can
access
the
fire
hydrant
api,
that
our
ui
does.
A
I
joke,
and
I
say
if
you
just
absolutely
loathe
the
fire
hydrant
ui,
you
could
build
fire
hydrant
again
on
our
apis,
like
we
really
are
that
open
and
honest
about
our
apis
and
the
availability
of
them,
and
it's
important
because
it
means
our
customers
get
the
same
guarantees
that
our
front
end
gets
it's
not
an
afterthought.
It
is
the
thought.
A
Opening
api
spec
has
also
allowed
us
to
generate
documentation,
websites,
clients
with
ease.
We
use
our
own
clients
within
our
within
our
application
and
also
our
integrations
as
well
such
as
our
kubernetes
integration,
cli
integration,
they're.
All
powered
off
of
this
open
api
documentation
that
we
have
built
for
ourselves
developers
at
fire
hydrant.io.
If
you
want
to
check
that
out.