5 ms·

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

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/ https://table.dog/blog/stripe/how-to/stripe-graphql/

elitan 4y ago
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 } } } ```
- justsomeuser 4y ago
  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/ https://table.dog/blog/principles/events-are-better/
  - tasn 4y ago
    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.
    - justsomeuser 4y ago
      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?
      - tasn 4y ago
        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.
        justsomeuser 4y ago
        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.
        tasn 4y ago
        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.

elitan 4y ago

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 } } } ```

justsomeuser 4y ago
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/ https://table.dog/blog/principles/events-are-better/
- tasn 4y ago
  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.
  - justsomeuser 4y ago
    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?
    - tasn 4y ago
      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.
      - justsomeuser 4y ago
        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.
        tasn 4y ago
        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.