Closed saurabhp75 closed 6 months ago
imo this example needs a rework
it gives a bad user experience because of the multi redirect here https://github.com/saurabhp75/epic-stripe/blob/baffb612ced3d53f53d17681baf31e62a2387b34/app/routes/account.tsx#L30
I don't get the value of wrapping the stripe calls into endpoints https://github.com/saurabhp75/epic-stripe/blob/baffb612ced3d53f53d17681baf31e62a2387b34/app/services/stripe/api/create-customer.ts
finally the duplication of data between prisma and stripe for the pricing plans makes thing complicated and is not what strip puts in its examples
I will fix first two items.
As for third item, there are few points to consider :
The app needs to keep some data locally (which will be synced using webhook). This is essential for better UX and avoid network latency. IMHO this is a pretty standard approach when integrating with payments platform.
The data to keep in Prisma depends very much on the type of products being sold like one time purchases, subscriptions or the one with licences or usage base plans. See item below for the use cases this example handles.
This example provides 3 subscription based products with option of monthly or yearly payments (In USD or Euros). Each subscription variant can be configured with a limit on number of units user can consume.
Do let me know which Stripe example you are looking at for DB schema.
I'm thinking of https://github.com/stripe-samples/subscription-use-cases
have a look at the server for the fixed price subscriptions example. no deduplication of data, the data is stored on stripe and not on prisma: https://github.com/stripe-samples/subscription-use-cases/blob/main/fixed-price-subscriptions/server/node/server.js
Regarding the latency I base my local data on the stripe json seed directly.. but if you have i18n in your app you might go with just i18next strings or a mix of both to get the prices in one place only
Regarding the multi redirect, maybe I don't know if piling up the calls in the same request (for the user) and waiting for all to complete is better user experience. For sure you get a clean browser history but you get a user that might cancel the page load..I went with bullmq to get an async workflow with tigris. Maybe just add comment in the readme or in the file to let the dev know why you chose this solution and what other solutions exist
README updated based on the discussion.
Test Plan
Checklist
Screenshots