Regarding request rejecting (Pixela v1.25.0)

[a-know]

Since v1.25.0 of Pixela, requests to the API are rejected 25% of the time.

Please comment with your views on this change.

[craigeley]

I’m a supporter at the lowest level, $1 / month, and I think this is a truly awful idea. Arbitrarily rejecting API requests is a ransom, not a benefit. And obscuring which requests this applies to is even worse. Seriously considering removing my support and not using the service if this stays implement. Can no longer recommend this to anyone.

[a-know]

@craigeley
Thank you for this comment and for your constant support.

I understand well about the comment you gave me. I would like to think a little more carefully about what this change was about.
However, I thought the following points you gave me were right on the money, so I just updated the blog article and published a list of the APIs to be targeted.

And obscuring which requests this applies to is even worse.

Again, thanks for commenting.

[a-know]

In this regard, I've released v1.25.1.
Thank you for your comments and opinions.

[pataquets]

Returning a 503 is a very bad idea because:

• Even from the maintainer's perspective, it might interfere with debugging, troubleshooting and even potential uptime checking.
• Gives a very bad impression of the service: even if due to a known reason, 503 is seen as an error. The unreliability sticls in the mind.
• Still worse if the user trying the service is not aware of the limitations, the service will look like flaky and they'll be scared away.
• Be ready to closely monitor the service. Free users will not report 503 errors because, you know, it's expected.
  I would suggest using the 429 http status (too many retries) instead. It makes more sense, it's more understandable and relates best with the motivation. All the above problems, solved!

Other than technicalities, I think this approach might cause more harm than good. Some thoughts.
I understand that the service has to make some income to keep itself up and running. It's fair and understandable.
I discovered the service some months ago and never used it, mainly because I was just toying around with it and had no specific use case in mind, but I found it appealing and saved it for the future in the "might come handy some day" bucket. Until recently, where I started thinking into a (potential, still not defined) personal use case and then came 1.25.0. Since I was thinking in a hobbyist usage and I don't need it professionally or for business, my reaction was "Too bad, let's move on. I'll search for another service when the time comes." and shelved the personal use mini-project. The main point is: even for a personal/hobby usage, unreliability is a deal breaker and even being the fee ridiculously cheap, it's out for casual or hobbyist use, so pixe.la was out. I don't have any data to back this, but I guess many people might come to the service for non-critical, non-business uses and more as a hobby and maybe later they buy it to keep their existing (or more precisely, evolving) app running or even buy it in their work, for professional use, as they're already familiar with the service. This inbound path is gone. Nobody will invest time to create any test/MVP if the service it's not reliable.

Disclaimer: As of 1.25.1, I'm a 100% user, so I'm not looking to get the service for free, as I qualify. Just sharing some thoughts.

[a-know]

@pataquets
Thank you for sharing your thoughts!

I would suggest using the 429 http status (too many retries) instead.

I see. However, I am concerned that it is not due to too many actual requests.
Wouldn't you be concerned it?

Also, I read with great interest your other statements. Thanks a lot!

At this point, I can only say that Pixela is a service run by me as a hobby, and I do not expect it to be reliable enough for professional use.
So far, Pixela has been excessively reliable. Too much reliability sometimes generates dependence on it.
(BTW, 25% of the time, the error is certain, which is a reliable specification, but is such reliability not required?)

And, actually, we have data showing that new users in the past few years have been skewed toward first-time programming learners.
I believe that APIs sometimes return errors and that one should be prepared for them are very important elements for software engineers. This change is also the result of our thinking about how we can provide real value to Pixela users.

Thanks!

[sktvete]

I get that you want to encourage people to support the project, but making the API fail randomly just makes it feel unreliable. A normal rate limit or usage cap would make way more sense and still get the point across

[a-know]

@sktvete
Thank you for your opinion. I understand you.
However, actually implementing the rate limits and usage restrictions you mentioned is not easy...

And I suspect that these restriction methods will hardly make users want to support (pay) to use Pixela because most users only need to make a few requests to the Pixela API per day. I'd also like to hear your thoughts on this matter.

[sktvete]

Seeing the situation from your position where you want people to pay for your service, I guess it's understandable.