►
From YouTube: May 13, 2021 Ortelius Architecture Working Group
Description
A focus on adding Swagger data to the Component is the primary topic of this Architecture Working Group meeting.
A
A
May
13th
the
artelias
architecture
meeting
so
just
kind
of
want
to
pick
up
where
we
kind
of
left
off
from
last
time
with
the
swagger
bringing
the
swagger
information
into
ortilius
at
the
component
level,
and
I've
been
doing
some
thinking
on
this,
and
I've
been
going
back
and
forth.
I'm
kind
of
on
the
fence
on
whether
we
should
bring
in
the
swagger
yaml
or
json
into
ortilius
and
store
it
in
our
database
or
if
we
should
just
leave
it
as
a
pointer
to
where
it
exists.
A
You
know
externally,
or
we
do
like
an
optional
thing.
Those
are
like
the
three
three
thought
processes
I
have
around
the
first
one
where
we
bring
it
into
in
inter
into
artelia,
so
we
can
tightly
couple
it
to
the
version
of
the
component.
So
we
can.
We
don't
have
to
worry
about
the
getting
out
of
sync
or
drift
between
an
external
file,
and
you
know
the
component
version
that
we're
we're
gonna
be
like
moving
around
and
deploying
and
tracking.
A
A
For
lack
of
a
better
word
ui
inside
of
ortelius,
I
look,
there
is
some
javascript
that
we
can
bring
in
to
render
up
the
the
yamo
or
json
and
then
be
able
to
have
all
the
endpoints,
and
you
know
the
parameters
and
all
the
documentation
there.
So
that's
kind
of
the
the
goal
will
be
allow
people
to
go
ahead
and-
and
you
know
see
what
the
contracts
are
from
inside
of
a
component
version.
B
So,
basically
we're
talking
about
having
a
cache
of
these
swagger
files
internally
in
artelias
and
and
my
question
about
whether
that
makes
sense
or
not
boils
down
to
two
things
like
hey.
How
much
are
we
going
to
want
to
come
back
and
reprocess
the
same
data,
and
so
saving
us
a
round
trip
to
whatever
the
external
thing
is,
could
be
reducing
latency
or
expense
and
making
our
lives
better?
B
And
you
know
how
much
is
how
we're
gonna
process
this
stuff
going
to
change.
You
know
like
if
we
1.0
we
can
process
like
50
of
the
data
and
swagger.
Would
we
want
to
come
back
in
a
month
or
six
months
and
reprocess
that
data
once
we
can
more
richly
pull
stuff
out
of
it
and
so
not
having
to
re-retrieve?
It
would
make
that
much
faster.
A
Yeah,
I
think,
on
the
the
way
I
understand
that
swagger
works
is
you
have
the
I
can't
remember
if
it's
yama
or
json
or
if
it'll
handle
both,
but
basically
you
have
the
file,
and
then
you
throw
the
file
at
a
swagger,
javascript
library
and
then
from
there.
It
will
basically
render
up
the
documentation
sections
and
then
like
the
little
entry
entry
fields.
If
you
want
to
go
ahead
and
test
something,
so
that
is
where
we
would
be
embedding
basically
a
swagger
javascript
engine
into
ortelius
to
do
that
work.
A
A
It
would
be
for
initially
it
would
be
for
people
to
see
visually
what
the
endpoints
are
and
the
parameters
for
the
endpoints
you
know
and
that
documentation
around
the
endpoints.
So
from
a
microservices
perspective,
you
have
your
microservice
right
now.
We
have
no
way
to
document
what
the
endpoint
is
for
that
microservice
and
bringing
in
the
swagger
would
be
the
easy
way
to
get
a
lot
of
bonus
points
from
the
developers.
A
B
So,
if
we're
not
really
like
processing
the
data
and
integrating
it
we're
just
basically
just
having
this
sort
of
bag
on
the
side
to
give
people
additional
useful
information,
then
the
question
boils
down
to
like
how
reliably
do
you
feel
like
you're,
going
to
continue
to
be
able
to
retrieve
that
information?
Or
do
you
want
to
store
it
in
a
cache
so
that
it
doesn't
look
like
ortelius
is
unreliable
just
because
some
other
back-end
system
isn't
up
at
the
moment.
A
C
Yeah
I
want
to
share
something
usually
when
you
go
to
the
to
the
contractors
world,
when
I
want
to
call
it
open
abby,
because
swagger
is
right.
Now
is
a
standard.
So
when
you
call
swagger
is
like
you're
directly
working
with
swagger,
so
in
the
open,
app
specification
and
contract
first
is
is
a
whole
life
cycle
for
for
a
for
the
an
integration
perspective.
C
So
usually,
if
you
contract
first,
usually
you
are
going
to
have
a
lifecycle
from
from
this
specification
and
you're
going
to
need
to
to
implement
some
kind
of
tooling
to
to
do
this.
This
workflow
working
for
avoiding
like
contracts
being
like,
I
don't
know,
sync
with
the
implementation
and
stuff
like
that,
so
I'm
seeing
or
the
brace
we
use
control
first
as
life
sql
you're,
going
to
use
chilling
like
like
epicurio
for
for
managing
the
implementation
you're
going
to
need
to
a
registry.
C
So
confluent,
I
think,
is
the
one
the
last
time
I
use
it
and
then
you
are
going
to
start
using
some
stuff
like
micros
for
for
for
for
first
you
know
you
take
the
implement
you,
you
do
take
the
contract,
then
you
implement
it
with
apigee
and
then,
when
microsoft
start
doing,
like
the
the
validation
that
you
need
for
that
app.
And
finally,
your
you
include
all
that
in
your
cicd
or
deployment
structure
to
to
be
sure,
you're
going
to
have
this
thing
with
your
implementation.
The
thing
is
working
with
with
contract.
C
Fear
is
impacts
in
the
way
you're
going
to
develop.
So
I
I,
if
we
are
going
to
go
to
to
to
open
abby,
probably
we
are
going
to
start
doing
changing
all
the
the
life
cycle
of
the
development,
because
people
who
want
to
implement
some
change.
You
are
going
to
start
with
the
contract,
updating
the
specification,
the
methods,
what
is
going
to
do
with
the
metadata,
and
then
you
are
going
to
re-uh
regenerate.
D
C
Your
your
structure
and
then
doing
the
change,
so
my
thoughts
are
that
that
working
with
with
open
appy
is
a
is
a
it's
a
whole
life
cycle
of
managing
managing
the
the
happy
itself
and
the
development
too.
So
that's
our
mind.
So
we
implement
like
a
few
more
tools
to
to
hang
on
with
all
this
information.
Of
course,
you
can
just
put
in
the
swagger
a
library
and
and
and
publishing
some
you're
you're
happy
for
a
specific
microservices,
maybe
but
yeah
at
the
time
you're
going
to
need
create
all
this
flow.
A
Basically,
so
I
think
that
part
of
the
life
cycle
is
a
little
bit
too
early
for
us
and
we
want
to
pick
up
after
all
that
work's
been
done
and
they're,
you
know
getting
ready,
ready
to
push
it
to
a
registry,
or
you
know
when
the
the
docker
build's
been
completed,
that
we
can
grab
a
swagger
file.
At
that
point,
that's
my
thought:
does
that
make
sense.
B
B
Does
it
make
sense
from
a
user
interface
perspective,
to
be
able
to
let
people
move
back
and
forth
between
the
history?
You
know,
we've
got
api
version,
one
and
api
version
two,
and
so,
if
somebody's
looking
at
a
microservice
that
was
released
with
api
version
two
should
they
be
able
to
go
back
and
find
api
version
one
and
whatever
was
associated
with
that?
I
don't
know
if
that
I
mean
that
seems
like
it
could
be
useful,
but
I
don't
know
if
it's
really
worth
the
trouble
or
not
to
well.
That
is.
A
B
A
No,
you
have
those
three
components
would
well.
Let's
put
it
this
way,
those
we
would
be
looking
at
from
the
the
producer
side
and
not
the
consumer
side.
Initially,
so
a
microservice
is
going
to
produce
an
endpoint.
That
would
be
the
swagger
that
we
would
associate
would
be.
This
is
how
you
talk
to
this
endpoint
in
this
version
of
the
microservice
and
that's
for
component
a
now
component
b
version.
Three
is
going
to
have
its
endpoint
definition
and
the
documentation
around
it,
and
then
we
have
another.
A
You
know
the
the
component
z
has
version
20
with
its
endpoint
definition
that
we
have
to
it.
If
that's
going
to
be
on
the
producing
side,
but
on
the
but
we're
not
initially
we're
not
going
to
look
at
the
consuming
side,
you
know,
z
is
consuming
version.
You
know
three
version
component
b.
You
know
that
I
think
it'll
be
down
the
road
when
we
look
like
bringing
in
telemetry.
C
Yeah
I
I
will
like,
if
we
maybe
have
some
session
to
work
like
seeing
trying
to
put
in
put
in
some
paper
what
are
the
the
what
we
want
to
resolve
and
what
are
the
capability?
We
have
and
then
do
a
little
like
aroma
for
that
to
see
okay
on
the
stage
one
we
are
focusing
on,
because
we
want
to
solve
this
so
having
something
like
that,
we
are
going
to
be
able
to
see
okay
on
the
first
step.
C
We
need
to
implement
like
this
this,
and
maybe
we
can
connect
the
pieces
to
the
end,
as
I
would
a
strategy
to
the
thing
we
are
building
and
in
increments
can
connect
at
the
end
and
having
maybe
this
whole
life
cycle
that
is
going
to
help
us,
but
I
would
like
to
have
that
big
picture
to
know
that
everything
we
are.
Every
step
we
are
doing
is
going
to
help
for
a
final
big
solution
for
say
in
some
way.
A
B
A
D
There's
a
million
different
ways,
and
I
think
this
is
part
of
a
pain
at
the
moment
which
folk
have
so
you've
got
swagger
hub,
which
is
remember
correctly.
Kind
of
public
sharing
and
most
of
the
swagger
api
is
from
cyber
swagger
libraries,
themselves.net
and
python,
and
the
like.
You
can
actually
stand
up
a
web
server,
essentially
a
report
alongside
the
application
which
exposes
the
swagger
api
directly
and
it's
just
basically
a
static
site
generated
from
the
json
files
and
a
couple
other
bits
and
pieces.
D
So
some
places
you'll
have
the
services
running
with
the
swagger
api
along
the
side
of
it
or
people
will
need
to
pull
the
image
down
and
then
run
it
in
order
to
see
it.
So
there
is
tooling
around
there
and
I
don't
necessarily
from
the
investigation.
I've
been
doing
like
what
we
do
internally.
I
don't
think
there's
really
a
kind
of
standardized
way
outside
of
just
using
the
built-in
kind
of
swag
and
library
to
expose
it.
D
There
is
definitely
value
in
being
able
to
associate
a
version
of
a
component
and
the
even
just
initially
just
the
api
associated
with
what
that's
producing,
because
you
do
run
into
situations
where
different
environments
with
different
api
versions.
It
can
be
quite
hard
to
track
that
and
there
is
tooling
around
it,
but
it
tends
to
go
more
along
the
lines
of
contract
based
testing,
which
can
be
a
bit
heavyweight
for
just.
D
A
C
D
C
A
A
C
Okay,
well,
I
just
do
the
the
what
is
the
documentation
and
yeah.
It
is
simple
to
use
as
as
the
demo,
because
it's
just
a
library
one
comment
on
that.
I
there
are
two
ways
to
implement
it.
What
is
one
is
using
a
decorate
like
adding
adding
over
a
method
like
the
the
implementation
of
the
pie,
breaker
and
the
other
one
is
just
calling
like
in
a
normal
way.
I
have
to
say
that
the
method
decorated
works
for
me
and
the
other
one.
C
C
The
web
microservice
without
having
the
database
is
a
half
amount
of
free,
try
some
time
between
that
retry
and
now
I'm
implementing
some
health
endpoint,
because
I
want
to
visualize
what
is
doing
the
the
secret
breaker
inside
I
want
to
the
observability
he
offers
so
the
secret
breaker
has
the
count.
Has
the
fry
has
the
state,
so
I'm
exposing
a
a
little
metal
to
to
have
visibility
of
that?
C
A
All
right,
awesome,
yeah,
so
just
put
some
contacts
for
people
that
missed
in
our
python
microservice
code.
We
ran
into
this
with
mooney
and
bemi
on
their
the
chico's
africa,
where
the
there's
a
sinking,
a
timing
problem
where
the
database
wasn't
starting
quick
enough
for
their
microservice
to
start
in
kubernetes.
A
We
don't
want
it
to
be
overly
complicated
and
if
we
need
to
you,
know,
exit
out-
or
you
know,
crash
gracefully
and
let
kubernetes
kind
of
kick
us
off
and
restart
us
and,
and
that
part
is,
is,
is
an
option
as
well,
and
that's
what
he's
looking
at.
So
that's
just
some
context.
What
we're
doing
at
that
point
it
you
know.
A
A
All
right
cool
there
is
a
if
you're
interested
it's
going
to
be
4
30
mountain
time
today
we're
going
to
do
another
architecture
meeting
with
the
australian
time
zone.
I
think
it
ends
up
being
like
8
or
8
30
sydney
time.
So,
if
you're
interested
on
that,
it's
on
the
calendar,
that
group
is
focusing
around
get
ops
and
artelia's
interface
and
to
get
up
so
that's
where
there's
like,
I
think,
five
of
them
five
or
six
of
them
that
are
working
on
it.