So what can be done in this situation?
change library or use an external service where to run that code. if you search there are posts about this already.
1 Like
Third option is to treeshake your canvas library / bundle it with your plugin using something like [esbuild](https://esbuild.github.io/). This is an issue I ran into while building a search plugin and treeshaking did the trick (also reduced my action’s execution time from 14+ seconds to roughly 2 seconds).
Only problem with introducing esbuild into your plugin creation flow is that it adds a few steps into Bubble’s already tedious plugin development process (ie coding in VS code then copy/pasting code into the plugin editor). But this - and your overall developer experience - can be improved using the Bask VS Code extension (which I built/is an official Bubble integration).
3 Likes
@dorilama Right, I looked at some old posts, but I wanted to check if there were any new developments or suggestions like the ones @zelus_pudding presented.
Thanks to both of you.
2 Likes
this works for some libraries, but this one specifically needs native binaries that are probably the main problem. you can prebuild your reduced version of them according to your needs but you probably will not be able to use it anyway (unless you use something other than bubble).
of course the benefit of reducing code size for server actions in bubble can have a higher impact than a normal server environment because your code is interpreted by an eval invocation that is slower than using code directly
3 Likes
Indeed, prebuilt binaries are a unique beast to work with. I imagine there’s still a way to treeshake / compile a binary for use in SSAs but compilation adds yet another step to ones dev process. Best of luck!
1 Like
there is a way to compile the native code removing unused functionalities, for example the default prebuild of canvas should comes with support for a lot of image type and you could compile a version that supports only one specifoc type.
the problem is that compiled native code can’t be embedded in the javascript code (the plugin ssa is a function interpreted in an eval function), it requires control over the infrastructure setup that bubble does not expose.
2 Likes
Perhaps I’m a touch out of my depth on this one, but is it not true one can make a paired down binary, publish it on npm, and include it in the SSA that way? The binary would have to be built to target Bubble’s AWS lambda infra and assuming it’s small enough, should just work?
If not, and the “native binary” aspect of it is to blame, the last option would be to pair it down, port to WebAssembly and then publish to npm. Then it could be included like any other npm package.
1 Like
pheraps it is possible to do it the way you describe.
with this library specifically this problem is very common and is resolved using a lambda layer. as far as I know you can’t do it in plugin ssa. here was shared a reply from support about this.
of course mantaining a custom build ported to webassembly and published on npm is probably a lot more effort than move the logic in a suitable infra or looking for alternative libraries. it’s still a interesting point of view that will have a place in my list of things to try 
2 Likes
Ahh, I think I see the issue. Lambda layers are just a convenient way of separating our business logic from dependencies. Any Lambda that can be made with a layer can also be made without a layer.
There are some upsides in using layers, but none of these benefits actually give us, for example, bigger deployment slugs (we’re always capped at 250MB), nor do they improve cold start times.
I recommend checking out this (to dispel a few Lambda myths) and this (for a taste of the compiling process needed to get node-canvas working in a lambda, which again, may ultimately have to be published to/pulled from NPM instead of a layer).
Overall sounds like a bit of mess to get working but should be perfectly possible.
1 Like
I found Charoite Lee’s Lambda layer as an effective way of solving this, and a straightforward way to configure it in our Lambdas.
1 Like
The only other quote you’re missing is:
Any Lambda that can be made with a layer can also be made without a layer.
I’ve linked to Jaime’s walk through which links to Charoite’s layer recipe because it should help guide anyone to create this thing without a layer. Charoite’s is a reference, not the only way (the compiled package will need to be hosted on npm instead of within a layer).
1 Like
I’m sure there is more than one way to do this.
I’m saying that the linked reference uses lambda layers to solve the problem, like a lot of other solutions for this library (as far as I can read online).
I have a feeling that one day I will read a blog post about you solving it in the other way. that will be a nice read
2 Likes
no no no no no don’t tempt me
2 Likes