For example, RadGrad provides a class called CareerGoalCollection, which manages access to a MongoDB collection also called "CareerGoalCollection". Upon startup, a singleton instance of the CareerGoalCollection class is instantiated and assigned to a variable called "CareerGoals". This variable is available for import into any files that need to access data from the MongoDB CareerGoalCollection collection.
This may sound confusing, but it's quite straightforward in practice. Here's a sample line of code to illustrate:
const interestType = InterestTypes.findSlugByID(doc.interestTypeID);
InterestTypes is imported into this client module, and it refers to the singleton instance of the InterestTypeCollection class. (Because these singleton instances have no mutable state, there are no concurrency issues associated with them.) The method
findSlugByID from this class is called with a string that (hopefully) holds the value of a document ID in the InterestTypeCollection.
The implementation of the data model is contained in the imports/api directory. In some ways, it would have been more descriptive to name this directory "datamodel" rather than "api". We named it "api" in order to conform to Meteor best practices for application structure.