-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Write a tutorial about "Build an Autocomplete with Structured Concurrency using Effection in React" #880
Comments
I think we'll start with a more introductory blog post first - We can begin the blog post with an example of 2 retries of a fetch call written in node and from there we can sprinkle in two more requirements involving a timer and the retry limit changing based on the response status code? The additional requirements will make it clear that it would be a pain in the butt to implement correctly and we'll say it's easy with effection and show how it's done. |
Sounds good. Let's do it! |
@cowboyd I wrote the javascript examples of fetching with additional requirements (without effection)
Simple Retrieslet retries = 2;
while (retries > 0) {
const response = await fetch(url);
if (response.ok) {
return;
}
retries--;
} More RequirementsRetry twice but up to 5 times for 5xx error codeslet retries = 2;
let retries_500 = 5;
while (retries > 0 && retries_500 > 0) {
const response = await fetch(url);
if (response.ok) {
return;
}
if (response.statusCode > 499) {
retries_500--;
}
if (response.statusCode < 500) {
retries--;
}
} Retry twice but up to 5 times for 5xx error codes, cancel after 5 secondslet retries = 2;
let retries_500 = 5;
const controller = new AbortController();
setTimeout(() => {
retries = 0;
retries_500 = 0;
controller.abort
}, 5_000);
while (retries > 0 && retries_500 > 0) {
const response = await fetch(url, { signal: controller.signal });
if (response.ok) {
return;
}
if (response.statusCode > 499) {
retries_500--;
}
if (response.statusCode < 500) {
retries--;
}
} |
I don't think so. It would look close to that in Effection because we can easily interrupt any operation; without Effection, there would be no way to stop this code. Even if we use an abort controller, it would run while loop. Maybe if you checked the state of the abort controller on every cycle. Let me do some research. |
return new Promise(function (resolve, reject) {
var wrappedFetch = function (attempt) {
// As of node 18, this is no longer needed since node comes with native support for fetch:
/* istanbul ignore next */
var _input =
typeof Request !== 'undefined' && input instanceof Request
? input.clone()
: input;
fetch(_input, init)
.then(function (response) {
if (Array.isArray(retryOn) && retryOn.indexOf(response.status) === -1) {
resolve(response);
} else if (typeof retryOn === 'function') {
try {
// eslint-disable-next-line no-undef
return Promise.resolve(retryOn(attempt, null, response))
.then(function (retryOnResponse) {
if(retryOnResponse) {
retry(attempt, null, response);
} else {
resolve(response);
}
}).catch(reject);
} catch (error) {
reject(error);
}
} else {
if (attempt < retries) {
retry(attempt, null, response);
} else {
resolve(response);
}
}
})
.catch(function (error) {
if (typeof retryOn === 'function') {
try {
// eslint-disable-next-line no-undef
Promise.resolve(retryOn(attempt, error, null))
.then(function (retryOnResponse) {
if(retryOnResponse) {
retry(attempt, error, null);
} else {
reject(error);
}
})
.catch(function(error) {
reject(error);
});
} catch(error) {
reject(error);
}
} else if (attempt < retries) {
retry(attempt, error, null);
} else {
reject(error);
}
});
}; This is probably the best example of how someone would do this without Effection, Observables or Effect.ts. |
@taras - not sure if @ notifications get sent if it's added in an edit 🤷
Are we talking about just dropping/stopping everything at any point in the code? Isn't the abort controller (in my last example) saying, after 5 seconds, we're going to stop fetching and let it run the rest of the while loop but it won't do another cycle?
So then would the structure of the blogpost be:
|
It's worth a try. The libraries I listed above don't seem to support AbortController explicitly. fetch-retry tests don't have a mention of abort. What do you think about making a small test harness to test the behavior of these different libraries? We can figure out the narrative once we have a better understanding of what the status quo is. |
Updated outline
|
@taras ☝️ |
Yeah, that looks good. I'm going to put together a small test to see how it behaves |
@minkimcello I found an interesting library called abort-controller-x for composing abort controller aware asyncronous functions. Interestingly, they wrote the code the same way you did in your example. The point of this library is that it makes it easy to thread the abort controller through many async operations. We could mention it in our "Need to thread abort controllers to each layer or use something like abort-controller-x to compose abort controller aware async operations" https://github.com/deeplay-io/abort-controller-x/blob/master/src/retry.ts#L44-L93 This is the best example of writing a retry/backoff using an abort controller. export async function retry<T>(
signal: AbortSignal,
fn: (signal: AbortSignal, attempt: number, reset: () => void) => Promise<T>,
options: RetryOptions = {},
): Promise<T> {
const {
baseMs = 1000,
maxDelayMs = 30000,
onError,
maxAttempts = Infinity,
} = options;
let attempt = 0;
const reset = () => {
attempt = -1;
};
while (true) {
try {
return await fn(signal, attempt, reset);
} catch (error) {
rethrowAbortError(error);
if (attempt >= maxAttempts) {
throw error;
}
let delayMs: number;
if (attempt === -1) {
delayMs = 0;
} else {
// https://aws.amazon.com/ru/blogs/architecture/exponential-backoff-and-jitter/
const backoff = Math.min(maxDelayMs, Math.pow(2, attempt) * baseMs);
delayMs = Math.round((backoff * (1 + Math.random())) / 2);
}
if (onError) {
onError(error, attempt, delayMs);
}
if (delayMs !== 0) {
await delay(signal, delayMs);
}
attempt += 1;
}
}
} It looks almost identical to how you'd implement it in Effection except you don't need to manage abort controller manually. |
I just want to make sure that we don't drown out the simplicity of the Effection example by showing too many ways to do it. |
We'll just jump right into the Effection implementation and highlight all the advantages without referencing other libraries. That should simplify the blogpost quite a bit. |
@taras @cowboyd How does this look? https://github.com/minkimcello/effection-retries/blob/main/blog.ts - this will be for the code snippet for the blog post. There's also this file that I was running locally https://github.com/minkimcello/effection-retries/blob/main/index.ts to run a fake fetch. I noticed I couldn't resolve from inside the while loop. Is that by design? |
@minkimcello I think we can make that example much simpler.
|
@taras I was trying to replace the fetch with a fake fetch and test out the script. but I noticed none of the console logs from operations inside |
That is very odd. I would expect it to log... unless there was an error or someone else won the race. |
We figured it out. It's a missing yield in front of race |
wrote the code examples (and not much of the text (yet)) for the blogpost: thefrontside/frontside.com#374 Is that too long? Maybe we can cut out the last part? the |
The autocomplete example's logic is ready. We should now write a blog post about it. The focus should be on describing the pattern of doing autocomplete with SC. The main takeaway is that SC organizes operations into a tree where an operation can have children. One of the rules of SC is that a child can not outlive its parent, we can use this rule to design out autocomplete. We'll build from nothing to a working autocomplete in React.
It's going to be broken up into 3 steps
The text was updated successfully, but these errors were encountered: