eli-darkly
commented
4 years ago It's true that the main SDK package currently has some large dependencies.
If we were to do it all over again, we would have packaged the Redis integration separately (as we did for the later Consul and DynamoDB integrations). Unfortunately, taking it out now would be a breaking API change, so we can't do that until version 6.0.0. In any case it doesn't account for a very large chunk of the dependencies: its whole subtree is 277K uncompressed.
A much bigger chunk is node-cache and its dependency lodash— about 2.8M uncompressed in all. The node-cache module is there to support some functionality that you're not using, but that again can't be factored out without a breaking API change. Later versions of node-cache do not bring in lodash; unfortunately, they also don't support Node 6.x, which we are still supporting for now (it is EOL, but based on customer usage we often have to maintain support for older platform versions).
I'm not sure what you mean by "a bunch of AWS stuff": the request package brings in aws4 and aws-sign but those are both small packages with no dependencies. As for "a bunch of json schema stuff + ajv", those are also dependencies of request. Its subtree accounts for about 4.8M uncompressed, but request is needed for core functionality in the SDK.
Your thought of possibly stubbing out some modules might be workable; you should be able to completely remove redis and node-cache (including their dependencies: redis-parser, redis-commands, double-ended-queue, lodash, clone) without affecting your use case, as they're not imported directly in the code. But I think a much greater savings might come from running everything through Rollup, to minify the code and remove non-code content— I think that is a good idea for deployment to any environment where code size is a concern at all. Even with compression, unminified Node code can be pretty big and a 1MB limit is not all that much.
joeruello
Is your feature request related to a problem? Please describe.
I'm trying to implement feature flagging/bucketing at the CDN edge using lambda@edge. Visitor edge lambdas currently have a size limit of 1MB of code compressed. With this library as my only dependency, node_modules is over 14MB before and just over 4mb after compression.
Describe the solution you'd like I only really want to use
variationcalls, reading/generating userId from cookie info. It looks like there's a bunch of extra deps, a bunch of redis stuff, a bunch of json schema stuff + ajv that I'm not really using (I think), a bunch of AWS stuff. Plus, ALL of lodash (Probally something downstream).It would be great if these could be moved into peer dependencies or another smaller package without all the bells and whistles
Describe alternatives you've considered I could use the client SDK, but it seems like that would be slower as I would need to talk to LD on every request. I guess I could also look into using rollup/webpack or something and stubbing out the extraneous packages.
Additional context n/a