At the moment the pricing for APIs is very static. Each request predefined cost attached to it.
For example:
Get a single content 1
Query multiple contents: 1
Query with GraphQL 2
Bulk update contents 5
The goal was to reflect a little bit the costs, but it is difficult because you can make 100 of queries with GraphQL and very expensive bulk updates. So some of the requests are underpriced and some of the are overpriced. But I think it evens out overall.
My idea is to make the pricing more dynamic based on the actual queries and operations. So each update could be 1, each query by ID could 0.5 and then each normal query could be 1 again. These values would then be summed up and used for the costs. Some queries are then cheaper and others would be more expensive. But you could optimize your code for costs basically, which is difficult at the moment.
I like the idea of weighting the billing of requests.
I think that a large contributor to this issue is coming from billing each application separately. If it’s request based, the organization of a project shouldn’t effect billing.
Oh, I wasn’t considering the teams concept, I haven’t actually looked into that yet.
I don’t understand that. You think it should only be based on requests?
Sorry, I was over simplifying in this, let me re-type it… it is related, so maybe it’s also solved with teams?
First, I should of said query instead of request.
I really like this billing idea, and I do agree that each query is not equal to one another. My thought here was about splitting the projects up into individual payments and query limits. If I’m not mistaken, each project has its own billing separate from each other project. This is the organisation that I’m referring to here, where I see the issue is more about this separation for someone with many projects, than it is about the individual query costs, and I’d rather see all costs consolidated across projects. This way, we’d be encouraged to make many projects as opposed to being encouraged to stuff everything into one project. But, this is getting off-topic from your topic goal.
So, back to the discussion.
what are the reasons behind the assigned weights of each operation? For example, why would a query by ID be half the cost of an update, where vs a GraphQL query vs a bulk update? The reasons seem like they could be assumed, but I’m curious on your assessment of the costs.
Nobody asked for that yet and we are not AWS where some people might spend several Millions per month. So it seems a little bit weird to split a 49€ invoice into multiple payments. But you can already configure limits. For example you can configure limits per client and then have one client per frontend to ensure that a frontend A does not eat all requests of frontend B.
It is a simplified heuristic of course. For example: A query by ID is an index hit and therefore a fast query to the database and definitely much cheaper than an update, which also has the disk write. A bulk update is also more expensive than a normal update and so on. But of course we cannot measure how much it would really cost and so even if we make the pricing more fine grained it would be based on assumptions.
Nobody asked for that yet and we are not AWS where some people might spend several Millions per month. So it seems a little bit weird to split a 49€ invoice into multiple payments. But you can already configure limits. For example you can configure limits per client and then have one client per frontend to ensure that a frontend A does not eat all requests of frontend B.
No, that’s not what I was referring to, I was just talking about the high level billing separation per project that is already in place.
It is a simplified heuristic of course. For example: A query by ID is an index hit and therefore a fast query to the database and definitely much cheaper than an update, which also has the disk write. A bulk update is also more expensive than a normal update and so on. But of course we cannot measure how much it would really cost and so even if we make the pricing more fine grained it would be based on assumptions.
Assumptions would be very difficult to get away from, but with them comes a certain level of trust from the customer. I think that’s perfectly fine, as long as the ways that this is calculated are public.