Continuing the discussion from Last 3.4-beta.14 Release, Faster Builds, Smaller Bundles and Modern Setups with the Rspack integration 
:
Hi all,
So I keep getting the following error when I try to deploy Care Commons using the new RSPack builder.
Error deploying application: Application is too large (maximum 367001600 bytes). Consider moving static assets to a separate static hosting service.
Could we brainstorm a little bit on how to audit the build and deploy pipeline? I’ve read the documents, and have been looking at the _build folder, but it’s only 102.4MB
That obviously doesn’t seem to be the entire story for what’s deployed to Galaxy when I run meteor deploy ....
Between here (the _build directory) and there (Galaxy), what else is happening with the new RSPack/SWC tooling?
1 Like
I have asked the Galaxy team to be more flexible with the size limits. You should be able to deploy your app even using that amount. We’ll back with an answer.
I understand that your project may be using a lot of native dependencies bundled in the final production build, and this is normal. Is it the case that you migrated to Rspack and added new setup to your app? Or do you have the same version of your original app in Meteor 3.3 just migrated to Meteor 3.4 Rspack?
One way to compare sizes is to build your app with meteor build --directory <path>. I have used this in the past to see the final contents that will be deployed to the host service (includes all your app code + packages + native deps, and all needed for production). It is also a way to get outputs from different versions of your app, and then use a tool to diff your bundle directories (I use WinMerge for this, but there are other options for other OS). This lets you see what each version adds. If in Rspack you have added new dependencies and an advanced setup, it is likely that many native deps are making your bundle heavy.
Again, this can be normal as you have more possibilities with the bundler to have large bundles, especially because, as you posted in other post, you are using advanced technology in the medical domain, making full use of Workers, GPU and advanced setup.
Note: Are you using beta.14? we also delivered some production optimizations for bundle size. Though your app may having heavy size that should be deployable.
Ooops. That would explain it.
Yeah, this one is on me. I did a local build with all of the functionality to get a Radiology Information System through ONC HealthIT Certification, and it’s sitting at around 400K lines of code, and compiles to around 2GB.
All things considered, I think competitor projects in Java and C# are actually quite a bit larger. So on the one hand, this is fairly slim for what Radiology typically is accustomed to. And on the other hand, we didn’t include a local LLM or anything. On a local box, we would have another 200GB to 500GB or more of language models, reference images, etc. That would be content to be shipped via Electron or in an App Store bundle. But we still need to deploy the server.
I tried building with the --server-only flag, but it came out to the same size. The custom coded React user-interface isn’t all that big, actually. That’s what’s staying under 100MB. It’s all those imported libraries to provide the DICOM viewer, AI connectivity, 508 compliance for accessibility, etc. I can probably trim 200M to 300MB by ditching the ONNX subsystem. But it’s still going to sit near 1.8GB.
We could try hosting on AWS on a dedicated box. In some ways, it would give a cleaner HIPAA story; but we would lose sticky sessions and horizontal scaling and have to re-implement (ug). I’d sort of like to operate under 21st Century Cures if I can, and position the Care Commons product as requiring a Galaxy Enterprise license for full HIPAA compliance.
Hmmm… need to think on this…
ps. Still on beta-12. Will upgrade to beta-14, to see what happens. But I think this is just a honkin large project.
