►
Description
This Kong Summit 2020 session focuses on the war stories, and subsequently the patterns HyperCurrent employed, from building an API chargeback/monetization product using OAS, Kotlin, Spring Boot and Kong. We will discuss how a programmatic approach can be used to deliver an elegant REST-ful API while enforcing an anti-corruption layer for domain logic without writing API contracts by hand. By using Kotlin and Spring Boot along with a controller/DTO approach, we can automatically produce an OAS contract, HTML docs, a console and a client side SDK.
A
Who
is
hypercurrent
just
to
give
you
some
context
on
our
company,
so
we're
a
technology
startup
delivering
software
to
help
enterprises
turn
their
apis
and
microservices
investments
into
profit
centers.
We
currently
have
customers
in
the
financial
services,
insurance,
healthcare
and
federal
government
verticals.
A
Now
in
terms
of
the
product
we
built,
so
we
built
something
called
profit
stream,
so
profit
stream
is
a
distributed.
Ledger
based
enterprise,
api,
chargeback
and
monetization
platform,
and
essentially
what
it
enables
organizations
to
do,
is
to
monetize
their
api
and
microservice
investments
by
metering,
api
transactions
across
lines
of
business,
between
central
italy,
lines
of
business
and
even
distributed
organizations,
and
then
then
it
has
the
ability,
then
to
to
take
that
metering
data
and
then
do
things
like
send.
A
A
In
addition
to
that,
we
also
had
to
cater
to
business
personas,
who
were
in
the
salesforce
ecosystem.
So
we
also
realized
that
we
needed
a
salesforce,
lightning
interface.
So
there
was
a
single
pane
of
glass
for
for
our
users
who
were
in
the
salesforce
ecosystem
and
then
finally,
we
knew
from
an
operational
standpoint
that
we
had.
A
We
needed
some
sort
of
command
line
that
led
administrators
configure
and
then
operate
the
software
at
scale
and
then
also
do
things
like
scripting
and
integrate
it
with
various
devops
moving
parts,
so
so
that
you
know
that
this
piece
of
the
use
cases
will
be
the
focus
of
this
talk.
But
in
addition
to
these
this
use
case
around
the
user
interfaces.
A
We
also
had
a
bunch
of
other
non-trivial
stuff.
We
had
to
contend
with
so
because
this
this
product,
profit
stream,
is
dealing
with
financial
data.
We
had
to
integrate
to
multiple
financial
systems
of
records
so
again
things
like
salesforce
oracle,
financials,
microsoft
dynamics,
the
data
model
and
business
logic.
For
this
both
you
know
from
internal
data
modeling
standpoint,
as
well
as
just
the
data
models
we
presented
to
the
user
interfaces.
A
This
was
also
non-trivial
right,
so
we
had
a
relational
backend
database.
We
have
a
distributed
ledger
piece
of
it
and
all
this
needed
to
be
kind
of
condensed
in
a
way
that
was
consumable
by
our
front-end
developers.
We
didn't
necessarily
know
a
lot
about.
You
know
things
like
you
know:
chargeback
use
cases
or
distributed
ledgers
or
things
to
that
effect.
A
We
also
had
to
support
multiple
deployment
models,
so
you
know
knowing
that
our
customers
would
be
in
the
financial
services
and
government
kind
of
vectors.
They
even
had
on-premise
deployment
requirements.
Many
had
private
cloud
initiatives
and
we
also
obviously
had
to
support,
hosted
models
as
well
as
public
cloud
models
and
then,
finally,
for
anyone,
who's
done
any
kind
of
enterprise,
any
kind
of
enterprise
application
development.
A
We
also
had
to
have
slas
for
our
own
software
right,
so
that
meant
having
cross-cutting
concerns
addressed
like
rate
limiting
and
things
like
circuit
breakers.
So
you
know
to
summarize
just
a
lot
of
of
you
know
various
difficult
moving
parts
that
we
had
to
contend
with
from
an
analysis
and
architecture
standpoint
before
we
wrote
any
code
at
all.
A
So
when
the
core
team
got
together,
we
landed
on
a
handful
of
patterns
and
techniques
that
we
were
going
to
apply
to
address
all
the
complexity
of
the
previous
slide,
and
essentially,
I'm
going
to
spend
the
rest
of
this.
This
topic
dressing
is
the
the
techniques
and
patterns
that
we
chose
to
to
use.
So
to
summarize,
we
we
landed
on
a
combination
of
domain-driven
design,
strategic
and
tactical
patterns.
A
Obviously,
you
know
using
restful
apis,
then
in
terms
of
the
implementation
of
the
wrestle
apis
leveraging
spring
boot
and
then
the
kotlin
language
and
then
finally
leveraging
kong,
both
as
a
metering
solution
as
well,
as
you
know,
eating
our
own
dog
food
in
terms
of
using
it
to
address
the
enterprise
cross-cutting
concerns.
I
I
just
talked
about
so
things
like
rate,
limiting
throttling
circuit,
breaking
etcetera
and
essentially
these
techniques.
Let
us
go
from
product
inception.
A
A
So
the
idea
here
is
that
you
know
initially
for
our
own
front
end
development
team,
then,
ultimately
for
any
other,
maybe
third
party
or
customer
teams
that
wanted
to
extend
our
product.
We
wanted
to
make
sure
that
that
their
experience,
interacting
with
our
product,
was
as
straightforward
as
possible.
So
this
is
where
you
know
the
a
lot
of
the
benefits
for
having
api
contracts
comes
into
play.
So
you
get
things
like
auto
generated
platform
sdks.
A
So,
for
instance,
we're
able
we
were
able
to
quickly
produce
both
javascript
and
java
sdks
for
profit
stream,
so
this
meant
that
developers
would
just
bring
these
these
libraries
into
their
their
projects
and
start
immediately
accessing
the
apis
of
data
types.
We
were
exposing.
You
also
get
things
like
auto-generated
documentation,
so
we
were
able
to
generate.
You
know
something
like
60
pages
of
very
nicely
formatted.
A
You
know
html
and
pdfs
that
documented
all
the
different
endpoints
and
data
types
that
we
were
exposing
in
our
application
and
then
finally,
you
get
things
like
developer
portals
right,
so
the
ability
using
the
contracts
to
push
a
button
and
then
expose
out
both
the
sdks,
the
documentation
and
the
api
itself
in
a
way
that
lets
developers
quickly
sign
up
and
access
it.
So
again,
a
bunch
of
stuff.
A
A
There's
two
schools
of
thought,
so
the
first
school
of
thought
involves
a
top-down
approach,
so
in
top-down
api
contract
development,
the
contract
is
defined
first
and
the
code
is
implemented.
Second,
and
then
with
the
bottom-up
approach,
you
write
the
code
first,
so
you
basically
build
your
api
and
then
once
you,
you
get
to
a
point
where
the
api
is
usable.
You
generate
a
contract
as
an
artifact
from
that
build.
A
There
are
significant
pros
and
cons
for
each
of
these
approaches.
So
I'm
going
to
talk
about
now.
What
those
pros
and
cons
are
briefly
and
then
I'm
going
to
talk
about
the
approach
that
we
landed
at
that
hypercurrent
building
out
the
profit
stream
api,
so
top
down
contract
development.
So,
with
top
down
contract
development,
a
you
know,
generally,
a
developer
will
collaborate
with
you
know
with
other
people.
A
As
part
of
you
know,
the
the
contract
definition
to
write
write
the
api
contract
first,
so
this
means
that
before
anyone
touches
any
code
at
all,
there's
a
design
first
approach
that
that
involves
iteration,
where
the
api
designer
works
with
the
api
consumers
and
they
essentially
collaborate
on
the
api
design
to
ensure
that
the
api
meets
the
consumer's
requirements,
and
you
know
as
a
side
effect
of
this
approach.
Since
you
have,
you
know,
obviously,
a
human
being
writing
these
things.
These
contracts
are
also
generally
readable
by
humans.
A
So
this
means
that
someone
looking
at
the
api
contract,
you
know
they.
They
should
be
able
to
understand
pretty
quickly
what
it
does
without
having
to
go
and
like
bring
it
into
an
ide
or
jump
through
any
kind
of
hoops
in
terms
of
understanding
understanding
what
it
is,
because
it's
too
complex
or
anything
to
that
effect
now
in
terms
of
the
cons
with
contract
based
top-down
development,
the
design
tooling,
is
it
tends
to
be
awkward
for
it.
A
So,
generally,
you
need
to
do
you
know
browser-based
ide
sort
of
stuff
to
to
design
the
apis.
Some
of
them
are
form
based.
It
also
requires
learning
a
new
language,
so
this
means,
in
addition
to
whatever
back-end
stack
you
you've
landed
on
to
build
your
api
in
you.
Don't
need
to
have
your
developers
learn
some
new
contract
language
to
go,
define
the
front
end
of
their
api
and
also,
I
think
this
is
probably
the
biggest
one
for
me.
A
The
this
approach
almost
always
requires
code
generation
so
for
anyone,
who's,
who's
dealt
with
code
generation,
there's
a
bunch
of
associated
complexity
that
comes
along
with
that,
namely
it
means
that
every
time
you
touch
the
contract
that
usually
has
a
bunch
of
cascading
implications,
the
back
end
code.
Once
you
you
do
the
contract
generation.
A
I
think
the
final
piece
is
that
again
in
my
personal
experience,
I
find
implementing
cross-cutting
functionality
difficult
with
top-down
contract
development.
So,
even
though
there
tend
to
be
mechanisms
to
express
things
like
pagination
and
security,
shared
data
types,
etc,
I
usually
find
that
doing.
This
is
awkward
and
again
doesn't
really
lend
itself.
Well,
when
the
back-end
code
is
generated
now,
the
other
school
of
thought
in
terms
of
contract
development
is
doing
it
from
the
bottom
up.
A
So
in
this
approach,
developers
auto
generate
a
contract
that
build
time
and
then
essentially,
it's
always
in
sync,
with
whatever
the
code
is
so
so
using
this
approach,
a
developer
might
write
an
api
using
java
or
node.js
or
something
and
then
as
part
of
the
build
process.
When
this
artifact
is
built,
it
will
generate
the
api
contract
as
a
side
effect.
So
this
means
that
the
api
contracts,
always
in
sync
with
the
code.
A
So
you
know
naively,
this
might
seem
like
a
good
thing
like
basically,
you
know
you
point
something
at
your
database
game
is
then
you
automatically
get
a
restful
api.
The
the
real
danger
here
is
that
once
you
do
that
you've
automatically
coupled
your
front-end
user
interfaces
to
your
backend
database,
schemas
and
now
that's
made.
It
makes
it
very
difficult
to
go
and
do
to
evolve
your
data
models
and
and
schemas
going
forward.
A
A
So
essentially
what
we've
done
is:
we've
landed
on
a
hybrid
approach
that
we
call
middle
out
that
takes
advantage
of
both
styles
and
it
uses
a
combination
of
the
following
techniques
which
I'll
dive
into.
But
essentially,
we
used
the
domain-driven
design,
strategic
hexagonal
architecture,
pattern,
the
tactical
anti-corruption
layer
and
dto
patterns,
and
then
we
also
from
a
cross-cutting
concern
standpoint
leveraged
annotation,
driven
documentation
to
generate
the
contracts,
as
well
as
api
policies
to
address
yeah,
just
the
the
more
operational
cross-cutting
cerns
that
I
talked
about
previously.
A
So
the
the
first
pattern
we
used
to
accelerate
the
the
api
contract
development
was
leveraging
domain,
driven
design
and
hexagonal
architecture.
So
for
those
who
aren't
familiar,
hexagonal
architecture
basically
means
that
you,
you
have
your
core
domain
model
and
data
types
and
then
essentially
you
you
have
those
at
the
center
of
your
hexagon
and
then
surrounding
that
hexagon
are
ports
and
adapters
which,
for
all
intents
and
purposes,
protect
the
domain
model
from
corrupting
interfaces.
A
So
when
I
I
talked
about
before
about
coupling,
you
know
relational
we're
starting
coupling
your
data
models
and
schemas
to
your
api
contracts.
It's
this
approach
that
lets
you
avoid
that.
So
this
is
the
idea
that
you
surround
the
data
model
with
things
like
rest
controllers
and
then
serialization
layers
and
then
you're
able
to
essentially
support
things
like
concurrent,
front-end,
uis
and
integration.
A
So
the
next
accelerator
that
we
leveraged
to
get
to
this
api
sort
of
contract,
nirvana
for
lack
of
a
better
term
is,
is
leveraging
kotlin
as
an
implementation.
Language
so
and
you'll
see
why
this
is
relevant
in
a
few
minutes.
But
but
kotlin
for
those
who
aren't
familiar
is
an
object,
orientated
functional
jvm
language.
A
Kotlin
are
things
like
data
classes,
co-routines,
it's
concise,
syntax
and
all
safety
type
inference,
and
some
other
things,
and-
and
you
know
this
is
essentially
what
makes
kotlin
a
really
nice
language
for
implementing
apis
now
in
terms
of
the
anti-corruption
layer
right.
So
just
you
know
kind
of
looping
back
to
the
hexagonal
architecture.
A
A
We
leverage
the
data,
transfer
object
patterns
of
the
dto
pattern
as
that
essentially
leverages
kotlin
data
classes
to
serialize
data
types
back
and
forth
from
the
different
res
controllers.
To
the
front
end
interfaces
the
dtos
are,
are
you
know
purely
for
serialization
deserialization,
there's,
no
business
logic,
there
they're
just
basically,
you
know
just
used
to
transport
data
back
and
forth
from
a
different
different
user
interfaces
over
our
rest,
api
and
even
the
controllers
themselves
are,
are
you
know
they're
essentially
dumb?
They
they
basically
don't.
A
A
So,
rather
than
have
developed,
the
developers
write
the
in
our
case
the
swagger
contracts
we
instead,
let
them
document
the
the
anti-corruption
layer
and
the
dto
layers.
I
just
talked
about
with
something
called
spring
fox,
so
essentially,
what
these
do
is
they
they,
let
you
use
kotlin
or
java
annotations
on
your
methods
and
your
data
classes
and
then,
as
part
of
the
build
time
these
annotations
will
produce.
You
know
fully
documented
swagger
contract
along
with
the
data
types.
So
this
is
the
main
piece
that
lets
us.
A
You
know
get
the
get
the
benefits
of
both
worlds
right,
so
this
combination
of
using
hexagonal
architecture,
anti-corruption
layers
and
dtos
in
combination
with
annotation
driven
api
documentation,
let's
just
protect
our
core
data
model
and
schemas,
while
also
automatically
exposing
api
contracts
and
then
in
conjunction
with
kotlin.
This
basically
forms
you
know
a
mini,
domain-specific
language
right
so
with
very
little
developer.
Sort
of
cognitive,
overhead
or
even
effort,
it
becomes
really
easy
for
for
us
to
define
api
contracts.
A
It
also
makes
it
easy
from
us
again
from
a
devops
standpoint,
to
put
guardrails
in
place
in
terms
of
doing
things
like
sonarqube
checks,
to
make
sure
that
our
controller
classes
and
data
dtos
are
all
annotated
with
the
annotations
as
well
right.
So
let's
just
programmatically
enforce
that
things
will
will
produce
documentation,
so
it
gets
a
huge
amount
of
power
coming
from
these.
These
approaches
now
the
other
piece.
So
this
this
is
the
now
we're
into
the
cross-cutting
concerns
part.
A
So
again,
this
saved
us
a
ton
of
time
on
the
back
end
from
saving
our
developers
from
having
to
reinvent
the
wheel
for
a
lot
of
these
use
cases
and
then
also
from
an
enterprise
api,
cross-cutting,
constant
concern
standpoint.
You
know
kong
is
a
huge
help
for
us
here,
so
in
terms
of
our
core
business
use
case.
So
you
know
just
going
back
to
profit
stream
and
the
fact
it's
doing
api
metering
chargeback.
A
We
were
able
to
very
easily
build
a
kong
plugin
that
lets
us
to
meter
and
roll
up
api
charging
transaction
data
right.
So
essentially,
this
means
that
we
can
deploy
com
to
our
customers,
who
are
using
profit
stream,
and
it
gives
us
a
way
to
asynchronously,
collect
and
meter
api
traffic
going
through
the
the
com
proxies.
A
The
other
major
piece-
and
this
is
where
we're
using
con
in
our
own
application-
is
we're
able
to
put
kong
in
front
of
our
api
and
then
get
a
lot
of
the
stuff
that
would
otherwise
take
us.
You
know
a
lot
of
development
effort
from
an
operational
standpoint.
It
is
implementing
things
like
rate
limiting
governance,
security
and
circuit
breaking
right.
A
So,
just
you
know,
security
alone,
this,
having
the
you
know,
the
ability
to
leverage
olaf
and
sso
features
in
kong
as
well
as
doing
the
you
know,
the
sla
enforcement
so
we're
limiting
governance.
This
is
all
things
that
would
be
non-trivial
for
my
team
to
build
and
we
sort
of
just
get
out
of
the
box
from
using
com
as
an
api
gaming
player,
and
then
finally,
you
know
just
a
circuit
breaking
right,
so
we
have
to
maintain
our
own
slas,
particularly
for
our
own.
You
know
hosted
models
of
this.
A
A
So
now,
to
summarize,
I
just
want
to
quickly
go
through
the
lessons
learned
from
moving
just
from
the
inception
of
this
product
to
mvp.
So
essentially,
after
the
the
inception
and
architecture
stage,
we
got
to
mvp
kind
of
general
availability,
general
availability
of
profit
stream
within
six
months.
So
this
was,
you
know
using
the
you
know,
the
highly
skilled
core
team
that
I
mentioned
at
the
beginning
of
the
presentation,
as
well
as
the
overseas
ui
ux
teams.
A
You
know
just
back
of
that
in
calculations
I'm
guessing
we
got
two
to
three
hundred
percent
productivity
gains
using
these
techniques.
You
know
again
the
the
kang
plug
plug-in
architecture
not
having
to
reinvent
the
wheel
for
security
and
governance
that
saved
us
on
the
low
end
two
months,
if
not
more
than
that.
A
So,
basically,
you
know
we'll
get
a
pull
request
from
the
from
the
front
end
team
we'll
integrate
that
in
check
it
in
and
then
our
build
process
will
push
the
the
new
api
out
the
api
portal
and
the
back
end
and
again
it
could
happen.
You
know
within
a
few
minutes,
assuming
the
the
api
contract
changes
are
trivial
from
a
semantic
standpoint:
the
client-side
code
generation
techniques.
So
again
I
talked
about
this,
but
the
fact
we
were
able
to
just
automatically
produce
java
and
javascript
sdks
that
particularly
simplified
the
cli
development.
A
We
basically
got
the
cli
written,
I
want
to
say
in
like
like
seven
days
or
something
it
was
super
quick
to
get
that
done
using
the
the
auto
generated
java,
sdk
and
then
just
from
a
strategic
standpoint.
Having
done
this,
this
product
we've
built
a
bunch
of
our
own
internal
core
libraries.
I
suspect
the
next
the
next
products
that
we
build,
we'll
even
further
velocity
gains
just
by
having
done
this
stuff
already
and
implemented
in
the
way.
That's
that's
reusable
now
again
nothing's
for
free
right.
A
So
there
were
some
risks.
With
this
approach
and
some
you
know
some,
you
know
kind
of
negative
things,
so
the
the
positive.
Definitely
that
weighs
the
negative
because
I'm
being
transparent
you
know
so
one
thing
to
bear
in
mind
is
that
the
core
team
we
bought
up
fuel
worked
together
before
and
again,
like
you
know,
a
bunch
of
experience.
A
So
you
know
if
it
was
a
team
that
we
built
from
scratch.
I'd
be
a
little
bit
more
worried.
You
know
you
know
just
from
a
communication
standpoint
and
getting
everyone
to
gel,
but
again
we
all
have
experience
working
together.
So
that
wasn't
an
issue
here.
The
other
thing
is
that
kotlin
on
the
server-side
world,
it's
you
know
it's
sort
of
new
right
so
like
I
wouldn't
expect
to
be
able
to
find
back
in
kotlin
developers
really
easily.
A
I
wouldn't
suspect,
it'd
be
too
difficult
for
them
to
ramp
up
on
kotlin
the
again
on
the
kotlin
piece,
some
of
the
kotlin
spring
boot
intersections
were
nascent
and
not
well
documented,
that's
not
to
say
we
couldn't
get
it
to
work,
but
they're,
just
things
that
you
know
again
from
a
documentation
standpoint.
You
know,
I
suspect
that
we
were
maybe
some
of
the
first
people
doing
it.
Just
based
on
some
of
the
issues
we
saw
on
some
of
the
gaps
in
documentation.
A
So
a
lot
of
the
front
end
stuff
was
actually
less
around
crud
and
more
around
reports
and
ad-hoc
graphs,
and
we
had.
We
had,
we
shouldn't
say
trouble,
but
it
was
somewhat
awkward
to
map.
You
know
restful
api
concepts
to
these
ad-hoc
queries
so
because
that
we're
beginning
to
look
at
a
parallel,
graphql
api.
In
addition
to
the
you
know,
the
the
current
crud
api
from
a
wrestle
standpoint
that
we're
exposing.