What architecture on Meteor would you use for a new medium sized app?

help
1

Hi guys, I was wondering… I’m going to start a medium sized app on Meteor and with all these changes and news on Meteor, what should I use as architecture? I have a lot of questions haha.

The app has some complex and heavy screens and they need to be FAST. Blaze is not an option… What should I use? React?

As for the router… what is the best option today?

The app for sure will be needing tests. So where do I go there?

Nowadays, do we have an architecture to follow like Mantra was being built before? I see that they no longer updated it…

To sum up, I’d really like to use meteor in this new app… but I need to know where to go on:

  • Front Side
  • Router
  • Tests
  • Best Practices
  • Folder and files structure

Thanks in advance!

2

Do you need real time or not ?

3

All the topics listed above were discussed in the Meteor Guide, did you go through it carefully?

4

Yes, I need real time.

5

Thanks for your reply. I read the meteor guide but maybe not as carefully as necessary. Gonna do it.

6

Me and my team are building a large meteor app for our organisation. Realtime, lots of data, many users. We started Meteor’s old way of structuring a while ago (no other choice). This was basically a package based approach.

We are progressing gradually into meteor’s proposed way of structuring apps as described in the guide. For us this already is really beneficial in terms of not having to re-invent the wheel and also we have more control over the load order and it drastically improved the application’s performance.

7

One of the things I’ve learned is to only use realtime reactivity where it is actually needed. In Meteor it is very easy to make everything reactive, but all great magic comes at a cost. Take a chat-app: For a list of profile-pictures that changes maybe once a month, use the return of a method call to get the list of your pictures once at page-load. And for the actual chat messages, use pub/sub reactivity. The fewer reactive parts, the snappier they will be.

3 Likes
8

I have been using React front end (inc. React Router), mobx as state manager on front end, and Meteor for data management, with Mongo as database. I now reuse this basic pattern on any new apps as it means I can implement an app very quickly. You can see the architecture here:

https://github.com/tomswales/meteor_architecture/blob/master/Realtime%20Application%20Architecture-%20React-Mobx-Meteor%20(1).png

There is an old diagram I made of Meteor 1.3 app structure based on the React todos branch following the Meteor guide. It is still broadly valid:

3 Likes
9

I tend to develop on Windows (because I’m a loser), but my production environments are always Linux x64.

10

The package based architecture is actually very good, and still highly relevant. It helps you make your application very modular, and easy to update or split into services later (https://github.com/TelescopeJS/Telescope/tree/master/packages). There’s nothing stopping you from adapting it slightly, to take advantage of imports, or using ES6 Modules instead of Meteor packages.

Some advantages of package based architecture (don’t mind the file loading order, which should be less relevant today): http://experimentsinmeteor.com/package-based-architecture/

Another straightforward example: https://juststartworking.com/package-based-architecture-meteor-application/

Off-topic: @leosco, you’re not alone, and I’d say, not a loser: https://news.ycombinator.com/item?id=13797042 :slight_smile:

2 Likes
11

I would take themeteorchef.com base as a starting point. It uses react with react-router and is prepackaged with lots of nice goodies and uses proper folder structure

1 Like
12

Except this:

Once you go the package architecture route and your app size increases it will become difficult to move to an architecture using /imports.

The package architecture works very nice, but tooling is horrible. Package imports aren’t recognized by your ide or eslint or other awesome stuff like walibyjs. It’s just not supported outside of Meteor. So I have a love/hate relationship with Meteor packages :wink:

With some discipline you can create nice isolated packages within /imports, but because Meteor won’t force you in that scenario it’s easier to make a mess.

13

You can take a look at one of my project and learn from it, I think it a good architecture for building web apps

14

That’s a very valid point. I was a bit biased by our own use case when suggesttung the package architecture. Our packages are very decoupled, and we use the Observer pattern a lot. Changing some of them into modules hasn’t been a problem in our case.

As for the packages that can’t be migrated in this way, why not rewrite them as NPM packages? You can import anything from node_modules. And one is not so much at risk of creating a mess with NPM, like with modules.

Yeah, I agree, the tooling is terrible with packages.