👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labled with Status: Up for grabs. You & others like you are the reason all of this works! So thank you & happy coding! 🚀

I'm pretty sure that Octokit supports serverless. If there was a known problem with https://www.serverless.com/ specifically then we could add a test to address it, but adding tests just for the sake of it, I'm not sure if that's helpful?

Maybe we should do the tests in Probot instead?

On a related note, I always wanted to remove all the "middleware" functionalities into their own @octokit/middleware-* packages. We could then create custom middlewares for custom deployment targets, and invite the community to provide their own. There could be a dedicated one for serverless. Would that be something that would be interesting for you to work on?

Am I interpreting your issue correct that you are particularly interested in serverless.com? Or is it about serverless environments in general?

@gr2m

I am actually investigating how we can rip out express from probot. See:

probot/probot#1930

Maybe providing the middlware is ok, but what I would prefer is exporting the handler out. Then I could use in probot a fast router, like find-my-way, which we use in fastify and just mount the webhook handler to the right place in the router.
Or without a router and just check always if the webhook path is correct and call directly the webhook path and the other routes are then slower, but we dont care about their performance.

We use at work probot with gcf and gcf expects actually a express middleware. But if we dont use any express specific stuff, we increase the compatibility with other serverless implementations like aws or azure.

fwiw I'm using these libraries without issue (express or otherwise) in both AWS Lambdas and Azure Functions - most of them are internal for Ackama, but this is a public example

(I am in support of reducing dependencies in general where it is possible to do so without a heavy increase in maintenance burden so will happily support PRs reducing any direct dependencies on express that is stable)

I am actually investigating how we can rip out express from probot.

I think the right approach here is to make probot decomposable. We started that effort already: https://probot.github.io/docs/development/#run-probot-programmatically

Eventually it should be decomposable to a smooth eject of Probot altogether, into octokit.

Probot is a framework, it should be opiniated and come with batteries included. We can replace express with something better / more performant, but there should always be a server built in. And the high-level usage of probot run ./my-app.js or new Server({ Probot }) should not expose too low-level hooks to replace these built-in batteries. Instead you should be able to bring you own server and only use probot for the parts that are relevant to you

You make valid points.

I would therefore recommend for the beginning just to get the createNodeHandler part exported.
We can later "reshuffle" if necessary. ;)

get the createNodeHandler part exported

we already do that already?

In Probot

https://probot.github.io/docs/development/#use-createnodemiddleware

In @octokit/webhooks

https://github.com/octokit/webhooks.js#createnodemiddleware

Imho createnodemiddleware is also handling routing. If we have the pure handler, we can improve the performance.

Imho createnodemiddleware is also handling routing. If we have the pure handler, we can improve the performance.

Okay that makes sense, I'm okay with the direction #932 is going 👍 just update the README to include the new export and explain the difference between the two exports