Hacker News Reader

Comment by sequoia | Hacker News Reader

This looks really cool! I'm confused about the usecase, however. In your foods/nonfoods example[0], it allows you to request a some JSON with 2 keys, `foods` and `"nonFoods"`, each with an array value, and use only foods, discarding nonFoods. You request this from oboe('/myapp/things.json')

My question: why not modify the backend to accept a request like `/myapp/foods.json` and let the backend compose the json you need & send only that? It seems like fixing it "in the wrong place" to build your frontend to accommodate getting the wrong/too much data. Is this a contrived example that isn't the core usecase? This is my assumption.

Is this primarily for 3rd party APIs and legacy codebases where it's impractical to change the response type & updating to e.g. sockets is impractical? Thanks for the cool project, I apologize for my ignorance wrt whatever points I'm missing!

[0] https://github.com/jimhigson/oboe.js#using-objects-from-the-...

View on HN

I suppose the example is a little artificial. It isn't really for using some of the JSON response while ignoring the rest (well, you can use it for that but it isn't the main use).

I got the idea for this project working on data vis. Not all of the data was visible and we wanted to display the first bit of data quicker without waiting for all of it to arrive. We could have just sent the visible bit but it was good to have some data ready in the off-screen section for when the user scrolled.

Before that I worked on a service where we were aggregating 6 or 7 services into a single JSON. Some of the services were quicker than others but because the AJAX lib we were using waited for the whole response they all had to go at the speed of the slowest component.

We could have done multiple requests but it was more elegant to serve a whole page's json in one call. Also, we cached the slow services so they were only sometimes slow.

> well, you can use it for that but it isn't the main use

Actually, you could use it for that, as long as the library actually finishes downloading the file on abort. If you need contents from the file again, you just download it again and as it will already be cached, that operation should be extremely fast.

You might need "nonFoods" sometime later but not right now at the start of the app. But instead of making 2 http requests you just make one, but use the thing you actually need as soon as it's available.

If you scroll the README file to the bottom you'll find some good use cases that explain it better than I just did :)

Yeah! There are more understandable examples further down. suggestion @joombar: since the first example is the first thing people see and it doesn't actually reflect the core usecase, perhaps add a note explaining that the example is contrived for simplicity's sake ~or~ make the primary example represent the core usecase more closely. Cool project!

Hmmmm, yeah. Use cases doesn't take up much space, I'll put that before examples because it explains better what it is for.

OH yeah!! Those user-story style use cases really help clarify what it's for in a clear succinct way. Thank you!! (I wish all projects would do this)

I am often consuming API's that I have no control over, and this is great for that use case.

Reply on news.ycombinator.com