`stripe-sync-engine`-as-a-library in a NPM package

[Amaury]

Before anything, I just want to say that this project is gold. It's basically an open-source alternative to https://syncinc.so/. When i read in the README:

Note: this is experimental. There are no guarantees that it will be supported in the future.

I just hope that this project will continue to live on!

Feature request

Is your feature request related to a problem? Please describe.

This repo instantiates a server using fastify. To use this code, one needs to deploy a separate server, e.g. on https://fly.io. It maybe happens that the user already has a server with existing API endpoints, and just wants to add another /webhook (or with another name!) endpoint, and use the behind-the-scenes logic from this repo.

Currently, it's hard to use this repo's code in an existing server codebase.

Describe the solution you'd like

I propose to expose a npm package that would be stripe-sync-engine as a library.

Basically, it would expose one webhookHandler function, which would more or less contain this code and all related dependencies.

Then, the actual server's webhook in src/routes/webhooks.ts can be as simple as:

import { webhookHandler } from '@supabase/stripe-sync-engine';

export default async function routes(fastify: FastifyInstance) {
  fastify.post('/webhooks', {
    handler: async (request, reply) => {
      await webhookHandler({
        body: request.body as { raw: Buffer },
        stripeSig: request.headers['stripe-signature'],
        stripeWebhookSecret: config.STRIPE_WEBHOOK_SECRET,
        // maybe some other options
      });

      return reply.send({ received: true })
  });
}

And then it should be easy to use webhookHandler with other backend frameworks (Express, Next.js...)

Describe alternatives you've considered

There's always the possibility to fork, but...

Additional context

Add any other context or screenshots about the feature request here.

[Div Arora]

Instead of needing to support different frameworks etc here, would placing this service and your other ones behind a reverse proxy do the trick?

[Amaury]

The problem is not so much to have the /webhook endpoint on the same URL (which a reverse proxy solves), but really to avoid deploying a separate server (which comes with additional costs & maintenance).

[Copple]

this project is gold

Thanks for the kind words, @AmauryM - always nice hearing positive feedback.

I think we can probably extract out the logic from the API routes. I'm not entirely sure how yet but something we can look at. We did something similar with postgres-meta.