Transform dynamic imports to static imports

[jankapunkt]

The dynamic-import package does not work with a client-only app, so we need to bundle all imports while building statically.

A similar approach is done by bundle-visualizer. I could provide a PR if there is some alive-ping.

[dr-dimitru]

Hello @jankapunkt ,

Don't think it requires an additional PR to the codebase.
I'd accept PR to the docs with note explaining that if you're building static client bundle, — do not use dynamic imports!. I mean when we build application and we plan to use it as static Client bundled app — we know that we can not use dynamic imports.

And this package pending general update, hope to put my hands on it soon.

Open for further discussion in case if I'm wrong

[jankapunkt]

Thank you for the fast response @dr-dimitru

I am using this package to build a demo application for one of my client-side packages that runs on github.io but the problem is, that the package uses dynamic imports to reduce initial bundle size.

I tried to introduce static imports that are only included when I set a flag in Meteor.settings but then the build of the package always seems to use static imports.

I will try to figure out how to code-split a dynamic and a static version of the same package and will update some of the README here when I found (or not found) a solution.

[dr-dimitru]

@jankapunkt do you think it would possible to pull all dynamic imports as static files, and rewrite import() function to send request to a static file using file map?

Can't find how meteor generates assets for static import 🤔

[jankapunkt]

I haven't figured it out, too. However, we may have a Chance to override the dynamic import to use static require under the hood, since it is not the native esmodule implementation.

[dr-dimitru]

Have an idea for case when building Client only for modern browsers link script with type="module" attribute, in that case dynamic modules would be pulled from Server.

To this moment all my tests were throwing errors... and yes, it requires Server, while this package focus on Client only solution.

I hiope this comment would inspire someone for a solution or spark discussion.

[technicalbirdVayuz]

Hi @dr-dimitru ,

Just wanted to ask, will this package support Dynamic Imports? If yes, then can you share by when we will be able to use it in our projects?

[dr-dimitru]

Hello @technicalbirdVayuz ,

1. You can use dynamic imports as long as there a server to serve the code
2. Implementing this one would require some time/funds investment, unless @jankapunkt got some spare time

[technicalbirdVayuz]

Can you please share an example of this?

• You can use dynamic imports as long as there a server to serve the code

[dr-dimitru]

@technicalbirdVayuz just connect to a Meteor server

[technicalbirdVayuz]

How does it relate to Dynamic imports? Can you please explain

[dr-dimitru]

@technicalbirdVayuz dynamic import(/*....*/) imports code dynamically on demand from a server via DDP

[technicalbirdVayuz]

Hi,

@dr-dimitru Can you share a small sample please? Not sure, where to put code for this

[dr-dimitru]

@technicalbirdVayuz it's just an example. No actual changes in your codebase required.

By default your app will connect to a server address passed into --url CLI option.

To test this locally:

1. Build client app passing local server URL
2. Run local meteor server with --production flag
3. Open index.html generated by meteor-build-client

To be quite honest — I'm not sure about if no.3 going to work without locally running nginx, this is my method for testing. Let me know if that worked for you

[technicalbirdVayuz]

I tried the and steps, it worked.

First of all, I have not used DDP connection as mentioned here but without this its working fine [Instead if I add that code, then I got DDP is not defined]

there is one error also, noe from where It is coming from

Please check:

Also, My idea of using this packageas as an micro Service but using it this way will make it highly dependent on the server, would be great if we can use it as a stand-alone build.

[technicalbirdVayuz]

& Also, If we have to run this way then why should we create a client build. In any case, We need to run the server & server ideally has the client code too.

Please correct me if I am wrong @dr-dimitru

[dr-dimitru]

if we can use it as a stand-alone build.

This isn't possible due to the way dynamic imports implemented. At the moment it serves compiled pieces of code in batches meaning multiple packages and files are served in the single request.

If there will be a way to request packages one-by-one, then we can place all code-pieces as static files under public directory.

Simply replacing dynamic imports with static imports during the building phase won't work either as "dynamic" pieces of code won't be a part of "bundle"

[dr-dimitru]

& Also, If we have to run this way then why should we create a client build. In any case, We need to run the server & server ideally has the client code too.

You can place client build into CDN, or have many servers serving static files and one handling server-part

[dr-dimitru]

there is one error also, noe from where It is coming from

Please check:

This means server return HTML instead of JSON, I'd start with inspecting "Network" tab

[technicalbirdVayuz]

Thanks for the quick response.

Just want to ask one more thing, will it be considered as a microservice if we use it this way as it is not loosely coupled now.

[dr-dimitru]

will it be considered as a microservice if we use it this way as it is not loosely coupled now.

Nope.

Microservice usually focused on performing single task, but doing it very well in the most efficient way. Nowadays this term has broad meaning, so some folks can call it microservice.

I'd just call it backend and static servers

[technicalbirdVayuz]

Ok. Do you have any references where we can use Meteor as a Micro Service?

[dr-dimitru]

@technicalbirdVayuz Meteor is great for:

• Building front-end (compiling files and libs)
• Transferring data between client and server (including reactively)

On the server it's just Node.js, so I'd suggest using pure "vanilla" Node.js to build microservice

[jankapunkt]

@dr-dimitru a little bit off-topic but:

On the server it's just Node.js, so I'd suggest using pure "vanilla" Node.js to build microservice

I agree hre, unless you want some of the Meteor Magic, like Mongo Integration, DDP (to connect with other Meteor apps) or Accounts, then I suggest to watch my presentation on Microservices with Meteor

[dr-dimitru]

@jankapunkt great mention. It seems to me that it only applicable if you're building ecosystem/infrastructure on top of Meteor — then it makes sense to keep micro services on top of Meteor.

In our case we always end up building vanilla Node.js micro services for efficiency and smallest footprint possible. Data between micro services usually exchanged via Database (MongoDB in our case).

Good references can be found at microservices.io