5 ms·

Another IMPORTANT aside. Very annoying. Backblaze requires an authorize() call to obtain a token before calling any API function. Please see https://www.backbla

Another IMPORTANT aside. Very annoying. Backblaze requires an authorize() call to obtain a token before calling any API function. Please see https://www.backblaze.com/b2/docs/b2_authorize_account.html https://www.backblaze.com/b2/docs/b2_authorize_account.html. This is unlike S3, which simply needs a STATIC API key, and boom, you can access the API. I don't know why you did this, but it is bad developer UX. Is it because tokens are "cool". I see no need to have this concept of tokens for your API. Why I am annoyed: 1) An API operation now requires one ADDITIONAL call. B2 already requires 2 calls to upload a file, and this now means 3 calls! 2) Related to above, this means bad latency. The roundtrip can be significant, especially since you only have 1 data center in California. My users will NOT be happy. 3) My code is much more complex now. 4) It is more work FOR YOU. This means more processing. More resources wasted FOR YOU. More cost. Why would you do this? You are supposed to be lean. Imagine millions of extra calls EVERY day. Adds up. Is there a solution to this? Can the token be cached? If so, for how long. Also, would love to see a reasonable rationale for this? If there is no rationale, then please provide a STATIC approach to access your API. I REALLY like B2, and I wish they could think of developer UX a little more.

d4l3k 10y ago
If you look at their API you'll see that the token can be cached for up to a week. I doubt that having a check if the token is up to date will add much complexity.
- truetraveller 10y ago
  It really does add complexity: -I have to store the cached token somewhere: -I have to do date arithmetic, what if my server clock is incorrect, -if an API call failed, I have to check for an additional error: a invalid token I don't mind complexity when it is needed, but I do not prefer complexity for no good reason. That being said, can it really be cached up to a week? I see "at most 24 hours", which means it could be even less than 24 hours, so there's no guarantee. Please see: https://www.backblaze.com/b2/docs/b2_authorize_account.html https://www.backblaze.com/b2/docs/b2_authorize_account.html
  - loxias 10y ago
    "-if an API call failed, I have to check for an additional error: a invalid token" In general it's considered good practice to always check return values and error codes. Not for all code, but just for the code you would like to work.
  - truetraveller 10y ago
    @loxias. I do not understand your response. Of course one should check error codes. My point is: now there's one more thing that can go wrong and needs to be checked.
  - FireBeyond 10y ago
    > -I have to do date arithmetic, what if my server clock is incorrect, How is your clock inaccuracy in any way the responsibility of a service provider (Backblaze or other)? From certificate expiry to inaccurate logging, and so on, complaining about "what if my clock is wrong, I have to date math in my app!" is precisely "solving the wrong problem".
  - truetraveller 10y ago
    @FireBeyond Did you even read my reasoning? All I'm saying is that there is ADDITIONAL complexity know in relation to the other, simpler static key approach. Not shifting blame on Backblaze for my server clock being potentially inaccurate.
loxias 10y ago
Uh, what's your complaint? Why in the world would you assume that it has to have the same API as S3? I also don't understand your comments about "cool". You need an auth token so that the subsequent API calls, well, know you're authentic... Makes perfect sense to me. Yes, the first API call requires authenticating first but every additional call reuses cached credentials, so no change to latency. I've been using Backblaze to write a for-fun app, using c++ and libcurl, for the last few weeks and I've found it to be wonderful from a developer perspective. Their documentation is short and sweet. They have capabilities to help you stress test your implementation to make sure you handle edge cases! (you can pass an extra flag and it will randomly send errors) That is so amazingly helpful! And to top it off, their support staff is quick and responsive even with technical details. _And I don't even have a paid account_ If you find dealing with this to make your code "much more complex", then as they say "my consulting rates are very reasonable, my email is in my profile". :P (Disclaimer: I do not work for Backblaze, have never given them a dime of my money. So far.)
- truetraveller 10y ago
  I listed very valid concerns regarding why I was upset. I certainly know what auth tokens are. I like there docs, short and sweet. It fits in their lean approach. But, using tokens is much heavier than the easier static key approach.
jjeaff 10y ago
Somewhere on their site, they address this issue. It is part of the reason they are able to offer cheaper prices. By having to request the token first, then upload, this allows them to avoid using load balancers. The less equipment they have to have, the cheaper your storage can be.
- truetraveller 10y ago
  I do not believe this is for the authorize() token issue. Rather, this is relating to the fact that an upload requires to calls: https://help.backblaze.com/hc/en-us/articles/218513487-Is-the-B2-Cloud-Storage-API-Compatible-with-Amazon-S3- https://help.backblaze.com/hc/en-us/articles/218513487-Is-th...
  - skj 10y ago
    No, N uploads require N+1 calls.
brianwski 10y ago
Brian from Backblaze here. > Backblaze requires an authorize() call to obtain a token before calling any API function.... this now means 3 calls to upload a file That is correct if you only plan to upload one file. The "authorize" can be reused for weeks, and so can the upload URL. So if you want to upload 100,000 files, it is 100,002 calls to upload the 100,000 files (give or take). It is true this is slightly more complex than it could be, but in turn this means we don't need to have any load balancers in our datacenter (which in turn makes the cost of the service cheaper and at the same time enormously more easily scalable). The idea here is that your application authenticates, then you ask for a URL to a vault that has spare space on it. Then your application "hangs up" (stops talking with that server) and contacts the vault directly. This means there is zero "chatter" between our vaults and that you are talking directly (no hops) to the vault you are storing your data on.
- deleted 10y ago
  [deleted]
- truetraveller 10y ago
  Thanks Brian. I don't see the mention of authorize "can be used for weeks" in the docs. I see "at most 24 hours". Please see https://www.backblaze.com/b2/docs/b2_authorize_account.html https://www.backblaze.com/b2/docs/b2_authorize_account.html

d4l3k 10y ago

If you look at their API you'll see that the token can be cached for up to a week. I doubt that having a check if the token is up to date will add much complexity.

truetraveller 10y ago
It really does add complexity: -I have to store the cached token somewhere: -I have to do date arithmetic, what if my server clock is incorrect, -if an API call failed, I have to check for an additional error: a invalid token I don't mind complexity when it is needed, but I do not prefer complexity for no good reason. That being said, can it really be cached up to a week? I see "at most 24 hours", which means it could be even less than 24 hours, so there's no guarantee. Please see: https://www.backblaze.com/b2/docs/b2_authorize_account.html https://www.backblaze.com/b2/docs/b2_authorize_account.html
- loxias 10y ago
  "-if an API call failed, I have to check for an additional error: a invalid token" In general it's considered good practice to always check return values and error codes. Not for all code, but just for the code you would like to work.
- truetraveller 10y ago
  @loxias. I do not understand your response. Of course one should check error codes. My point is: now there's one more thing that can go wrong and needs to be checked.
- FireBeyond 10y ago
  > -I have to do date arithmetic, what if my server clock is incorrect, How is your clock inaccuracy in any way the responsibility of a service provider (Backblaze or other)? From certificate expiry to inaccurate logging, and so on, complaining about "what if my clock is wrong, I have to date math in my app!" is precisely "solving the wrong problem".
- truetraveller 10y ago
  @FireBeyond Did you even read my reasoning? All I'm saying is that there is ADDITIONAL complexity know in relation to the other, simpler static key approach. Not shifting blame on Backblaze for my server clock being potentially inaccurate.

loxias 10y ago

Uh, what's your complaint? Why in the world would you assume that it has to have the same API as S3? I also don't understand your comments about "cool". You need an auth token so that the subsequent API calls, well, know you're authentic... Makes perfect sense to me. Yes, the first API call requires authenticating first but every additional call reuses cached credentials, so no change to latency. I've been using Backblaze to write a for-fun app, using c++ and libcurl, for the last few weeks and I've found it to be wonderful from a developer perspective. Their documentation is short and sweet. They have capabilities to help you stress test your implementation to make sure you handle edge cases! (you can pass an extra flag and it will randomly send errors) That is so amazingly helpful! And to top it off, their support staff is quick and responsive even with technical details. _And I don't even have a paid account_ If you find dealing with this to make your code "much more complex", then as they say "my consulting rates are very reasonable, my email is in my profile". :P (Disclaimer: I do not work for Backblaze, have never given them a dime of my money. So far.)

truetraveller 10y ago
I listed very valid concerns regarding why I was upset. I certainly know what auth tokens are. I like there docs, short and sweet. It fits in their lean approach. But, using tokens is much heavier than the easier static key approach.

jjeaff 10y ago

Somewhere on their site, they address this issue. It is part of the reason they are able to offer cheaper prices. By having to request the token first, then upload, this allows them to avoid using load balancers. The less equipment they have to have, the cheaper your storage can be.

truetraveller 10y ago
I do not believe this is for the authorize() token issue. Rather, this is relating to the fact that an upload requires to calls: https://help.backblaze.com/hc/en-us/articles/218513487-Is-the-B2-Cloud-Storage-API-Compatible-with-Amazon-S3- https://help.backblaze.com/hc/en-us/articles/218513487-Is-th...
- skj 10y ago
  No, N uploads require N+1 calls.

brianwski 10y ago

Brian from Backblaze here. > Backblaze requires an authorize() call to obtain a token before calling any API function.... this now means 3 calls to upload a file That is correct if you only plan to upload one file. The "authorize" can be reused for weeks, and so can the upload URL. So if you want to upload 100,000 files, it is 100,002 calls to upload the 100,000 files (give or take). It is true this is slightly more complex than it could be, but in turn this means we don't need to have any load balancers in our datacenter (which in turn makes the cost of the service cheaper and at the same time enormously more easily scalable). The idea here is that your application authenticates, then you ask for a URL to a vault that has spare space on it. Then your application "hangs up" (stops talking with that server) and contacts the vault directly. This means there is zero "chatter" between our vaults and that you are talking directly (no hops) to the vault you are storing your data on.

deleted 10y ago
[deleted]
truetraveller 10y ago
Thanks Brian. I don't see the mention of authorize "can be used for weeks" in the docs. I see "at most 24 hours". Please see https://www.backblaze.com/b2/docs/b2_authorize_account.html https://www.backblaze.com/b2/docs/b2_authorize_account.html