POC Feedback

[dac09]

Hey hey! Feedback re: the PoC.

Is it worth building example apps first?

Maybe one (or different) apps to demonstrate:

• a store that checks out products

• a SaaS that lets you subscribe for premium content

  • a good example to follow would be:

  https://github.com/stripe-samples/netlify-stripe-subscriptions

  Stripe Subscriptions · Learn With Jason

Using Hooks instead?

const { checkout, createCheckoutSession } = useRedwoodStripe()

Setup Process

• no link to find stripe secret key
• no check if stripe cli present. Do we need to have a dependency on the stripe cli for the setup process?
• we cannot assume that the stripe cli exists, and is invoked the same way as macos brew installation process. If the cli isn't detected, maybe prompt the user for the command to run the stripe cli? e.g. docker run --rm -it stripe/stripe-cli:latest
• its not clear why we need to provide these values. The cli should explain that the keys are being added to the .env file
• each key should be appended to the .env file rather than right at the end

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

• this should be graphql request, and implemented as a service

💡 This is important because Redwood by default does all of its authentication through the graphql endpoint.

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:

• a service, Cell and SDLs for querying your basket
• a service, and SDLs for creating a checkout session through a mutation (mutation made available through a hook)
• a service, Cell and SDLs for querying available subscriptions
• services, called through the webhook for handling
  • payment success
  • payment failure
  • subscription renewal
  • renewal failure
  • refunds
  • subscription cancellation
• a service, Cell and SDLs for querying your orders
• a service, Cell and SDLs for querying your subscription

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:

• checking out as a signed in user, and making sure the order gets added to their account details
• use of RBAC to show/hide details based on a user's role
• use of RBAC to control who can cancel, amend or update a subscription

Success and Failure handling not setup

• the success and failure URLs are not configurable
• theres no hooks/utility functions to handle the success response

e.g. of what I would've expected

const { handleCheckoutSuccess } = useRedwoodStripe()

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.

• User and where Stripe User Id is stored
• Plan
• Product/Price/Catalog

[dac09]

@dthyresson and I reviewed it together. Hope this is helpful @chrisvdm

[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:

• how to share schemas
• how to wrap up the different "processes" that would use graphQL (e.g. checkout session creation) but still give users the ability to change queries/mutations so that its easier to use. Maybe a custom hook with the option of updating the default query (hope that makes sense)

Anyway thats just where my heads at and again sorry for the late response