FYI the node-gyp that is shipped with Meteor is outdated because Meteor ships npm v6 which is also outdated. For instance, you will not be able to install and compile the sharp library with meteor npm i if you are running the latest version of Python. Instead, you’ll get the following error message:
ValueError: invalid mode: 'rU' while trying to load binding.gyp
See ValueError: invalid mode: 'rU' while trying to load binding.gyp (Python 3.9 compatibility issue) · Issue #2219 · nodejs/node-gyp · GitHub for more info.
To workaround this, force npm to use a globally installed node-gyp that is actually up to date. See https://github.com/nodejs/node-gyp/blob/main/docs/Force-npm-to-use-global-node-gyp.md.
I understand the point. Many things will be fixed this year as it seems. However, my believe is that Sharp should not stay on a Meteor server. Let me use this as example, more or less relevant but I believe it completely makes the point: Debugging high memory consumption for sharp.toBuffer · Issue #890 · lovell/sharp · GitHub
Meteor works best when used to server clients. It is predictable, measurable. The moment you throw something else in the mix you lose predictability and lack of predictability converts into bad experience and raised costs.
Sharp is an image processor and it perfectly qualifies for a microservice position. It works best when used together with cloud storage.
Example: user uploads to AWS S3, Sharp in AWS Lambda processes from the S3 bucket, puts in S3 bucket and delivers via Cloudfront.
@paulishca Indeed. However, I do not think this applies to me because my setup is “everything runs on the local network, all the data and logic is contained in Meteor and its MongoDB instance for simplicity, there is only one user using the app, sharp is only used to resize images to thumbnails”. I am not experiencing any of the memory problems listed in the referenced issue. As a matter of fact, the MongoDB container is using four times more memory than the Meteor container.
Thanks for the advice though, I’ll consider outsourcing whatever sharp is doing once my app hits the service-splitting-worthy threshold.