Readers may also enjoy Steampipe [1], an open source CLI to live query Stripe [2] and 80+ other services with SQL (e.g. AWS, GitHub, CSV, AirTable, etc). It uses Postgres Foreign Data Wrappers under the hood and supports joins etc across the services. (Disclaimer - I'm a lead on the project.)

1 - https://steampipe.io 2 - https://hub.steampipe.io/plugins/turbot/stripe

Thanks for sharing. Steampipe looks really cool, will test it out!

For the alternatives section, there is another way: apply Stripe events directly to your Postgres DB as they occur.

I wrote about this here:

https://table.dog/blog/stripe/how-to/stripe-graphql/

Looks interesting but isn't this just another way of syncing data to your database (duplicated data). Instead of via a webhook you're using this tdog CLI

This approach is also limited because it won't allow you to do mutations like:

``` mutation { stripe { createBillingPortalSession(customer: "cus_xxx") { id url } } } ```

Yeh it does just write your Stripe data to your database. This is better than doing just-in-time HTTP queries when you run your GQL query. Local data access is faster to read and indexes can be used.

Writing to Stripe is not supported, but you will likely want to use the Stripe API directly in order to handle errors.

The events endpoint works slightly differently from webhooks: https://table.dog/blog/principles/events-are-better/

The comparison in this link is quite biased - having all "X" on one side and all "V" on the other is a strong indication of that.

More specifically, I disagree with some of the points there, it really just depends on your use-case.

It is biased as it is arguing in favour of events over webhooks (and may be missing some of the benefits of webhooks). But I feel it is quite accurate.

Which points do you disagree with?

Like you said, the main thing is what it doesn't include.

Though also specifically "D. Least server resources used", which is very much dependent on usage characteristics. If each of your customers is getting thousands of webhooks per second, then yeah, webhooks are probably not the best idea (though even then it's not that clear cut, because with webhooks you already have the models loaded in memory, and with the /events polling you need load them from DB every time), though if your customer have a long idle periods (especially if you have many customers) webhooks are orders of magnitude more efficient.

Think about Github, there are a ton of repos, but the activity in each is occasional. So if you have CI that needs to be triggered on push, it's much more efficient to be notified when there's a change rather than all 300m users polling all the time (and getting nothing).

It's kind of like a spin-lock: polling is efficient when you get "yes" often, and it's not efficient when you get "no" often. Again, tradeoffs.

This is true. To be honest I was only considering the benefits to the client - if there are 10m client's polling this could mean a lot of server resources for Stripe.

But an indexed last_update_ts could take less than 1ms to query, HTTP connections are kept alive, meaning the server handling the poll is still not using a huge amount of resources.

Keeping all of these connections alive is also not great. Updating them when things change means either polling (so 10m at least once a second) or some complex messaging mechanism.