►
Description
The issue that we want to implement: https://gitlab.com/gitlab-org/gitlab/-/issues/342437.
The GitLab GraphQL style guide: https://docs.gitlab.com/ee/development/api_graphql_styleguide.html.
The GraphQL gem docs: https://graphql-ruby.org/.
The GraphQL explorer GitLab.com: https://gitlab.com/-/graphql-explorer
A
Hello,
everyone
I'm
David
from
the
package
team
and
in
today's
video
we
are
going
to
go
through
a
pair
programming
session
about
graphql
with
me.
Today
we
have
Dima
and
Raul
so
hello
and
we
are
going
to
tackle
this
issue,
which
is
having
a
graphql
mutation
to
delete
packages
in
bulk,
so
delete
multiple
packages
in
one
request.
A
A
Okay,
so
graphql
I,
don't
know
which
level
of
your
graphql
knowledge
is
so
I
guess
I
will
be
trying
to
summarize
some
Concepts.
If
you
have
any
questions,
just
stop
me
and-
and
we
can
go
into
details-
I'm,
not
sure
how
much
of
the
implementation
we
would
get
done,
but
we'll
see
at
the
end,
I
will
finish
the
implementation
today
and
I
will
open,
NMR
and
and
yeah
since
you're.
Working
on
this
with
me,
you
will
be
credited
on
on
on
that
MR2.
B
A
That's
the
two
type
of
requests,
better
set,
two
types
of
queries
that
you
can
make,
so
the
rate
requests
are
called
queries
so
short
and
simple,
the
other
ones,
the
the
ones
that
do
some
rights.
They
are
called
mutations,
and
here
we
are
going
to
delete
packages,
so
we
are
going
to
introduce
a
new
mutation
on
graphql.
A
A
B
A
A
A
A
Okay
and
then
we
open
it's
like
it's
like
opening
the
the
project
value
that
is
written,
and
here
we
are
on
the
project
value,
so
we
can
ask
for
the
packages
which
will
return
a
connection.
We
open
that
connection.
We
are
interested
in
the
nodes,
we
open
the
nodes,
and
here
it's
the
fields
of
the
of
the
package,
so.
A
This,
and
so
we
we
have
two
packages
on
that
that
project.
That's
a
query:
the
mutation,
it's
the
mutation
is
exactly
the
same.
It's
just
that
mutations
are
more
complex
inputs
because
usually
limitations
can
be.
For
example,
you
can
update
an
object,
so
you
will
need
to
pass
as
an
input
all
the
updated
fields
that
you
all
the
fields
that
you
want
to
update.
So
it's
it's
similar
with
more.
B
A
A
A
You
can
basically
have
it
where
you
want,
but
we
we
do
have
some
code
organization
at
GitHub.
Otherwise
that
would
be
the
wide
west
I
guess.
So
we
do
have
a
namespace
for
mutations.
Then
it's
pretty
much
splitted
into
functional
area.
So
we
do
have
one
namespace
for
packages
and
then
we
have
all
the
you.
A
A
And
then
the
most
important
function
is
the
result,
so
the
the
result
function
is
basically
taking
the
inputs
of
the
mutation
and
just
execute
the
mutation
and
returning
returning
either
a
message
or
an
ntra
or
errors
or
whatever.
The
the
inputs
of
the
of
the
result.
Function
are
exactly
the
ones
that
are
stated
as
Arguments
for.
A
A
A
Yeah,
so
this
one
that's
a
custom
helper
on
GitHub,
so
we
do
have
a
lot
of
queries
and
mutations
that
use
a
project
path
as
a
as
an
argument,
and
so
this
this
thing
provides
it's
the
defined
project
based
on
on
Project
path,
is
to
find
a
Project
based
on
this.
The
input
and
that
will
get
executed
by
this
line.
Motorola
is
fine.
A
It's
yeah!
It's
it's
not
super
clear
because
it's
like
helpers
using
helpers,
and
so
it's
not
super
clear,
but
this
thing
will
call
I
think
it's
called
it
expects
to
have
a
function
called
find
object
and
it
will
actually
find
the
object
and
check
this
permission
on
the
find
object
and
just
fail.
If,
if
the
user
doesn't
have
the
the
object,
we
can
check
on
the
I
think
we
do
have
that
on
the
destroy
package,
five,
so
same
mutation,
but
this
one
is
just
for
one
package
file.
A
A
Same
parameters,
so
here
since
we
didn't
use
the
project
helper,
we
Define
defined
object
directly,
but
here
since
it's
the
project
path,
we
can
use
the
finds
project.
I
guess
we
can
open
it.
Let's
see
what
what
this
has
but
I
guess.
It's
almost
just
find
object.
You
see
yeah,
just
fine.
It's
just
a
way
to
avoid
everyone
to
Define
this
function
on
their
mutation
yeah,
but
yeah.
There
is
something
to
to
know
it's
that
the
authorized
fine.
Well,
actually,
you
can
always
check.
B
A
Yeah,
so
it's
actually
me
that
doesn't
know
how
to
write
so
it's
yeah
as
I
said
it's
finding
the
object.
You
see
this.
The
call
here
on
the
find
object,
method,
another
object
that
has
been
patched.
We
will
call
the
authorized
which
is
just
below,
and
it's
it's
actually,
oh,
that
okay
I,
like
those
constructions
where
you
your
functions,
that
are
only
one
single
line
but
okay.
Why
not?
So
it
will
just
check
if
we
do
have
the
authorization
on
that
object.
A
A
A
Is
naming
like
I'd
like
to
put
like
destroy
I,
don't
know
packages.rv
yeah?
Why
not?
But
we
do
have
packages
twice
right:
yep,
yep
I'm,
as
I
said
several
times.
I'm
a
simple
man
like
duplicating
packages
doesn't
bring
value
so
yeah.
Well,
we
we
can
go
with
bulk,
destroy
I,
guess
yeah.
That
should
be
quite
explicit.
If
you
have
some
ideas,
don't
hesitate
to
to
give
me
names
yeah.
Well,
let's
go
with
this
and
we'll
see
so
yeah
I'm,
super
lazy,
so
I
will
start.
A
It's
destroyed
packages,
we
don't
need
this.
We
will
discuss
key
authorize
shortly.
We
said
that
we
don't
have
the
project
path,
we
do
have
IDs.
That
has
to
be
an
array,
so
a
very
quick
World
on
arguments.
So
you
give
a
name
which
is
the
one
that
will
be
used
on
the
schema.
Then
you
have
to
give
a
type
so.
A
A
A
Required
the
schema
allows
you
to
to
say:
if
you
expect
you
can
have
multiple
fields,
and
you
can
you
can
say:
okay,
this
field
is
required,
I
need
it
all
the
time.
This
input
field
and
this
input
field
is
optional.
That's
basically
the
required
thing
here.
We
only
have
IDs
so
yeah,
it
is
required.
Otherwise
we
we
can't.
We
can
do
anything
and
then
the
description,
it's
useful
for
the
schema,
because
you
will
get
the
description
there,
the
it's
the
Side
Bar
that
I
open
previously
like
exploring
the
schema.
A
A
A
A
To
extract
the
model,
yeah
model
ID
and
then
it's
using
the
model
class
directly
yeah,
that's
not
really
recommended.
We
should.
We
usually
need
to
use
a
finder.
So
a
finder
is
like
it's
like
a
service
class
that
is
highly
specialized
to
just
fetch
objects.
That's
it
services,
do
whatever
logic
you
need
to
do
so.
A
A
B
A
A
B
A
A
A
B
B
A
A
A
A
Yeah
I
guess
that's
something
to
take
into
account
from
my
knowledge:
I
think
the
the
default
sorting
will
work
just
fine,
but
I
would
still
and
actually
I
will
do
it
on
this
amount.
Because
that's
a
new
query,
we
will
need
the
database
analysis
so
that
we
know
that.
Okay,
this
query
disquarified,
it's
fine.
What
is
more,
what
bothers
me
more
are
the
the
including.
A
A
B
A
A
So
yeah
the
thing
is
that
the
mutation
will
need
a
finder
and
the
service.
My
idea
for
this
session
is
that
I
don't
want
to
spend
too
much
time
on
those
two
things,
because
there
are
they're
like
additional
things
out
of
graphql
I
wanted
to
focus
this
session
on
graphql.
But
you
tell
me
if
you
want
to
go
into
details
on
finders
and
services.
That's
fine
too!
A
B
A
A
Here,
filter
by,
let's
say
that
it's
IDs-
probably
this
is
specific
to
this
finder,
so
I'm
not
going
to
add
this
to
the
we
do,
have
a
a
module
or
a
concern
or
whatever
you
want
to
call
this.
It's
a
ruby
module
that
is
included
in
different
helpers
to
provide
this
filtering
methods
but
filter
by
IDs
yeah.
That's
not
that
often
that
we
need
to
do.
A
B
A
B
A
A
A
One
so
in
in
the
package
registry,
we
don't
destroy
packages
directly
because
we
do
have
files
and
files
are
linked
to
object
storage,
so
we
can
delete
them
within
the
web
request
because
that's
that's
a
bit
too
many
operations
in
one
go,
and
here
we
are
actually
trying
to
destroy
multiple
packages,
so
that
would
be
even
more
operations
to
do
in
one
go
so
instead,
what
we
do
is
that
we
we
mark
them.
It's
like
flagging
them
for
for
Destruction.
A
A
Yeah,
that's
that's
correct
and
we
need
to
sing
the
yeah.
That's
for
Maven
packages.
That's
something
specific
for
Maven.
In
very
short
words.
Maven
has
a
other
file
that
we
list
all
the
available
packages.
So
if
you
delete
a
package,
we
need
to
remove
that
packaging
version
from
that
file,
so
this
function
will
include
a
job
that
will
just
do.
A
A
A
And
so
one
of
the
parameters
are
the
container,
which
is
like
domain
actor
that
you
want
to
open,
like
this
service
want
to
works
on
this
actor
or
this
object.
So
the
the
object
is
called
container
for
the
base
container
service
so
because
I
don't
want
to
have
container
everywhere.
I
just
put
an
earlier
so
that
I.
A
B
A
A
Which
means
that
we
don't
want
duplicates,
because
you
don't
want
to
check
the
the
permissions
twice,
although
we
don't
have
any
performance
penalty,
because
the
permission
framework
will
actually
cache
all
evaluations.
So
if
you
check
the
destroy
package
against
project
I
project
a
and
then
at
a
later
time
you
check
again
the
first
evaluation.
The
result
of
that
evaluation
was
cached,
and
so
the
second
one
is
almost
free.
The
Char,
the
cache
is
checked
and
there
is
a
hit
and
you
will
get
the
result
return.
A
B
A
A
A
A
A
Yeah
again,
this
is
this
is
a
shortcut,
but
I
will
not
create
the
the
Mr
with
this,
because
we
should
really
avoid
each
on
collections
that
you
don't
know
the
the
final
size
for
our
case
here.
It's
fine
because
we
limited
the
IDS
to
20.
So
it's
fine
to
do
an
age,
but
I
know
that
I
want
to
reuse
this
service
on
cleanup
policies
and
it's
not
20
is
is
like
any
number.
It's
it's
arbitrary,
so
we
cannot
have
an
each
here.
We
need
to
have
something
else.
A
A
So
probably
I
will
do
that
and
and
streamline
this
one,
because
this
one
is
an
update.
So,
instead
of
having
that
many
updates,
we
can
just
pack
all
together
in
one
single
update
this
one
I
will
probably
have
a
way.
There
is
a
way
to
include
multiple
jobs
in
a
single
call.
I,
don't
want
to
include
them
one
by
one.
It's
similar
to
the
SQL
aspect
like
include
them
all
by
one,
but
for
the
sake
of
keeping
things
short.
B
A
B
A
A
B
A
A
A
A
This
is
very
simple,
since
every
every
it's
like
every
object
in
the
graphql
schema
is
mapped
to
a
class.
We
do
have
a
query
type.
That
is
a
class
that
will
actually
have
all
the
queries
that
are
possible
and
we
do
have
a
mutation
type,
I
guess
yeah
same
thing,
but
for
mutation,
mutations,
so
yeah
there
is
a
bit
of
order
in
here.
So
let's
put
here,
let's
put
everything
together.
We
do
have
the
destroy
here.
A
Okay,
I
think
we're
good.
So
what
we
can
do
is
just
reload
the
editor.
The
editor
itself
will
query
the
the
graphql
server
hey,
give
me
the
the
new
schema
and
we
should
see
the
our
mutations
here
when
you
work
on
on
graphql.
This
is
very
handy
because
this
loading,
if
it
fails
that
means
that
something
that
something
went
wrong
with
either
your
declaration,
your
mutations
or
you
I,
don't
know
the
arguments
or
something
here
it
it.
It
has
all
loaded.
So
our
mutation
is
a
valid
one.
It
was
properly
loaded
and.
A
A
A
B
A
A
A
B
B
A
A
So
we
we,
basically
the
the
implementation
on
the
graphql
side
is
done.
Is
that
that's
good?
The
only
thing
is
missing.
Is
the
the
refactorings,
because
I
I
took
two
shortcuts
here
for
the
finder
and
in
the
service
for
looping
on
the
packages,
and
then
when
this
refactoring
is
done,
we
will
need
to
create
all
the
specs.
But
well,
since
we
are
out
of
time
I
guess
we
need
to
stop
here,
yeah.
Well,
so
that's
basically
the
how
you
you
work
with
graphql.
A
We
can
have
a
quick
word
on
specs,
so
specs
for
graphql.
It's
about.
Basically,
you
are
going
to
have
specs
on
two
levels.
One
of
them
is
the
mutation
itself.
It's
like
it's
almost
initializing
this
class
and
calling
the
resolve
function,
basically
that
what
you
will
do
and
the
other
level
is
running
at
the
it's
like
running
at
the
graphql
controller
level,
where
you
actually
send
the
query
to
the
controller
and
say
hey,
it's
like
doing
what
we
did
here.
A
B
A
A
A
There
are
two
formats,
there
is
a
Json
format
and
there
is
the
like
the
guava
creel
format,
which
is
basically
what
we
see
here
when
we
create
queries
same
thing,
but
with
everything
that
we
can
do
so
we
do
have
two
tasks
for
update
those
schema
now.
Actually
we
do
have
one
for
dumping.
The
schema
in
in
those
two
formats
and
the
other
one
that
we
will
need
is
the
compiled
dogs.
So
it's
gitlab,
graphql,
compile
docs.
If
you
want
that.
A
A
A
A
We
do
have
a
few
ones.
So
I
would
say
that
for
all
simple
things
like
a
new
query
or
adding
a
new
field
that
you
can
return
in
a
query,
that's
fine!
Anyone
can
review
that,
but
for
more
complex
mutations
or
more
complex
access
like
sometimes
you
want
to
access,
really
nested
objects,
but
at
the
same
time
you
want
to
avoid
and
plural
n
plus
one
situations.
Things
like
that.
B
B
Yeah
to
the
code
editor,
we
implemented
kind
of
the
strict
rule
that
if
the
amount
of
IDs
is
more
than
Define
it,
then
we
just
trust
an
error
yeah.
What
would
be
your
thoughts
on
to
make
it
slightly
softer,
for
example,
and
still
accept
the
request
but
kind
of
partial,
accept
request
and
still
delete
some
amount
of
the
packages
but
and
together
also
like
rice
and
errors
that
only
this
amount
allowed,
but
so
you
know
kind
of
success.
Blood
Plus
combine
it
with
error,
just.
A
In
this
case,
the
the
max
amount
of
20
was
not
chosen
randomly
it's
actually
the
amount
of
packages
that
can
be
selected
on
the
front
end
for
Destruction
and
so
ultimately
the
front
we
will.
We
want
to
implement
that
front-end
feature.
So
these
backend
changes
are
supporting
that
front-end
feature
and
yeah.
For
the
first
iteration,
we
decided
to
start
with
what
the
front-end
needs
and
limit
to
that.
A
If
then,
users
come
back
and
hey
I
want
to
delete
like
I,
don't
know
thousands
of
packages,
we
can
look
into
into
that
and
see
how
the
system
reacts,
but
I
guess
it's
part
of
the
of
the
iteration
value.
The
first
iteration
is
super
simple
and
it's
the
front-end
needs
and
that's
fine.
The
only
extra
bonus
here
is
that
that
service
that
deletes
multiple
packages,
I
already
know
that
we
are
going
to
use
that
on
cleanup
policies.