Comments (11)
Ideally, if performance is important, you should not be doing compression with Node.js at all, especially since these compression requests are using your available thread pool in Node.js.
Using Varnish would provide exactly what you're looking for.
If you insist on using Node.js to do compression (which I don't recommend if you are about performance), I'm pretty certain there are modules on npm that do compression with caching.
from compression.
Otherwise PRs are welcome to implement this feature and then we can discuss the implementation in the PR :)
from compression.
Honestly I don't get it how you tell me not to do compression on node in a repository about doing compression in node :-)
That confused me a little.
I ended up putting my middleware before compression and I'm using node-cache to store the compressed output (so I'm not compressing it again each time I return it from the cache).
If you think it's a valid use case for this module (to use node-cache I mean since the output is always the same with the same input) then let me know and I'll do a PR.
from compression.
Honestly I don't get it how you tell me not to do compression on node in a repository about doing compression in node :-)
Well, this repo is here for non-production and small sites, because people want it, so we provide it, but it doesn't mean it's a good idea :) We are probably the best one that exists, but that still doesn't solve the fundamental issue of doing this in Node.js in the first place :)
If you think it's a valid use case for this module (to use node-cache I mean since the output is always the same with the same input) then let me know and I'll do a PR.
I'm glad you got something working! I would rather go towards "separation of concerns", where this module does compression and... that's it. BUT if you feel like the solution you're doing is working well, I would 100% be interested in adding an example of using compression + node-cache to the README :)
from compression.
hey guys, caching might be a good idea, but maybe it's better to gzip all your components before the server starts up?
from compression.
In my case that's not possible. I'm talking about an API that returns objects as json. For the amount of time I cache the response from the database I'm caching the compressed output instead of the response from the database, so each time I respond with the cached version I don't need to compress it again.
from compression.
It's 2015, networks are faster and have more bandwidth - I would read the latest information about whether it's really worth compressing JSON responses. I have approximately 3 hours total experience with GZIP and no computer science degree but I would venture to guess it's not worth it to compress JSON responses. You have to compress it on the server and then decompress on the client, that's a lot of computational effort and slows things down.
Furthermore, you are going to have a hell of a lot of extra logic to deal with caching on the server.
Not to toot my own horn but I think it makes a lot more sense to only compress text assets before the server starts up, then you don't have to worry about runtime caching logic which could get pretty nasty and you don't have to lose CPU cycles to runtime compression.
from compression.
That's a fair and valid point. I'm just doing things the way my client wanted me to do it but I guess it will all come down to having a proper test with and without the compression. This is an API that's going to live in Heroku and accessed mostly from the same country so perhaps you have a point.
from compression.
Like I said, I really have no idea what I am talking about, that is just a guess from the brief experience I have with this stuff. If you find good benefits from compressing JSON responses, please let me know, it's just my guess that, especially for small JSON responses, it's not worth it. If you have large JSON responses that are cacheable, then it might be worth it.
from compression.
furthermore, if you are using a cluster of servers / the NPM cluster module, caching makes even less sense. Because the cache on one server won't be the same as the others. You'd have to then use Redis, or whatever, which would introduce lag that you are trying to avoid in the first place. AFAICT, statelessness on servers still rules the day when it comes to using more than one server. I hope that makes sense.
from compression.
You all might find this very interesting:
from compression.
Related Issues (20)
- Setting Vary header although caching is disabled HOT 1
- "drain" event listener leak when using res.once("drain"); can't use res.removeListener("drain") HOT 3
- compresssion doesn't work ,the vue.txt is 2m HOT 2
- Content-Type: application/json; charset=utf-8 No effect HOT 2
- Question: Why this middleware HOT 2
- Corrupted compressed .js-files for Mac OS / Safari -clients HOT 11
- Is compression working when node server is running on a container? HOT 2
- middleware fails when the request has more than 1 values for accept-encoding header HOT 2
- Is compression result cached? HOT 1
- change Transfer-encoding HOT 1
- Why does the data size increase after compression HOT 1
- Force size to be a minimum... HOT 2
- Chunked encoding is broken after using this middleware HOT 1
- Using a current debug version HOT 1
- Deflate backwards HOT 7
- Compression instrumentation (before/after compression hooks) HOT 2
- Angular Not Compressing? HOT 2
- compression not working json payload HOT 6
- Crash when compressing characters like ū HOT 1
- Express returns a non-compliant HTTP/206 response when gzip is enabled HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from compression.