[RFC] Better resolver validation and authorization with a new pipe function

[flybayer]

I've found it very common for mutations to want the following:

• Validate input data with zod
• Normal users can only create items attached to their organization/account
• Admin users can create items attached to any organization/account

So let's make that easier.

I'm proposing adding a resolverPipe() function that could be used like this:

export const CreateProject = z.object({
  name: z.string(),
  dueDate: z.date().optional(),
  orgId: z.number().optional(),
})

// Pipe function runs functions in order.
// So here CreateProject.parse will be called on input data first verifying input
// This will automatically add correct type to the (input, ctx) arguments of next function.

export default resolverPipe(CreateProject.parse, async (input, ctx) => {

  // orgId input is optional, defaults to currentOrgId
  input.orgId ??= ctx.session.orgId
  // User must be logged in
  ctx.session.$authorize()
  // If input.orgId does not match the current user, require user to have admin role
  ctx.session.$authorize("admin", {if: input.orgId !== ctx.session.orgId})

  const project = await db.project.create({
    data: input,
  })

  return project
})

And with a new authorize() helper function, the above could be written this way:

export default resolverPipe(
  CreateProject.parse,
  // set default orgId
  (input, {session}) => ({orgId: session.orgId, ...input}),
  authorize(),
  authorize("admin", (input, {session}) => input.orgId !== session.orgId),
  async (input) => {
    console.log("Creating project...")
    const project = await db.project.create({
      data: input,
    })
    console.log("Created project")
    return project
  },
)

Furthermore since requiring a logged in user is so common, we could add authorizedPipe() which would call ctx.session.authorize() for you.

Key Benefits

• Easily validate input data with a zod schema
• Easily require user to be logged in
• Less having to manually specify TS types
• Get the resolver input properly typed without having to do export type SignupInputType = z.infer<typeof SignupInput>
• For advanced cases you can easily compose functions

[flybayer]

If you're curious, here's an earlier iteration of this general idea that I didn't like very well: #1234

[flybayer]

I don't know about you all, but the more I think about this the more I really like it! It's so powerful and elegant.

I don't particularly like the name of resolverPipe though. I would rather it just be pipe, but that could confuse folks since this is not a normal pipe. It's a special pipe which takes functions with arity of two instead of one, and additionally it adds special types (like Ctx).

[malkomalko]

Just want to make sure I'm understanding this correctly 😄

Does the output of each step (I like the name step somewhere in the method name btw) set the value of input (the first arg) in the following function call? The ctx argument is an optional second arg that gets passed to every function?

What happens when one of the steps fails? Does it stop the whole chain? Can you post an example of how you'd deal with errors?

Is authorize() by itself just a function that checks ctx.session.authorize() and just returns the previous input and ctx if it succeeds?

What is the second signature of authorize mean with two arguments? Is it: authorize(checkThisRole, ifThisFnReturnsFalse)?

[flybayer]

Does the output of each step set the value of input (the first arg) in the following function call? The ctx argument is an optional second arg that gets passed to every function?

Yes and yes

What happens when one of the steps fails? Does it stop the whole chain? Can you post an example of how you'd deal with errors?

The chain stops at the failure point, just like if you called each function imperatively in order. This doesn't change anything about error handling. It will continue to work as it does now.

Is authorize() by itself just a function that checks ctx.session.authorize() and just returns the previous input and ctx if it succeeds?

Yes

What is the second signature of authorize mean with two arguments? Is it: authorize(checkThisRole, ifThisFnReturnsFalse)?

Optional second param to ctx.session.authorize() is technically unrelated to this RFC but it got stuck in lol. The second argument is a condition. The role will be enforced only if that condition is true.

[Skn0tt]

Love it! 🥰

[flybayer]

Update!

Here's the final result. I had to have a little wrapper for zod schemas to make the types correct, so decided to make pipe and object that we can add various utilities to. Currently has pipe.resolver, pipe.zod, and pipe.authorize

This is fully working both for strong types and runtime! :)

😍😍😍😍😍😍

import {pipe} from "blitz"
import db from "db"
import * as z from "zod"

export const CreateProject = z.object({
  name: z.string(),
  dueDate: z.date().optional(),
  orgId: z.number().optional(),
})

export default pipe.resolver(
  pipe.zod(CreateProject),
  pipe.authorize(),
  // Set default orgId
  (input, {session}) => ({orgId: session.orgId, ...input}),
  async (input, ctx) => {

    console.log("Creating project...", ctx.session.orgId)
    const project = await db.project.create({
      data: input,
    })
    console.log("Created project")

    return project
  },
)

PR coming soon

[flybayer]

PR: #1801