6 ms·

I loathe the over-abundance of "Optimistic Without Feedback Pattern". It is used as a crutch for "I don't want to bother implementing error cases". Even the pin

by yuliyp 2y ago

I loathe the over-abundance of "Optimistic Without Feedback Pattern". It is used as a crutch for "I don't want to bother implementing error cases". Even the pinned chat example they use is just a bug factory. Stating "this particular API request has almost no way of failing, and we know what the server will return in advance" is extremely naive. The user could have gotten logged out somehow, or maybe there's a rate limit or something, or the server's overloaded, or they're offline and going to use the app on another device that is online before you can sync, or whatever. Assuming the happy path just leads to the app breaking in weird ways down the road.

Spivak 2y ago
> The user could have gotten logged out somehow, or maybe there's a rate limit or something All your examples are retryable errors in which the prescription is the same: "keep the message queued until it's successful." And when all your failure modes are like this optimistic-no-feedback works. If you have non-retryable errors in your failure modes "Bad Request", "Gone" this pattern can't be used.
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
- ben-schaaf 2y ago
  Not being logged in is not a retryable error.
  - Spivak 2y ago
    Sure it is, why wouldn't it be? Keep it stored and queued until they log in again. It's the same as being offline.
    - xbjfk 2y ago
      What if someone else logs in?
      - Spivak 2y ago
        Your local storage, and hence the queue, isn't segmented by user?
- yuliyp 2y ago
  Sure they're retryable. But those retries might never succeed (user wipes their phone or uninstalls the app or logs out or clears local app data or a buffer fills up to come up with a few scenarios. Either the request didn't matter to the user at all, in which case sure whatever, or at some point they're going to discover that the thing they thought happened didn't actually happen.
swah 2y ago
What are the other options?
- marcelr 2y ago
  handle the errors, ideally manually
  - wodenokoto 2y ago
    What error?
- mystified5016 2y ago
  The same options we've had literally since computers were invented. Unexpected and unrecoverable errors are as old as computing. This is not some new field of rocket surgery. You use whatever mechanism is available in your language/framework to catch exceptions or errors, and you handle it. The program should do its best to recover, fail gracefully, and emit a useful message or log. This is one of the core tenets of programming. Again, since the dawn of time.
whoitwas 2y ago
My error buckets and //TODOS with dreams of more refined implementations weren't all that lazy after all.
wodenokoto 2y ago
So what you are saying is that you don't think apps should work when offline?
- yuliyp 2y ago
  Not at all. I'm saying that they should reflect the unereliability inherent in distributed computing rather than pretend it can't exist with such false notions as "retries will fix it" or "this call can't fail"

by yuliyp 2y ago

Spivak 2y ago

> The user could have gotten logged out somehow, or maybe there's a rate limit or something All your examples are retryable errors in which the prescription is the same: "keep the message queued until it's successful." And when all your failure modes are like this optimistic-no-feedback works. If you have non-retryable errors in your failure modes "Bad Request", "Gone" this pattern can't be used.

deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
ben-schaaf 2y ago
Not being logged in is not a retryable error.
- Spivak 2y ago
  Sure it is, why wouldn't it be? Keep it stored and queued until they log in again. It's the same as being offline.
  - xbjfk 2y ago
    What if someone else logs in?
    - Spivak 2y ago
      Your local storage, and hence the queue, isn't segmented by user?
yuliyp 2y ago
Sure they're retryable. But those retries might never succeed (user wipes their phone or uninstalls the app or logs out or clears local app data or a buffer fills up to come up with a few scenarios. Either the request didn't matter to the user at all, in which case sure whatever, or at some point they're going to discover that the thing they thought happened didn't actually happen.

swah 2y ago

What are the other options?

marcelr 2y ago
handle the errors, ideally manually
- wodenokoto 2y ago
  What error?
mystified5016 2y ago
The same options we've had literally since computers were invented. Unexpected and unrecoverable errors are as old as computing. This is not some new field of rocket surgery. You use whatever mechanism is available in your language/framework to catch exceptions or errors, and you handle it. The program should do its best to recover, fail gracefully, and emit a useful message or log. This is one of the core tenets of programming. Again, since the dawn of time.

whoitwas 2y ago

My error buckets and //TODOS with dreams of more refined implementations weren't all that lazy after all.

wodenokoto 2y ago

So what you are saying is that you don't think apps should work when offline?

yuliyp 2y ago
Not at all. I'm saying that they should reflect the unereliability inherent in distributed computing rather than pretend it can't exist with such false notions as "retries will fix it" or "this call can't fail"