Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
1–10 of 74 posts
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#2At the very bottom he describes the use case. Mobile apps optimize for battery life by preferring one big long request up front rather than lots of little ones as needed. But you only need the first 10% of the data to render the first screen of your app.
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#3Does this require any changes server-side?
I'm using Node.js — with an Express.js router — to power an internal site. We have a few API endpoints which would benefit from this. Does anything need changing when sending the data?
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#4Very cool, but there's one thing I don't understand.
Do you need to stream JSON objects from a server to make this work? You have to get a response from the server in some kind of streaming protocol right?
Or...
Is this just reading the part of the JSON string that it currently has?
I'm inexperienced with streaming, so this might be obvious to some.
EDIT:
Ah, I get it. I was wrong to say it was "streaming". Looks like my second suggestion was the correct one.
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#5Does this require any changes server-side? I'm using Node.js — with an Express.js router — to power an internal site. We have a few API endpoints which would benefit from this. Does anything need changing when sending the data?
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.
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#6Does this require any changes server-side? I'm using Node.js — with an Express.js router — to power an internal site. We have a few API endpoints which would benefit from this. Does anything need changing when sending the data?
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.
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#7Very cool, but there's one thing I don't understand. Do you need to stream JSON objects from a server to make this work? You have to get a response from the server in some kind of streaming protocol right? Or... Is this just reading the part of the JSON string that it currently has? I'm inexperienced with streaming, so this might be obvious to some. EDIT: Ah, I get it. I was wrong to say it was "streaming". Looks lik…
It will work with any JSON but It'll work faster if you write the JSON out a bit at a time.
Consider if you are writing data from a db: you can either collect all the rows together then write them out, or you can write them out one at a time as you get them. If you write one at a time you are in a sense streaming even if you're not using a streaming protocol.
On a slow network reading any http is like a stream because you can use the first bit to arrive without waiting for the rest. The faster the network the less the benefit but it shouldn't end up worse.
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#8Very cool, but there's one thing I don't understand. Do you need to stream JSON objects from a server to make this work? You have to get a response from the server in some kind of streaming protocol right? Or... Is this just reading the part of the JSON string that it currently has? I'm inexperienced with streaming, so this might be obvious to some. EDIT: Ah, I get it. I was wrong to say it was "streaming". Looks lik…
If you've spent too much time in jQuery you might not realize that streaming is supported by the underlying XMLHttpRequest object. The readyState property can be set to LOADING or DONE. Most applications will wait for DONE so they have a complete document to work with. A "normal" payload will be small enough that the lag between LOADING and DONE is tiny, but a big download can definitely be parsed as it loads. Imagine an HTML doc with inline JavaScript. That JavsScript is evaluated as soon as it's encountered and doesn't wait for a page load that may never happen.
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#9This 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.
Re: Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finish
#10This 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-...