What is the use case for your billing being directly tied to your front-end, and not the back-end? I'd think that opens up a much larger surface area for security problems?
The use case is just speed of development. We looked at several Billing implementations and found consistent patterns for exposing available plans and subscription management to the frontend.
use-stripe-subscription simply packages one implementation so your frontend team can consume it directly, instead of asking backend teams to reinvent the wheel.
It doesn't just re-expose Stripe endpoints, which would result in significant security concerns. This package clamps down the endpoints so the active customer can only see their own data and modify their own subscription.
Comments
What is the use case for your billing being directly tied to your front-end, and not the back-end? I'd think that opens up a much larger surface area for security problems?
The use case is just speed of development. We looked at several Billing implementations and found consistent patterns for exposing available plans and subscription management to the frontend.
use-stripe-subscription simply packages one implementation so your frontend team can consume it directly, instead of asking backend teams to reinvent the wheel.
It doesn't just re-expose Stripe endpoints, which would result in significant security concerns. This package clamps down the endpoints so the active customer can only see their own data and modify their own subscription.