Responding to API endpoint without returning

Get Help and Help Others
1

I am working on a Slack app, using our Redwood JS server to handle slash command webhooks. The pattern for the webhooks is to:

  1. Respond with an ack (i.e. empty 200 response)
  2. Do stuff (business logic, CRUD, etc)
  3. Send a message to the embedded response_url in the webhook based on the outcome of step 2

However in Redwood docs, these API Endpoints respond to clients by immediately returning. Since our business logic is fairly straightforward, I want to “ack” the response, do my business logic, and send the final response in one handler, rather than need to push a bunch of logic to background workers. Is this possible? Any hints on the simplest way to handle this type of use case?

2

One thought would be something like this:

export const handler = async (event: APIGatewayEvent, _context: Context) => {
  if (authenticateSlackRequest(event)) {
    deferWork()
    return {
      statusCode: 200,
    }
  }
  return {
    statusCode: 401,
    body: JSON.stringify({ message: 'Unauthorized' }),
  }
}

const deferWork = async () => {
  await new Promise((resolve) => setTimeout(resolve, 10000))
  console.log('deferred work done')
}

Running this code locally, everything seems to work fine, but I’m slightly concerned about running this in a prod environment (GCP Cloud Run specifically), and the server process is terminated (for example, by scaling down or deploying a new revision). Any thoughts on that approach?

3

FYI I responded in another channel. I’ll update back here when we have an answer.

FYI my suggestion is to use Inngest since you want production durability and that will give you the confidence I think you want.

1 Like
4

As @dthyresson mentioned, using a background worker like Inngest is the most durable way to handle this type of workflow in Redwood. I realized that it was probably simpler to use the bolt framework for this feature, since it provides a nice SDK and doesn’t require the additional overhead of a background worker. There may be some ways to register the bolt app at the fastify level, but in our use case, we decided it was simpler to create a separate entrypoint into the app and run it as a different service outside of the redwood server