Show HN: Open-Source Stripe GraphQL API
nhost.io
nhost.io
1 - https://steampipe.io 2 - https://hub.steampipe.io/plugins/turbot/stripe
I wrote about this here:
This approach is also limited because it won't allow you to do mutations like:
``` mutation { stripe { createBillingPortalSession(customer: "cus_xxx") { id url } } } ```
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/
More specifically, I disagree with some of the points there, it really just depends on your use-case.
Which points do you disagree with?
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.
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.