►
From YouTube: Jamstack Incubation Engineering -- Showcase January 2023
Description
User survey all results: https://about.gitlab.com/handbook/engineering/incubation/jamstack/js-runtimes-survey.html
A
Hi
I'm
Janis:
this
is
the
gitlab
drumstack
incubation
showcase.
What
I'm
working
on
right
now
is
a
feature
for
gitlab
to
allow
users
to
deploy
server-side
JavaScript.
This
would
be
an
amazing
step
to
deploy
modern
JavaScript
Frameworks
such
as
remix
belt
kit
or
next.js
right
from
within
gitlab,
without
needing
to
set
up
a
node
server
I'm.
Currently
at
a
point
where
I
have
two
viables
viable
ways
of
implementing
that
one
is
using
cloudflare
workers
I
call
this
a
cloudflare
track.
A
A
We
want
to
start
this
with
a
project
level
integration.
This
means
users
bring
their
own
cloudflare
account
and
connect
it
with
an
API
token,
once
we
were
able
to
hide
most
of
the
complexities,
we
would
then
add
it
on
an
instance
level.
That
means
we're
offering
this
runtime
on
gitlab's
Bill
for
users.
This
would
look
like
we
just
offered
this
runtime
service
ourselves.
A
The
other
viable
way
to
allow
running
JS
server
side
using
gitlab,
is
by
executing
V8
isolates
directly
in
gitlab
pages.
I
call
this
the
pages
track.
This
is
way
more
experimental,
but
also
a
bit
more
interesting.
Currently,
gitlab
Pages
serves
only
static
files,
but
it's
written
in
go
so
it
executes
super
fast
I
have
used.
This
go
wrapper
around
the
VA
JavaScript
engine
to
translate
a
request
made
to
the
go
API
into
a
JavaScript
object
and
execute
that
then
I
obtain
the
result
from
JS
and
return
that
to
the
user.
A
Let
me
show
you
here's
a
project
in
gitlab.
It
has
some
static,
HTML
files,
just
like
how
it
always
was,
but
now
I
can
add
a
new
file
called
request.js
not
set
on
the
name
yet,
but
let's
call
it
request.js
for
now.
I'll
include
a
Handler
function
inside
that
file.
That
returns.
This
response
object
and
just
as
an
example
I'll
commit
that,
and
once
the
pages
pipeline
ran,
I
can
visit
the
pages
site
if
I
go
to
a
path
that
has
a
static
file.
A
A
A
So
what
are
my
next
steps?
I'm,
currently
working
on
both
tracks
kind
of
in
parallel?
My
goal
is
to
get
either
one
of
them
live
as
soon
as
possible.
The
pages
track
is
more
promising
in
terms
of
user
experience.
It's
also
faster
to
develop
and
go
than
in
the
rails
of
monolith,
but
this
track
has
more
unknowns
on
the
cloudflare
track.
On
the
other
hand,
I've
worked
for
longer
and
it's
more
predictable.
A
So
for
the
decision
I
needed
an
additional
data
point
I
went
ahead
and
created
a
short
survey.
A
couple
of
weeks
ago,
I
sent
it
out
to
front-end
and
jumpstack
developers.
I
wanted
to
see
where
their
priorities
are.
I
got
38
responses,
both
gitlab
users
and
non-users
I've,
written
up
all
the
results
in
the
handbook
and
put
a
link
below
the
video,
but
here's
a
quick
overview
over
the
actual
results.
A
Next
I
wanted
to
know
what
features
do
users
need
for
a
JS,
runtime,
so
I.
Let
them
rate
a
few
statements
from
not
important
on
this
side
to
very
important
on
this
side.
Here's
the
result
is
it
important
that
there
is
a
free
tier?
The
answer
is
a
resounding
yes,
all
the
competitive
Services
have
very
generous
free
tiers,
so
it
makes
sense
that
this
is
expected.
Now
people
need
to
try
the
capabilities
before
making
a
commitment.
After
all,
second
statement,
a
strong
USP
of
gitlab
pages
is
that
you
can
self-host
it.
A
A
How
important
is
it
that
whatever
service
we
come
up
with
integrates
into
an
existing
ecosystem
and
the
answer
is
not
quite
mandatory,
but
rather
important
even
more
so
if
we
only
look
at
the
answers
of
people
that
have
used
gitlab
before
now,
the
one
thing
cloudflare
workers
has
that
we
don't
is
an
edge
Network,
a
network
of
hundreds
of
servers
distributed
around
the
globe
to
reduce
Network
latency.
No
matter
where
on
Earth,
you
are,
is
that
important,
the
user's
answers,
Maybe.
A
That's
interesting
because
my
first
intuition
was
that
this
is
super
important.
Then
it's
the
main
reason
I
started
the
whole
thing
with
cloudflare
track
now,
The
crucial
difference
for
me.
In
this
whole,
two
tracks
system
is
user.
Experience
on
the
one
hand,
side
versus
feature
completeness.
On
the
other
hand,
Cloud
there
has
all
the
features
already
done:
API
complete
a
whole
ecosystem,
but
the
iterative
approach
would
mean
we're,
starting
with
a
rather
complicated
developer
experience.
A
You
have
to
create
a
cloudflare
account,
obtain
an
API
token
set
it
up
in
GitHub,
and
then
we
can
work
on
making
that
process
simpler
with
each
iteration
and
integrate
more
into
the
eye
using
pages.
On
the
other
hand,
there's
zero
setup
required
from
the
start.
You
just
drop
a
script
where
you've
dropped,
static
files
before
Done
Works,
but
we'd
have
to
build
the
whole
ecosystem
from
scratch.
The
API
everything
so
in
the
beginning,
there's
very
few
features
and
each
iteration
we
would
add
new
ones.
A
So
I
asked
the
users
to
read
the
high
level
statement.
Is
it
more
important
that
it's
easy
to
use
or
that
it
has
for
you
to
completeness
here's?
What
I
said
please
give
me
both
I
should
have
known
that
would
happen,
but
but
when
it
really
comes
down
to
it,
ease
of
use
clearly
wins,
especially
if
we
only
look
at
the
answers
where
users
felt
really
strongly
about
either.
A
Now,
let's
abstract
this
into
a
product
strategy,
say
we
have
a
distribution
of
potential
users
like
this
lots
of
small
websites
and
a
large
long
tail
of
increasingly
complex
sites
with
cloudflare.
We
can
cater
in
theory
to
all
of
them,
but
as
long
as
the
setup
is
complicated
with
bringing
your
own
account,
only
the
long
tail
users
would
be
willing
to
invest
that
effort.
A
As
we
iterate
making
making
the
interface
simpler,
we
move
the
target
audience
to
the
left
using
Pages.
We
probably
were
probably
ignoring
the
long
tail
users
to
start
with.
We
won't
have
the
features
they
need,
but
we'd
be
able
to
cater
to
a
way
bigger
chunk
of
quick
and
easy,
build
and
forget
sites
and,
as
we
iterate
add
features,
we
move
to
the
right.
A
So
this
would
likely
give
us
more
instant
feedback.
It
would
create
a
bigger
buzz.
It
looks
like
a
more
sensible
approach.
Okay,
let's
summarize
one
I
prefer
the
pages
approach
a
bit
more.
Given
the
user
feedback,
two,
both
implementations
would
be
able
to
co-exist
eventually,
but
I
can
probably
only
focus
at
one
at
a
time.
Three,
but
Pages
has
two
open
blocking
security
questions.