Collection schema class library

help
1

Hello All,

I want to build a system that will consist of two (or more) Meteor applications: An administration application and a user application. Eventually, there will be a third mobile user app.

What’s the best approach to have a common schema library for the collections that these Meteor apps will share? I want to avoid code duplication and maintenance headaches.

Thank you.

2

Meteor specific options:

3

@rjdavid Thank you for your answer.

I already use meteor-simple-schema. What I’m talking about is what’s the best way to organize code. Is it better to leave all schemas and/or collection in a different directory and reference them from the Meteor project? Is it better to use symlinks? Will the projects build correctly in those arrangements?

Cheers.

4

Our team uses git subrepo, which works for us, but it has quirks and a way to use it properly. We currently have six separate meteor apps using the same collections using this tool. It is not perfect and requires some discipline. But for our use cases, the benefits far outweigh the shortcomings

5

Ok, you might not need the same schemas …

I have 5 Meteor projects sharing multiple MongoDB Clusters.

  1. Social - this has the full schema of Users and partial schemas of Communication (Chat)
  2. Chat - has full schema of Profiles, Relationships, Discussions and partial schema of Users
  3. Business - has full schema for Business Owners, Clubs, Competitions, Groups, Teams, Schedules etc, and partial schema of Users and Profiles
  4. Cycling - has full schema of Cycling info assets and partial schema of Users, Profiles, Clubs, Groups etc
  5. Communities - full schema of Communities and other urban level units (Developers, Areas, Building) and partial schema of Users, Business Owners, Activities etc.

What works best for me: in ecosystems of projects, 1 projects tends to be “master” and there is where I have the full schema. As I start using DBs between projects, on the “slave” projects I only define the minimum necessary schema based on the master schema because I don’t need Cycling to alter Users or to read user details, I don’t want Chat to read or write bicycle inventories but only cycling events and so on. Schema on the master gives me the full picture of the DB and the partial schemas are good for maintaining security, they are “granularly” written with the Meteor Method in mind instead of having the full DB view.

I use design principles for schemas rather than repos or file locations.

6

@paulishca Thank you for your answer.

In your arrangement, does it mean that if you need to change a schema, you might need to update several files?

7

Not necessarily. Will express this in a different way.
A schema in a master project is my reference schema. In a “slave” project I (indeed) can have CRUD operations on the master project DB. With Validated Methods, I don’t need the whole schema of a DB to make an insert or a read. Only those fields required for a CRUD operation will be part of a “slave” or partial schema. In a slave project I should not really need to add extra fields that do not exist in a master project schema. All slave project use partial subsets of the main schema, limited to only fields that I use in the slave project.
I know you try to understand how you should organize files but on that I have no recommendation. My recommendation is only to not use the same schema in all projects if a project only requires access to certain fields.
If my Profile object in Project 1 has 25 fields and in Project 2 I only need (to read) a display name and and avatar, the Profile schema on Project 2 will only have 2 fields to validate. There should be no fields in the Project 2 schema that do not exist in the Project 1 (master) schema.