Sounds interesting. There's some great hints here, but a similar solution has to be found for each language as the asynchronous model not available for every one of them. Though, I found out that every disposable IF should be treated separately. As there's no general rule to handle them all in the same way. For example and per your suggestion, the app installation check IMO should happen before starting the server using hooks or something similar. Thanks Mihail !
You could still write this with callbacks, in fact, getUser could be a synchronous callback in some languages, blocking the (green)thread.
The general idea is that you are "scheduling" work for after the asynchronous condition is determined, and keeping a "handle" to the work to know if/when it succeeds. This could be a part of the language runtime, or directly in your application code, where there is more opportunity to retry/batch/time out your pending "tasks".
But yeah, the initialization phase, including critical assertions, is a totally separate story.
For example the way you schedule network actions with an
offline-first/optimistic update system like Apollo, the Firebase client, etc.
Chaining on an actual promise of a network request or filling a stack of "tasks" which will begin sending to the network after a "cameOnline" poll or callback fundamentally represents the same idea: Preparing now actions that may run in the future if conditions are right.
Sounds interesting. There's some great hints here, but a similar solution has to be found for each language as the asynchronous model not available for every one of them. Though, I found out that every disposable IF should be treated separately. As there's no general rule to handle them all in the same way. For example and per your suggestion, the app installation check IMO should happen before starting the server using hooks or something similar. Thanks Mihail !
You could still write this with callbacks, in fact,
getUsercould be a synchronous callback in some languages, blocking the (green)thread.The general idea is that you are "scheduling" work for after the asynchronous condition is determined, and keeping a "handle" to the work to know if/when it succeeds. This could be a part of the language runtime, or directly in your application code, where there is more opportunity to retry/batch/time out your pending "tasks".
But yeah, the initialization phase, including critical assertions, is a totally separate story.
In the second paragraph, are you talking about " job queue " ?
Yeah.
For example the way you schedule network actions with an
offline-first/optimistic update system like Apollo, the Firebase client, etc.
Chaining on an actual promise of a network request or filling a stack of "tasks" which will begin sending to the network after a "cameOnline" poll or callback fundamentally represents the same idea: Preparing now actions that may run in the future if conditions are right.
I see, thanks for sharing your thoughts Mihail 😊