4 ms·

Still not much, realistically 4096 bytes or less. Browsers aren’t as much the issue as they’ve been in the past, but I’ve hit snags with proxies, old servers,

• ethbr1 2y ago
  How does pagination in urls work nowadays? You'd need ~3 bytes to index a reasonable number of pages naively, no? But curious what current art is re: performance optimizations between frontend and backend. Or is it simply page indices?
  • out_of_protocol 2y ago
    If you do limit/offset on database side, page number is enough. Though this doesn't work well for bigger page numbers. There's other ways to do pagination, e.g. with "cursors", where cursor is simply id of last record on previous page. SQL query is very efficient, but jumping to page X is impossible. In this scenario storing cursors for past pages is needed
    • cess11 2y ago
      There are libraries for Ecto that help with this. https://github.com/duffelhq/paginator https://github.com/duffelhq/paginator
      • sph 2y ago
        Careful that this library last I used it (2020 or so) used a particularly insecure encoding of the cursor that basically allows remote execution. Not sure if they ever addressed it. Here's the fork I created at the time to work around some of these issues: https://github.com/1player/paginator https://github.com/1player/paginator
        • cess11 2y ago
          Thanks for pointing that out.
        • ethbr1 2y ago
          Thanks to thread for the informative responses! (And the useful README on your fork/the upstream) I try to assume someone's thought of better than the best I could, or at least learned the hard way what edge cases need to be handled.
        • gregors 2y ago
          This looks like it was fixed * https://github.com/duffelhq/paginator/blob/main/lib/paginator/cursor.ex#L9 https://github.com/duffelhq/paginator/blob/main/lib/paginato... * https://github.com/duffelhq/paginator/blob/main/test/paginator_test.exs#L830 https://github.com/duffelhq/paginator/blob/main/test/paginat...