Redwood Stripe Integration

Here’s one way you could integrate Stripe with RedwoodJS.

8 Likes

Oooh, this is great, really love the example site too!

That was a fun code read through.

Do people like requirePermission over hasRole? I still prefer the idea of hasRole here since permissions (like edit:product often belong to role`.

Also a good example of db user/pwd auth + goTrue.

Thanks. I definitely think you’re right that if I wanted to get more granular with permissions I’d want to use something like hasRole.

If your app has both roles and permissions you generally always want to be checking for permissions and not roles. This way you can shuffle permissions between roles, add new roles, etc, and the code never changes.

A great example is if you offer pricing tiers on your site. You’ve got Basic, Pro and Enterprise. As the app evolves and the featureset changes you may find that Basic users get more and more functionality that used to only belong to Pro. If you’re checking only roles then you’ll have to constantly be swapping out those checks…

if (hasRole('pro') || hasRole('basic'))

But permissions never have to change:

if (hasPermission('inviteUser'))

If you’re using permissions nothing changes—Basic users now have more permissions than they did yesterday. But no code changes! And if you give your Product Manager an admin screen that lets them change permissions on a role you’ll be their best friend for life! :slight_smile:

At my last job we also added Role Limits—it determined how many of “something” a certain role could perform. For example, basic could perform only 10 searches a month, but Pro could perform an unlimited number. So we’d add a check like:

if (!hasPermission('search')) throw new AuthenticationError
if (!underLimit('search'))    throw new LimitError

// permission granted, proceed...

If your app only has roles then that’s all you can check anyway, so disregard the above suggestions. :slight_smile:

2 Likes

Ahhhh, aha! Bookmarking for later.

1 Like

More I think about it, permissions feel like the way to go.

A permission is tied to a feature or set of functionality that is exists in (or was maybe removed from) an “app”.

While “role” or “plan” can change based on Management, Marketing, or Org changes.

It’s not the “Trial” plan it’s “Free” and now not the “Basic” but “Bronze”. Oh and guess what now the “Bronze” role can rename widgets.

Or more current … it’s not the “Master” role, it’s now the “Admin” role.

Would be nice to avoid all the pain of managing “role” changes in code.

1 Like

If you absolutely, positively need permissions right now I wrote up a quick thing in another thread for rolling your own until we come up with a Redwood Way to do it: Best practices for user permissions based on schema relationships

1 Like

Nice one! We also implemented Braintree and Paddle checkouts (subscription based) - it was fairly straight forward but I did have to play around with lazy loading to make sure Braintree’s library didn’t get bundled into vendors.

I’m happy to do the write up if the community wants, but only if the demand is there!

(Cc @dom)

2 Likes