bmizerany

> 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.

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...

Hi! Tier co-founder here.

> 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?

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

I hit reply too soon. Sorry. Regarding robustness: Our tests show we're more robust that than alternative proxy services with smaller feature sets.

We're happy to hear your enjoying it!

If you have pricing questions please email sales@backplane.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.

I added an example for you (although not a "slidding" window): http://godoc.org/github.com/bmizerany/perks/quantile#__examp...

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.

Yes. I use this for that. Query then Reset every 5 minutes.

azmenthe's article covers the problem well: http://blog.tempo-db.com/post/42318820124/estimating-percent...

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.

Great post.

Distributing the computation was quite easy. I emailed the authors of the paper and they gave me a quick answer, which is what I implemented and tested.

I'm interested in adding more implementations of the problem to perks, like Q-Digest, along with other streaming data problems.

Here is a list of all updates to the platform: https://gist.github.com/1000964

Please see: http://xph.us/2011/04/13/introducing-doozer.html

Yes, it is Paxos. We have a post coming up about it.

Sinatra has had etag support for years; longer than Rails (http://bit.ly/9rBLut now http://bit.ly/d3ir1T). Sinatra is well suited for large apps. I suggest using it for them. :)