lib: fetch pricing from API #62
Conversation
ghost
marked this pull request as draft
|
Had a talk with @Kjarrigan. We don't have to include We also had the idea to implement a cost estimation function. The best draft for that so far is: # returns a single number
client.pricing.image.estimated_cost('fsn1', size_gb: 100)
client.pricing.server.estimated_cost('CX11', 'fsn1', runtime_hours: 100)
# ...We'd also like to filter prices by resource type and/or region. The draft for that is (as far as I remember): # returns a matrix (represented in some way) of the remaining dimensions,
# e.g. a list of hashes of the resolved matrix
client.pricing.image(region: 'fsn1')
client.pricing.server(name: 'cx11', region: 'fsn1')
# ...Both approaches at the same time do not work together, but they can be combined in multiple ways. Implement # Allow to create a price matrix and then apply missing dimensions on the price matrix
client.pricing.image(region: 'fsn1').estimated_cost(size_gb: 100)
client.pricing.server(region: 'fsn1').estimated_cost(name: 'cx11', runtime_hours: 100)
# ...
# This would raise an exception, because not filtered down to a single dimension
# or alternatively we could also allow to return a matrix of estimated prices for different regions
# But that would mean that sometimes we return a single number, sometimes a matrix...
client.pricing.server(region: 'fsn1').estimated_cost(runtime_hours: 100)Implement # get estimated price (single number)
client.pricing.image.estimated_cost('fsn1', size_gb: 100)
# get price overview, optionally filtered on some dimensions (matrix)
client.pricing.server
client.pricing.server.filter(name: 'cx11')
client.pricing.server.filter(region: 'fsn1')
client.pricing.server.filter(name: 'cx11', region: 'fsn1') # still a matrix, with a single elementTo me, the second approach looks cleaner. It does not have surprises when using it. |
|
Example use for the first prototype. But it still needs work. require 'hcloud'
client = Hcloud::Client.new(token: ENV['HCLOUD_TOKEN'], auto_pagination: true)
p client.pricing.server_types.estimated_cost('fsn1', name: 'cx11', runtime_hours: 300)
client.pricing.server_types.filter(location: 'hel1').each do |info|
p "#{info[:name]} in #{info[:location]} costs EUR #{info[:prices][:price_monthly][:net]} per month"
end
# as a side-effect this also works (no name required in estimated_cost)
p client.pricing.server_types.filter(name: 'cx11').estimated_cost('fsn1', runtime_hours: 300)
# but it feels a bit strange that this does not work (since location is a required argument)
p client.pricing.server_types.filter(location: 'fsn1', name: 'cx11') \
.estimated_cost(runtime_hours: 300)
# this of course works. Nobody would filter for the same location twice in a single line,
# but it might come up when combining filters and cost estimates in longer classes
p client.pricing.server_types.filter(location: 'fsn1', name: 'cx11') \
.estimated_cost('fsn1', runtime_hours: 300)
# this fails, because the filtered data does not contain fsn1 anymore
p client.pricing.server_types.filter(location: 'hel1', name: 'cx11') \
.estimated_cost('fsn1', runtime_hours: 300)
# I'm not so happy that this raises an exception
# (because without name it does not filter the cost data down to a single row).
# But the alternatives are: We sometimes return a number, sometimes a matrix of numbers.
# Or we always return a matrix of prices, which is a bit annoying for the user.
p client.pricing.server_types.estimated_cost('fsn1', runtime_hours: 300) |
|
Quite complex design it seems and currently no need for it, closing. |
ghost
closed this
Pricing is a bit different than the other resource types. It only provides a single API endpoint
/pricing. On this it only returns a single dictionary. All other resource types return an array of resources and have a/<resource>/<id>endpoint for single resources.Our concept of
<X>and<X>Resourceclasses currently maps to the latter concept.I tried two different approaches for a user of our client:
Stick to the same concept as closely as possible. This is the one implemented now.
Only use a
Pricingclass or forward all calls fromPricingResourcetoPricing.The second approach in my opinion would be nicer for a user, but had some complications. Without special additions to the code the client will on each call to
client.pricingissue a new API request. This would cause needlessly many API requests if a user checks a few prices. A fix to this would be that theClienthas to cache some information (pricing or pricing resource). Currently, it just creates a new instance of<X>Resourcewhenever an attribute is called.Closes #28