This seems like it could be used to create a protocol similar to XMPP - which I always enjoyed from the perspective of elegance. I might have a pet project this weekend, thanks for sharing.
No worries. This is my masters dissertation btw.
Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
11–20 of 74 posts
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#12Is it intentional that it accepts invalid JSON?
I ask only because most of the examples on that page would not be valid as the name part of the key:value pairs needs to be quoted.
PS: Don't upvote this, it's a minor detail and the big point about the use-case is far more important than this comment.
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#13This 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 ne…
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 :)
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#14This 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 ne…
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.
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#15Is it intentional that it accepts invalid JSON? I ask only because most of the examples on that page would not be valid as the name part of the key:value pairs needs to be quoted. PS: Don't upvote this, it's a minor detail and the big point about the use-case is far more important than this comment.
Parsing is built on top of Clarinet (see where the name comes from?)
https://github.com/dscape/clarinet
Unquoted JSON in docs is a mistake. I'll take a look now.
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#16This probably won't work if you have gzip on, right?
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#17Java has had good stream parsing of JSON for a while now too. Last time I had to do it, I was surprised to find GSON, the library we were already using, had support for it. XML stream parsing vs. model parsing was a much bigger change.
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#18This 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 ne…
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!
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#19Is it intentional that it accepts invalid JSON? I ask only because most of the examples on that page would not be valid as the name part of the key:value pairs needs to be quoted. PS: Don't upvote this, it's a minor detail and the big point about the use-case is far more important than this comment.
Should be fixed now. Thanks for pointing out.
There's a test explicitly for not allowing this:
https://github.com/jimhigson/oboe.js/blob/master/test/specs/...
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#20Earlier quoted context omitted.
No changes required. It should accept any JSON resource. Having said that, there's a much bigger improvement if you're progressively writing out the JSON rather than doing it in one big lump.
Awesome! I'll investigate how easily we can stream our JSON out.
Its probably not worth changing it if it is eg in a file already, but if the process to generate it is a slow one it might be.