Meteor project structure and architecture

cmboros · June 23, 2022, 9:41pm

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

coagmano · June 24, 2022, 3:08am

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:

github.com

cult-of-coders/meteor-tuts/blob/master/source/chapters/3/structure.md

---
title: 'Overall Structure'
description: Let's bring it to a degree of order
disqusPage: 'Chapter 3: Structure'
---

So, we discussed about many concepts and we described where to put them. But the thing is,
it doesn't really matter that much, what we describe here are a set of practices, there's no such thing
as the best way, or the way. Whatever you choose, be consistent and try to document it.

To give you an overall image, it will look something like this:

## Standalone

```bash
server
    # This is where you import everything you need on server to start
    # Most likely it will be just: import '/imports/api/server'
    main.js
client

This file has been truncated. show original

bratelefant · June 26, 2022, 2:43pm

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

truedon · June 27, 2022, 3:37am

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.

coagmano · June 27, 2022, 11:55pm

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

truedon · June 28, 2022, 12:31am

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.