►
Description
Please join us for Fluent Talks! Our weekly webinar and office hours, on Fridays at 2PM Central. Streaming live on YouTube. This week we're going to get technical and provide detailed examples of how we use Golang to design and test our APIs
#flluentbit #golang #calyptia
A
Hey,
hey
everyone
welcome
to
another
episode
of
fluent
talks
and
I
am
joined
with
two
engineers
from
calyptia,
nicolas
and
gabriel.
We
have
some
exciting
topics
today
and
typically
we
we
chat
all
about
fluent
and
and
the
fluent
ecosystem,
but
today
we
actually
wanted
to
talk
a
little
bit
more
about
some
engineering
topics.
So
with
that,
let
me
go
ahead
and
hand
it
off
to
you.
Nicolas.
B
B
Guys,
I'm
seeing
it
yeah,
you
can
see
it
all
right,
so
it's
going
to
be
very
technical.
It's
going
to
be
a
demo
basically,
so
what
we
do
eclipse
normally
for
back
in
api
is
to
split
it
into
three
layers.
So
we
have
like
a
service
layer
when
we
perform
authentication
authorization
validate
the
input
from
the
user
and
we
call
any
party
dependency.
We
have
a
database
messaging
system
sending
of
emails.
B
B
So
here
I
have
a
demo
application.
It's
basically
just
one
table.
This
is
sql,
it's
the
user
table.
We
have
an
email
and
a
username,
very
straightforward
and,
like
I
said,
we
split
the
code
into
three
different
parts.
We
have
the
store
when
we
use
the
sql
database
and
the
user
file.
We
do
all
the
queries
to
work
with
the
with
the
user.
You
know
I
insert
a
user
fetch,
a
list
of
user
and
so
on
and
this
store
extract.
B
Now
we
want
to
install
a
user,
and
here
we
perform
the
validation
and
in
this
case,
since
it's
a
just
a
demo,
we
don't
have
addressation
or
any
kind
of
authentication
really
so
yeah.
You
should
normally
put
that
kind
of
stuff
here,
but
we
call
or
restore-
and
we
perform
the
logic
in
here
so
to
create
a
user.
B
B
B
B
So
yeah.
That's
basically
what
I
wanted
to
show
you
that
also
because
we
have
started
doing
the
client
first
approach.
We
know
we've
been
actually
making
simpler
apis
before
we
have,
for
instance,
for
the
filter
api.
We
have
a
functional
options
within
golden
those
were
nice,
but
actually
for
our
use
case
for
a
api.
Basically
that
a
user
is
gonna,
bring
some
json
into
the
thing
it
doesn't
fit.
So
we
simplified
a
lot
of
cases
like
those
by
thinking.
First,
in
how
the
client
is
going
to
look
and
then
implementing
it.
C
C
B
Yeah,
so
the
best
part,
I
think
is
we
don't
have
to
maintain
too
much
code,
because
testing
code
is
also
code
and
it's
most
of
the
code
really
so
like
we
know
this
is
really
all
of
the
tests
we
had
before
became
useless
because,
for
instance,
let
me
show
you
when
we
want
to
in
here
in
the
service
we
want
to
data
user.
Let
me
toggle
the.
B
B
So,
for
example,
if
you
test
only
this
method
in
isolation
and
then
test
the
other
one
and
then
the
other
one,
okay,
you
can
have
okay
good
gold
coverage,
but
then
what
we
were
doing
before
is
that
we
will
mock
this.
You
receive
this
as
an
interface
and
by
using
mox.
You
won't
find
issues
that
have
actually
happened
because
inside
a
sequel
transaction
for
example,
if
you
something
fails
here,
the
transaction
is
gonna
fail
to
commit.
A
B
Can
expect
an
error
to
be
not
fun
and
do
something
on
top
of
it?
You
are
handling
it
gracefully.
You
know,
and
you
can
even
put
the
book
statement
down
here
and
you
can
see
that
the
thing
passes,
but
actually
at
the
end
of
the
transaction.
It's
gonna
fail
because
you
cannot,
you
cannot
have
errors
inside
the
transaction
and
that's
something
very
difficult
to
test.
C
B
Can't
work,
if
you
have
it
separate.
Actually
you
know
this
at
calypso.
We
have
it
separately
in
a
public
and
a
private
repo,
both
of
them
and
we
have
a
flow
with
github
ci
when
we
do
a
change
in
this
repo
and
we
check
out
the
other
repo
and
we
can
run
the
test
from
the
other
ripple
to
this
one.
So
it's
possible
to
do
that.
B
A
B
Container,
this
can
be
swapped
by
a
postgres
container
or
whatever
it
is
whatever
you
want
to
use.
Then
we
try
to
connect
to
the
container,
because
the
container
cannot
it
could
be
not
ready.
Yet
you
know
the
image
can
still
be
pulling
or
the
container
itself
can
have
a
time
to
to
be
alive
to
be
ready.
You
know,
so
this
connect
method
is
using
our
retry
function
to
try
to
connect
to
the
database.
C
C
A
B
B
B
C
A
C
C
If,
let's
say,
if
you
have
already
a
system
big
and
you
don't
have
any
tests
on
it,
integration
test
is
always
the
easiest
way
to
test
it,
because
you
are
starting
for
the
borders
of
the
your
software,
so
you
are
literally
putting
up
your
whole
system
and
calling
the
apis
so
yeah.
If
you
don't
have
any
integration
tests,
I
mean
on
the
layers
between
service
and
database.
C
If
you
don't
have
any
in
your
test,
it
will
be
the
best
approach
for
your
start,
something
you
know
from
go
to
zero
for
something
it's
the
best
effort
yeah
the
idea.
I
think,
if
you
have
something
too
specifical,
let's
say
some
function
that
do
some
math
yeah
and
this
function
that
some
have
some
accounting.
It
can't
fail
in
any
time.
So
you
have
to
write
a
unit
test
for
this
function
because
it's
too
important
for
you
and
yeah
the
other
stuffs.
That
is
not
let's
say
not
that
relevant,
not
between
quotes.
C
A
B
B
B
C
Say
if,
if
you
can,
if
you
have
resource
you
have
time
yeah,
it's
good
to
you,
keep
the
test
primate
in
mind.
You
know
cover
the
base
of
perimeter
with
units
and
then
with
some
integration
tests
and
then
with
some
ui
tests,
because
yeah
as
we
can
see
here,
it's
we
we
have
to.
We
have
to
spend
some
resource
more
than
unit
tests,
to
extend
a
container
and
run
restart
the
server
and
run
against
everything
you
know
so
yeah.
It
depends
all
of
about
your
needs,
but
for
what
we
are
doing
here.
B
B
One
thing
I
forgot
to
mention
about
this
approach
is
that
downside
site
by
using
mods,
for
example,
you
can
force
a
method
in
the
database
to
error
to
have
an
external
error,
but
here's
difficult
to
do
that.
You
have,
I
know,
maybe
to
close
the
database
or
something
or
delete
the
table
so
yeah
these
tests,
don't
cover
that
and
you.
C
A
B
B
This
is
the
code
that
is
not
covered,
but
this
is
actually
just
internal
layers
of
the
database
example
here
is
in
our
error
in
the
sql
query
itself
or
here
on
the
decode
face
of
the
data,
but
this
is
something
that
you
can
find
not
with
this,
but
actually
just
with
your
static
code
analysis,
if
we
remove
this
line,
you're
gonna
get
a
warning
here
that
the
value
is
never
used.
So
these
are
stuff
that
most
of
the
time
your
id
is
gonna
catch.