Meteor project structure and architecture

Hey everyone,

Just wondering what is the project structure and architecture of large Meteor projects. I’m quite interested to see what big Meteor applications like lemlist @acemtp and Qualia @veered use. I’m sorry if is should not have tag you. Do you use MVC, MVVM or any other patterns. All replies are welcome.

Thanks in advance


I always really liked the suggested structure on the (now gone) Meteor Tuts website.
The content is still on GH, so you can build and view it locally: GitHub - cult-of-coders/meteor-tuts: Meteor Tutorials - From Noob to PRO

Specifically the page on structure here:


There’re some very interesting answers (incl. microservices e.g.) in this thread:

Meteor is real simple it’s just client for client stuff server for server stuff and imports for your api and init stuff.

The MVC paradigm of choice is agnostic and entirely up to you although it does run many different templating engines now most people run React and Redux or a variant of it. Which is a State View Event data flow arrangement. I prefer state based it’s just nicer to work with for reactivity and easier to get your head around then MVC. MVC has it’s plus points but for real time it’s kinda lame.

Yeah I think MVC on the client was a mistake. MVVM is already a lot better, but still feels wrong to me.

MVC on the server is quite nice, but with a decent frontend you don’t need Views. So I haven’t used it for years in favour of a simpler layered API->Services->DB approach

Agree, I prefer event state because it fits closer with what a server does and ultimately how a OS’s kernel and processes interact. You have an event queue and state there also.