Hi! 
I’m at the stage of system planning for the real estate company.
The system will include properties, developments, enquiries, property management, clients, documents and so on.
I’m thinking of using a Meteor.
Does anyone have experience in building a large application in Meteor?
Is it good idea? What are the limitations?
I would like to discuss it.
Thanks!
Many people here have build large applications with Meteor. Large can also mean different things, as a large user base, many concurrent users, many data to store, many data to process, much I/O, many use cases, many calculations for example for image or video processing. If you can break down your needs to individual tasks where you are in doubt likely different people can share their experience.
Even though Meteor is an opinionated Framework and gives clear recommendations in it’s extensive documentation people use Meteor as a basis to build software in many different ways. What makes your system large?
Thank you for your answer @softwarerero
Good point, after a deeper analysis of the system will not be so large.
My application will have few concurrent users (max 40), many logs, many graphs (data to process), 8 user roles, simple image upload.
The application need reactive dashboard and notification system.
What I’m afraid is that the application take long time to build while development, after coding all the functionality.
My applications do a similar thing. There is no load issue if you manage the imports functionality of meteor like how its described in the guide. With meteor 1.5 dynamic code imports can be done, this will further improve the experience.
Also try to re-use templates as much as possible
Thank you for your advice @cloudspider
I intend to use 1.5 release, GraphQL (Apollo) and React for reusable components.
Was there any constraints or big issues according to your application in Meteor?
What was your Application Structure? Do you use mantra, redux and so on?
I have a few similar apps, and I typically use a larger ‘modules’ approach:
/imports
/users // a module for all user-management related stuff
/both
/client
index.js
/login // Login, SignUp, ResetPassword, ...
/admin //pages and forms for admin users
/server // contains methods for adding users, ...
index.js
/todos // a module for handling my todos
/both/
/methods // Methods called both by client and server ( optimistic ui)
/addTodo.js
/todosCollection.js
/client
index.js
/ TodosList.js
/ Todo.js
/server
index.js
/methods // server-only methods
todosPublication.js
todosSeed.js // seeding initial dB
/anotherModule
/both
/client
/server
...
/components
/client // common shared components, like <MyConfirmButton />
/server
To bootstrap everything, I have a /client/index.js and server/index.js file above the /imports folder, which calls an index.js in each of the modules client and server folder, which in turn load all of their modules components. So with one client index.js and one server index.js file, I control as many modules as I like.
It’s not mantra, but it scales pretty well.
Redux: Nah, overkill. I use it for managing state in some React-Native apps. But in a Meteor app there is actually very little global state you have to manage yourself. The one thing it is mainly used for is handling user-state ( logged in or not, username), and this is something Meteor does already ( Meteor.user().profile.name ). React let’s you keep state locally very easy with setState on the main component of that module. The rare occasions I do need some global state, I pop it into the URL as a queryParam. Flowrouter lets you get and set queryparams on the url without triggering a rerender. And you can bookmark or email a link with state easily.
I just got hooked up with Meteor Galaxy hosting and mLab for mongo DB hosting.
This thing can scale to the moon. Come check out my current work at www.SkyRooms.IO running on the above platform. It’s one of the most difficult things I’ve had to learn, but damn, this is the way to go.
Very good advice, thank you @eleventy
So in /client/index.js and /server/index.js you just import modules?
Could You share with me this file?
Thank you @SkyRooms but I have blank page on your demo (skyrooms).
Just to be clear, with “modules” I mean the larger independent subsections of my app. For example, suppose you have a user section, a todo section, a chat section, and so on.
All files in Meteor are automatically loaded upon startup, except those in an /imports folder. Those you have to load explicitly.
In this case, the following happens:
/client/index.js:
import '/imports/users/client'
import '/imports/todos/client'
import '/imports/chat/client'
...
This file is automatically, eagerly loaded by Meteor on startup. This loads all index.js files in the users, todos, and chat folders.
/imports/todos/client/index.js:
import { Meteor } from 'meteor/meteor'
import React, { PropTypes } from 'react'
import Todos from './Todos'
import todosCollection from '/imports/todos/both/todosCollection'
...
The same for /server/index.js. So by adding or removing 2 lines of code, you can add or remove whole sections of your app.
Hey yeah, the demo meeting page is going up tonight. Work In Progress.
@eleventy
Where in your structure is the place for actions?
For example, if you click send on your form - where data goes and where you call Meteor.call()?
Methods are typically stored in …/both/methods/, for example /imports/todos/both/methods/createTodo.js.
Unless they are server-only methods ( like sending emails), then they go in …/server/methods/
in /imports/todos/clients/Todos.js, you have something like
...
import createTodo from '/imports/todos/both/methods/createTodo'
...
export default class Todos extends Component{
...
onSave = () => {
const todo = {
title: 'my title',
content: 'my content'
}
createTodo.call(todo, (err, res) => {
if (err)
console.log(err.reason)
else {
FlowRouter.go(`/todos/${res.id}`)
}
})
}
...
}
I use these as non-reusable, statefull higher order base components of my app. These are the bread and butter of that specific module, and contain the specific logic. They themselves contain a lot of reusable stateless components, which are housed in /imports/components/...
If you wanted to reuse them, I suppose you could inject the method into the component(<Todos onSave={onSave}/> )