How to use Nuxt.js for frontend.

[brightchip]

I don't wanna use Meteor packaging system and Mini-mongo/DDP etc...

Because there's a lot of Simple schemas. And many global functions . I find it so hard to completely get rid of Meteor but at lest let me change my Frontend into something else.

How to use Meteor for Server Only? Or how do i define the global function and then i can access it in anywhere of the APP ?

[chris-visser]

I assume with global functions that you mean Meteor methods? The problem with these methods is that they are DDP methods by default. At least almost all of the advantages you can get from them.

About using nuxt. Nuxt is a standalone UI framework. Its great and I would recommend to run it as a separate application from your Meteor app. What I don't really understand from your question is your goal. Are you trying to move away from Meteor? Or just its DDP layer?

My answer will highly depend on your end goal

[ceigey]

Echoing Chris' comment above: really depends on your end goal... and how far you're willing to go ;-) This is a long comment, but I've tried going down this path before so here's my 2¢ (please take with a grain of salt though, I'm not a Meteor veteran of 5+ years or anything).

---

I've tried using Nuxt coupled with Meteor before (using meteor-client-bundler), and it's a constant uphill battle trying to create a cohesive dev experience, so I wouldn't try it (especially with an existing project) unless someone was to put in the time and effort to make a Meteor plugin that uses the Nuxt API directly, or unless you need it (which is what normal users of meteor-client-bundler fall into).

When you try blending Nuxt with Meteor you really start to see how many of your architectural decisions align with the "happy path" of either framework. E.g. I was finding problems running the server and client in the same dev environment and still having users logged in, we were having unexpected surprises in production, and there was no way to really ensure that a future version of Meteor didn't break the entire architecture in a way we could work around without simply staying stuck on an older version.

---

Beyond using meteor-client-bundler and having 2x separate apps: one big problem is that Nuxt (and all its preconfigured goodness) is using its own Webpack configuration and ecosystem of packages while Meteor obviously has its own build system; theoretically you can use Meteor with Webpack (which probably has less caveats), but then you're moving into "building your own framework" territory, which is something you might be better off doing with just normal Vue + Meteor + SSR + PWA setup as a base and then following some Nuxt-inspired conventions (the PWA part could be done without a plugin, it's just a bit fiddly getting a list of assets for the Service Worker to cache I guess).

So, I'd look at the features you like in Nuxt, and see what you can do to emulate them in Meteor (e.g. alternative packages, plugins, etc)

This is all assuming you rely on the isomorphic nature of Meteor.

---

Alternatively, if your Meteor backed is restful (e.g. all HTTP, no DDP), you can go with Nuxt using libraries like swrv (stale-while-revalidate), or even Apollo GraphQL if you want to emulate that "always up to date" reactive data experience. If you can switch out your backend, you could also make use of the MongoDB API for JS (e.g. start writing some atomic transactions without diving into the private _-prefixed API of Meteor collections). Finally, if uses of the Meteor global are an issue, you could mock then with your own global object called Meteor that provides a compatibility API.

You might also want to consider the Vue Composition API for Vue 2. It allows you to interface with Meteor in some really nice ways (e.g. you can update refs with Tracker.autorun rather than having to use the Meteor tracker plugin).

[brightchip]

Thank you for the talking .

I was hardly working on the migration. And i have finished 70% of the project after a week. I'm using Old Meteor Project for the Accounts-system (meteor-apollo-accounts) and Admin usage with the Apollo packages and i created one more Apollo server for Web app data and Moved my Vue app to Nuxt which has everything built-in.

I think it looks pretty good , And i hope the Bundle won't go boom like In Meteor. But atlest with using Apollo, Data transfer will be faster . I'll let you know more after i finish the migration

[ceigey]

That sounds great! Using Apollo for your data layer must help a lot for migrations. In my case we are all-in on Meteor (DDP, pub/sub) so getting one foot "out the door" into the Nuxt world is much harder without sacrificing the developer-experience.

All the best with the migration!

[brightchip]

Hi. Note: I was using Meteor all over the project.

I actually finished the migration week ago .

After switched into Apollo the data for communication getting 4x times smaller than when using Meteor DDP (the main data Was more than 8kb per line ==> now less than 2 kb). The Cpus Seem to be more idle (I didn't really care about this). The Bundle size which i case the most, in my case , no big change from ~360 ==> ~ 280 Kb and I have replaced the moment-timezone to dayjs (I think the Apollo is too occupied ) But it got Webpack 4s automatically Code split which means users won't have to download the whole app after the App gets re-deployed

I also upgrade my server so maybe it's because of the new powerful server. So, the migration is not a must go if you feel lazy or unsure . Meteor is slower but more stable and the community still more alive than others.

[ceigey]

Thank you @RailgunWinjoy for the retrospective, I'll keep this in mind for the future of the projects at my work too!