Meteor 1.8.1 client and server directories in packages

#1

For a long time, Meteor has been offering the possibility to build very large, truly modular applications with its unique packaging system. With ES6 modules, dynamic imports, and separated server and client code inside packages, there is almost no limit to the modularity and pluggability which can be achieved in a Meteor app.

The architecture envisaged and proposed by @sacha in Vulcan, and which depends on the packaging system, is a truly unique way of building apps. In our view, it trumps micro-services when it comes to large applications. For a very simple visual of what one can do with this architecture, have a look at micro-frontends, under Organisation in verticals. Just think of the possibilities!

It was simply too good.

Meteor 1.8.1 does not treat the client and server folders as special anymore, which makes development of client code in packages more difficult. A lot more difficult if you have many packages. :frowning:

It would be a real shame if this ability was taken away for good. We looked a while back at using NPM packages as a replacement for Meteor packages in this architecture and it’s just not the same. For complex Meteor apps (I would say complex apps generally), the package based architecture is one really neat solution.

#2

It’s true we use a package-based architecture, but we don’t rely on the client and server folders being treated as special. We just do:

  api.mainModule('lib/server/main.js', 'server');
  api.mainModule('lib/client/main.js', 'client');
#3

That is exactly what we do also, but after the pull request mentioned in my original post, a client-only code change triggers a server rebuild. Hence my complaint that it makes development harder.

The behaviour is described in detail in this issue.

#4

Oh ok, got it. Although in our case we (almost) don’t have any client-only code since Vulcan supports SSR and all code is shared.

#5

That makes the rebuild time worth it, I guess. In all other situations, it’s a bummer

#6

Here’s how I would prefer to fix/restore this behavior: https://github.com/meteor/meteor/pull/10414#issuecomment-481293530

#7

That actually doesn’t seem to work, as described here: https://github.com/meteor/meteor/pull/10414#issuecomment-481313792

#8

@illustreets I wasn’t saying it worked, just that it should work, and I will make it work in Meteor 1.8.2: https://github.com/meteor/meteor/pull/10414#issuecomment-481320587

For example, if we get this right, and you change a file in your application’s imports/ directory that we know is only used on the client, even though it’s not in the client/ directory, Meteor should be able to do a client-only refresh (without restarting the server). The same logic would apply to packages.

In general, I want to move away from magic directories and use the information that’s already embedded in the module dependency graph.

7 Likes
#9

@benjamn Thank you for clarifying this! Now it all makes sense. Good to know it is a known issue.

This is very good news. It will allow, among other things, a much easier transition from packages to standard ES6 modules and back.

2 Likes
#10

After this is all sorted out, it would be nice for a comprehensive explanation of how to structure our applications again. I’m on Meteor 1.8 and still have client/server directories (and make little use of the imports directory).

The application is on Blaze, but I’m migrating to React now. Amazing Meteor 1.8 still works with my code from years ago by the way.

I’d like to jump to a situation where I don’t have to use an imports directory. I don’t see what’s so wrong with having a server/client/both directory and inside each making everything modular with imports like is the case using a standard bundler like Webpack for example.

I don’t use a “Packaging” system as some rave about, I don’t see what the big deal is and why some are adding another level of abstraction. Just to split the codebase up for farming out code chuncks for development? Are you guys making a bunch of small projects and just linking them into a “greater” meteor project for bundling? If so, seems overkill.

If you move to micro services, usually they’re totall separate, could stand alone, chunck of functionality that “talk” via a web API or the like. I’d like someone to explain what micro services mean in the Meteor context, are you building separate micro services “Packages” that communicate via Meteor Methods?

#11

In my case, i am using packaging system because my client code base is web and cordova in the same time, so i separate each logic in a different package to avoid having web code in cordova ( mobile ) app and vice versa.

#12

I have an app that still uses Blaze, and it still uses the magic folders, with eager loading, and all that.

My more modern react apps all mostly use the imports directory, though I still find it useful to place my entry points and other configuration in the client and server folders. I had played with moving everything to root, but that got messy, and decided to simply leave everything in classic folders, and it’s pretty clean that way. Inside the imports directory things are organized like many react apps - api, ui, and utils folders at the base, and then appropriate things where they go, etc.

Occasionally, I do create a local package. This is useful for example if you want to have a single import location, which works for both client rendering and SSR, but want to provide different API compatible libraries for client and server. I do this in my data tier, which is offline first, and built on top of Meteor methods, to bypass the overhead of pub/sub (which I only use sparingly for cases where I do need realtime). But most stuff lives cleanly in the imports directory.

1 Like