Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is this module unnecessarily parsing JSON? #74

Open
PradatiusD opened this issue Aug 18, 2015 · 3 comments
Open

Is this module unnecessarily parsing JSON? #74

PradatiusD opened this issue Aug 18, 2015 · 3 comments

Comments

@PradatiusD
Copy link

Hey Raoul!

Quick question: now that the 7Digital API is providing JSON output for parts of the catalogue API, does the module now support the updated data schema's or does it still just parse XML to JSON?

The reason I say this is because now the module is doing unnecessary parsing, as of my version 0.34.2. I'm just curious if there are plans to resolve this issue, so that the module can perform more efficiently.

Thanks,
Daniel

@raoulmillais
Copy link
Contributor

If I remember right it does parse XML on some endpoints that also support JSON. This was because the structure is subtly different and we don't want to break existing consumers. A major version (1.x.x) release will happen when the client can support POST/PUT ing JSON. At that point we can use semver properly to indicate breaking changes (via a major version number bump)

@raoulmillais
Copy link
Contributor

We've found on the 7digital.com web store, which makes ~2500 API requests per minute, that our application is heavily network bound and the CPU usage is relatively low.

That said XML parsing can become a bottleneck if making lots of concurrent requests for big documents (e.g. search with a big pagesize). We found it was a problem in one place: prefetching entire user lockers (in batches of parrallel requests) under load.

I suspect that's unlikely for a mobile application, but I'm guessing you're concerned about battery life? If you do find hotspots then you can use the technique we used to override the content type by specifying custom headers:

var api = require('7digital');
api
  .User({ headers: { Accept: 'application/json' }})
  .getLocker({ userId: userId },  console.log);

The JSON support is still very beta and subject to change - so if you do use it you run the risk of things breaking in the future. This is not so much of a problem for us as we can roll out updates quickly to our web applications, not a luxury you have on mobile. Proceed with caution :)

Hope this helps.

@PradatiusD
Copy link
Author

Thanks for clarifying Raoul and for giving me the detailed explanation!
Feel free to keep this issue open or closed.

On Wed, Aug 19, 2015 at 10:41 AM, Raoul Millais notifications@github.com
wrote:

We've found on the 7digital.com web store http://www.7digital.com/,
which makes ~2500 API requests per minute, that our application is heavily
network bound and the CPU usage is relatively low.

That said XML parsing can become a bottleneck if making lots of concurrent
requests for big documents (e.g. search with a big pagesize). We found it
was a problem in one place: prefetching entire user lockers (in batches of
parrallel requests) under load.

I suspect that's unlikely for a mobile application, but I'm guessing
you're concerned about battery life? If you do find hotspots then you can
use the technique we used to override the content type by specifying custom
headers:

var api = require('7digital');
api
.User({ headers: { Accept: 'application/json' }})
.getLocker({ userId: userId }, console.log);

The JSON support is still very beta and subject to change - so if you do
use it you run the risk of things breaking in the future. This is not so
much of a problem for us as we can roll out updates quickly to our web
applications, not a luxury you have on mobile. Proceed with caution :)

Hope this helps.


Reply to this email directly or view it on GitHub
#74 (comment)
.

Daniel Prada
954-990-9846

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants