> Webhooks for critical application paths just seem like a bad idea all around really
Well, put. I've been deep in the Stripe API for a while now, and the invoices API provides up-to-date account status information and what a customer is paying for. This can be referenced as needed and, if desired, cached with some TTL and referenced as the "truth." Then webhooks can be viewed as a convenient way to bust the cache quicker than waiting for the TTL to expire.
It could be better, but it provides the necessary information without relying on webhooks.
> Iterating this on a pricing.json file feels easier.
Agreed. :)
> if we decide to do something like giving the user the possibility of choosing between a monthly or a yearly subscription (with a variable quantity, because we charge per seat). That would imply a code refactor. Would tier.run help us with that????
Currently, plans that are similar but with different billing intervals can best be expressed as two plans like: `plan:pro:annual@0` and `plan:pro:monthly@0`. We're very open to feedback on this approach though.
> Do I set up which features belong to every plan on the pricing.json file, and then consume your SDK on the frontend to only show the tier to a certain category of paying user?
This is correct, limits (if any) are defined in the pricing.json using tiers. These limits may be reported to a browser session via a backend that proxies the limits from the sidecar back out.
> I also saw you want to build your product as an Auth0 action. Would that be used for this use case?
It seems possible. How do you envision the Auth0 action behaving with Tier?
> Currently, plans that are similar but with different billing intervals can best be expressed as two plans like: `plan:pro:annual@0` and `plan:pro:monthly@0`. We're very open to feedback on this approach though.
I think this makes sense because switching between them can be done very easily, just change the string from `plan:pro:annual@0` to `plan:pro:monthly@0`. As long as I can write some client side code that allows me to change if the end user is getting access to `plan:pro:annual@0` or `plan:pro:monthly@0` based on what they select on a UI.
> It seems possible. How do you envision the Auth0 action behaving with Tier?
Sorry, I'm not familiar with Auth0 actions. It was just an open-ended question because I saw someone proposed this on your Slack group.
Hello from Backplane. You can get this on Azure today using https://www.backplane.io with end-to-end encryption to your backends plus a huge chest of other routing and security features. It's free to start. I'm blake at backplane dot io
Backplane easily replaces the service discovery+custom agents+elb+nginx+firewall management code+cert management code+...... so if you have a process instance/scheduler like kubernetes or use auto scalers and want to save time and headaches and stop dealing with all of the above then Backplane is for you. The tunneling also allows us to bridge private DCs and cloud services for those transitioning to the cloud.
Backplane founder / CEO here. I started Backplane because I noticed after leaving Heroku as the first eng hire, then working with users while at CoreOS, that a lot could be done to fix many problems with service discovery, routing, traffic shaping, and network security. If you have any questions or comments, I'll keep an eye on the thread.
The solution is really elegant, cuts a lot of moving parts out of some architectures. Are you planning to publish more specific details or open source packages on h2s?
But for all but the most extreme cases, it's sufficient to just keep all the values in memory until they fall out of your window. Even if you're getting 1000 requests/second, that's still only 300,000 values that you have to store.
There may be a way to implement this in perks/quantiles by adding another piece of metadata for the timestamp. There is a space cost for this, but it may be okay or even opt-in. Maybe I'll look into this soon.
Edit:
I do agree that if you're working with datasets that fit in memory, you're probably better off keeping all the samples to find your percentile and not using this package. In fact, perks will not compress for datasets under 500 values.
Basically, when you have more data than memory and time to sort them in order to find the percentile you're looking for, you need to employ an algorithm that trades rank selection accuracy for lower memory and CPU costs. This package does that.
Well, put. I've been deep in the Stripe API for a while now, and the invoices API provides up-to-date account status information and what a customer is paying for. This can be referenced as needed and, if desired, cached with some TTL and referenced as the "truth." Then webhooks can be viewed as a convenient way to bust the cache quicker than waiting for the TTL to expire.
It could be better, but it provides the necessary information without relying on webhooks.
An example of how we use this API as a form of entitlement checks at Tier can be found here: https://github.com/tierrun/tier/blob/f7c32426d30ca314706ca7e...