undefined | Better HN

0 pointsthe_gastropod2y ago0 comments

But, like, why do you need a 1MB json response? That’s probably either a bad design or a use-case Rails is not designed for.

0 comments

6 comments · 2 top-level

jupp0r2y ago· 3 in thread

It's a paginated list of 1000 objects of 1kb size each. Any nontrivial API will have responses like that.

My entire point was that Rails is not designed for this.

the_gastropodOP2y ago

But you could return the 1000 objects (or less? 1000 records sounds like a lot for any UI to show at once) of 1kb size and allow the clients to request specific pages with a request parameter. There may be applications where you need to ship the full 1M records I guess, but that seems like very much an edge case as far as web apps go.

tauchunfall2y ago

True, you would not return 1000 objects at once to the frontend.

I first thought it's just a backend use-case, where processing 1000 records in a paginated result is common, but the parent mentions "rails", so it sounds like a frontend use-case.

1 more reply

wredue2y ago

1,000 records is absolutely not a lot on modern computers or connections. On a business LAN, this request should take well under a second full latency.

On an average mobile connection, it’s maybe a second or so.

1 more reply

wredue2y ago· 1 in thread

The better question is

“Why would I pointlessly accept this clear case of massive technical debt for literally no reason what-so-ever?”

Rails does not present any sort of promise that go does not also present, so just saying “yeah, I’ll handcuff my app like this cause I feel like using Ruby” is, frankly, absurd.

When you ask the right questions, you never land on Ruby, and that’s why Ruby continues to decline.

Lio2y ago

It depends on the metrics you care about.

Ruby is concise compared to Go though. I like Go and but when I use it I have to accept that I'll write (and debug) at twice as much code as I would do in Ruby.

If you're mostly just loading data into a large fast cache, lines of code may be a more critical dimension than execution speed.

That's how well designed Rails projects work and you get most of what you need straight out of the box.

j / k navigate · click thread line to collapse

0 comments

6 comments · 2 top-level

jupp0r2y ago· 3 in thread

It's a paginated list of 1000 objects of 1kb size each. Any nontrivial API will have responses like that.

My entire point was that Rails is not designed for this.

the_gastropodOP2y ago

tauchunfall2y ago

True, you would not return 1000 objects at once to the frontend.

I first thought it's just a backend use-case, where processing 1000 records in a paginated result is common, but the parent mentions "rails", so it sounds like a frontend use-case.

1 more reply

wredue2y ago

1,000 records is absolutely not a lot on modern computers or connections. On a business LAN, this request should take well under a second full latency.

On an average mobile connection, it’s maybe a second or so.

1 more reply

wredue2y ago· 1 in thread

The better question is

“Why would I pointlessly accept this clear case of massive technical debt for literally no reason what-so-ever?”

Rails does not present any sort of promise that go does not also present, so just saying “yeah, I’ll handcuff my app like this cause I feel like using Ruby” is, frankly, absurd.

When you ask the right questions, you never land on Ruby, and that’s why Ruby continues to decline.

Lio2y ago

It depends on the metrics you care about.

Ruby is concise compared to Go though. I like Go and but when I use it I have to accept that I'll write (and debug) at twice as much code as I would do in Ruby.

If you're mostly just loading data into a large fast cache, lines of code may be a more critical dimension than execution speed.

That's how well designed Rails projects work and you get most of what you need straight out of the box.

j / k navigate · click thread line to collapse