Open dac09 opened 2 years ago
@dthyresson and I reviewed it together. Hope this is helpful @chrisvdm
Hi @dac09 + @dthyresson Should've responded to this over here earlier (not 6 months later, sorry)... Again thank you for taking the time to write it up.
After working on the example store I can see the value of the above points much better now. So building an example app definitely helped :) You guys raised a lot of points that I did not think of.
Theres two things Im struggling with atm:
Anyway thats just where my heads at and again sorry for the late response
Hey hey! Feedback re: the PoC.
Is it worth building example apps first?
Maybe one (or different) apps to demonstrate:
a SaaS that lets you subscribe for premium content
https://github.com/stripe-samples/netlify-stripe-subscriptions
Stripe Subscriptions · Learn With Jason
Using Hooks instead?
Setup Process
Basket/Cart Support
The setup command actually makes it confusing because the items are hardcoded. The cart items even if not fully implemented for them, should be:
a) use graphql to fetch the data. i.e. generate an SDL and potentially update the prisma schema
b) give the user hooks/utility functions to add, update, and delete items from their shopping cart/basket
⚠️ GraphQL not used for the session and checkout creation
In terms of mental model, it's also important because Redwood is "schema first". It doesn't make a lot of sense to use a serverless function, without an SDL in place (except in the case of a webhook).
An example of a Redwoody implementation would be:
Lacks demonstration of quantities/seats/variable pricing of a subscription
Lacks demonstration of using Auth and Roles
A common and useful set of features to generate (or atleast guide through) would be:
Success and Failure handling not setup
e.g. of what I would've expected
Should include utilities for management payments/subscriptions
This is often the mysterious piece, and having the plugin hold your hand through this process would be very helpful
Unsure about syntax used in webhook
I'm not sure I personally would implement the webhook handler this way.
a) A switch statement really isn't that bad
b) Should generate enums for the stripe webhook type
c) Its not clear where the verification is handled
d) I'm not sure if there's a lot of value in hiding away the logic in "handleStripeWebhook". It might be better to generate a template webhook handler, and provide specific utlity functions like
verifySignature
,getWebhookType
e) The plugin should generate a service that let's you implement what happens when a payment is successful, and the webhook should call this service function.
This establishes for the developer the "pattern" on how to implement the functionality.
f) No code to handle base64 encoding
g) I would avoid using callbacks
Generate better tests
It would be immensely useful to have tests generated for each of the points mentioned in the "An example of a Redwoody implementation" list. Webhooks can also be tested within Redwood now see https://redwoodjs.com/docs/serverless-functions#how-to-test-webhooks
Not clear on how subscriptions work
I think the example does not really make it clear on how subscriptions are setup, and how they should be used.
Configuration Models / Data Model
Let's give the data model some thought for where users, plans, user → plan, products might be stored.
Similar to DbAuth, we may want to provide configurability to what the "User" model is, as it may not be called User.