3 ms·

Each user is making 6-10 requests, in parallel, to the server, instead of 1. My point is that I'd design this to not DDoS the servers if I got a lot of concurre

Each user is making 6-10 requests, in parallel, to the server, instead of 1. My point is that I'd design this to not DDoS the servers if I got a lot of concurrent users.

spankalee 4y ago
Most likely Jake encountered real world cases that really needed to use parallel promises and used fetch() as an example that could fit in a blog. Maybe in the real world it's file or database reads, off-thread parsing, decompression, etc...
- latchkey 4y ago
  Yes, this is why I wrote: > I know this doesn't answer the question of how to deal with the promises themselves I'm trying to bring up a bigger picture here.
horsawlarway 4y ago
that's... not a particularly astute approach. Generally speaking, you're almost always better off with more light requests than fewer heavy requests. Assuming this is static content (chapters) there's absolutely zilch you're gaining by fetching the whole block at once instead of chapter by chapter, since you can shove it all behind a CDN anyways. You're losing a lot of flexibility and responsiveness on slow connections, though. Not to mention - it may make sense to be doing something like fetching say... 5 chapters at a time, and then fetching the next chapter when the user scrolls to the end of the current chapter (pagination - a sane approach used by anyone who's had to deal with data at scale) In basically every case though, as long as each chapter is at least a few hundred characters, the extra overhead from the requests is basically negligible, and if they're static - easily cached.
- latchkey 4y ago
  You didn't read what I wrote closely enough. You just fetch the data you need for the list of chapters. In most cases, it'll just be something like chapterID, chapterTitle and maybe chapterShortDescription. This would be easily stored in db cache since chapters don't change much.

Each user is making 6-10 requests, in parallel, to the server, instead of 1. My point is that I'd design this to not DDoS the servers if I got a lot of concurrent users.

spankalee 4y ago

Most likely Jake encountered real world cases that really needed to use parallel promises and used fetch() as an example that could fit in a blog. Maybe in the real world it's file or database reads, off-thread parsing, decompression, etc...

latchkey 4y ago
Yes, this is why I wrote: > I know this doesn't answer the question of how to deal with the promises themselves I'm trying to bring up a bigger picture here.

horsawlarway 4y ago

that's... not a particularly astute approach. Generally speaking, you're almost always better off with more light requests than fewer heavy requests. Assuming this is static content (chapters) there's absolutely zilch you're gaining by fetching the whole block at once instead of chapter by chapter, since you can shove it all behind a CDN anyways. You're losing a lot of flexibility and responsiveness on slow connections, though. Not to mention - it may make sense to be doing something like fetching say... 5 chapters at a time, and then fetching the next chapter when the user scrolls to the end of the current chapter (pagination - a sane approach used by anyone who's had to deal with data at scale) In basically every case though, as long as each chapter is at least a few hundred characters, the extra overhead from the requests is basically negligible, and if they're static - easily cached.

latchkey 4y ago
You didn't read what I wrote closely enough. You just fetch the data you need for the list of chapters. In most cases, it'll just be something like chapterID, chapterTitle and maybe chapterShortDescription. This would be easily stored in db cache since chapters don't change much.