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
Use heic-convert npm package to process images #3
Conversation
- Spawn one child process per request and convert images sequentially
@boutell I could use some help testing this with apostrophe. I believe I have to:
Correct me if I'm wrong. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great to me! As for integration testing with apostrophe, the easiest way would be to npm link both this module and apostrophe in your project, and patch lib/modules/apostrophe-attachments/index.js to add this middleware as self.expressMiddleware in that module. I don't mind doing that test if you prefer.
The only "change" I'm requesting is that you update the documentation to address the change (no more need for tifig).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
Will this build on Windows? Any idea? Will it build if a compiler is not available on Linux?
If we're not sure about those things, or the answers aren't ideal, I can wrap it as an optional dependency in apostrophe, and we'll bump the major version of the middleware because the requirements will have changed. In practice most people will have a compiler available when installing npm packages.
Good questions. I was looking at the dependencies from That being said I think it's reasonable to wrap it as an optional dependency as I haven't tested it on windows. |
If it's prebuilt webassembly code windows should be fine. No need for optional dependency. |
Spawn one child process per request and convert images sequentially, avoiding blocking the main thread.
Note that there are many possible ways to use child processes (worker.js instances) here:
In the end I ended up using one worker per request because I think it's flexible enough to scale with the server load but without unnecessarily straining the cpu like one worker per image would.
For a comparison of how those different approaches work (except for the worker pool) you can try the
benchmark_test.js
file on this branchcloses #2