Feature request: metered trials as opposed to timed trials

[kctdfh]

Thanks for the great library! It's amazing for the kinds of single page web apps I build!

One thing I've bumped up against is metering and limited database access for freemium products built on Userbase. I specifically have two use cases in mind, which will hopefully illustrate the need in general.

1) Limiting database writes for non-paying users or those with expired subscriptions

Let's say we have a photo storage app that let's users build albums. Each album is a private database on Userbase. The service would allow a non-paying user to make 2 albums but a subscribed user can make unlimited albums. User Alice creates databases A and B before subscribing. They can read and write to these databases forever.

They then subscribe and create databases C and D. For a month, they add photos to all databases but their subscription expires. Ideally, we'd still allow them to access all of their photos but won't let them write to C and D anymore.

This introduces the concept of database-count-limited trial periods on an otherwise paid service and read-only databases for expired subscriptions.

2) Limiting storage usage per subscription type

For the same service as above, we could have the free plan give the user up to 500MB of storage space. Then another plan for 10GB and so on.

A useful addition for both the admin and the SDK API would be a utilization field. You could get the storage utilization of a single database or a specific user and limit the feature-set based on that.

In this case, read permissions are not revoked. Write permissions are.

The architecture docs mention metering and how the current lack of garbage collection would potentially hinder the accuracy of this measurement but I may be misunderstanding what bundling and garbage collection are.

Would love to hear everyone's thoughts on this metered trial vs. timed-trial freemium discussion! Hopefully the photo album example doesn't come with too much baggage and the use cases carry over to more abstract conceptions of a database.

[kctdfh]

I now remember reading the discussion about webhooks weeks ago and just read over the issue again. This comment is very encouraging and addresses parts of this discussion.

In terms of UX, I think server-side permission checking would be better because we could make the business logic much more robust and potentially use external data sources (e.g. free users can't insert more than 2 items per day on days that it rains in Paris). A server-less function isn't too much overhead for someone like myself who's eager to keep things very simple and contained to the browser.

[sjc5]

@kctdfh, I came here to see if anyone else was asking for this, and was glad to see your feature request.

I would love to implement metered trials (up to X database entries unpaid, forever), with X++ database entries permitted if user is a paid subscriber.

Theoretically there are ways to implement this currently, but it would be a bit hacky and all with user-side javascript code (which would not ultimately be secure because, while annoying, a user could technically edit the javascript in dev tools user-side in order to write additional database entries).

If I'm wrong about any of my assumptions here, please let me know.

Would love to hear from the Userbase team (cc @j-berman, @dvassallo, etc.) whether this is on their radar / roadmap.

Thanks!
sjc

[kctdfh]

Yeah it's possible now but webhooks as described in the discussion I linked in my last comment would solve the permission aspects of it more securely.

Then one of the issues remaining would be a "utilization" API so we can ask Userbase about the total bytes stored in a certain database or in all databases where a given user is the owner. Like this, we'd be able to easily make a request valid or invalid based on the amount of data a user has on Userbase.

Another issue is how paid apps work today. When an app is paid, users can't access their database unless they pay. Making this a webhook based check would be perfect. Like this we can for instance give plan A users read access after their subscription expires and plan B users no access after expiration while having a utilization cap for free users.

I really like the ethos of this framework but haven't fully jumped into a project I want to use it with because custom checks like these are essential.

P.s. They've mentioned that webhooks is on the road map but they seem very busy this past 6 months