I am planning a Meteor app which will acquire new modules on a regular basis. The app uses the React library.
A module will consist of a number of audio and image assets, plus JavaScript and JSON files that will do three things:
- Define the module-specific components
- Define and populate a module-specific collection
- Provide module-specific Meteor methods
The obvious place for the audio and image assets is inside the public/ folder. To make it easy to add and remove modules, I am considering placing all the files for each module (including its JavaScript and JSON files) in their own folder, inside the public/ folder.
On the server, Meteor.startUp() will run a script to crawl the public/ folder and rewrite certain files on the fly, to make any new methods and collections accessible to the server code. In particular, the main App.jsx file will be rewritten to include links to the new module components.
Are there any issues with working this way?
In particular:
- Could placing JavaScript and JSON files in the
public/ folder lead to a security issue?
- What files on the server risk being loaded before they can be rewritten by the server’s
Meteor.startUp() method?
There is s possibility that this will not work.
Instead of renaming methods and collections on the fly, why not just use roles or levels. Then use those roles to limit access to specific parts of the app.
Thanks for your input @rjdavid. I’m not sure that you understand me or that I understand you. The concept of limiting access to any part of the app is totally unrelated to my question. Nor am I renaming methods or collections. In my experience with Meteor, I have not yet come across the terms “role” and “level” in any context which seems pertinent to my question. A quick Google search for these words plus “Meteor” did not bring up anything that seems obviously relevant. Perhaps you could point me to some documentation about these concepts?
To restate my question:
I plan to add to the public/ folder of my Meteor project a folder which contains all the assets and logic to create a new module. To make the Meteor methods used by this new module available, I add a reference to it to a centralized methods.js file, which has the structure:
import * as module1 from '/public/modules/module1/methods.js'
import * as module2 from '/public/modules/module2/methods.js'
export { module1, module2 }
The /server/main.js script contains an import statement that makes all these Meteor methods available on the server:
import '../path/to/methods.js'
The modification of the methods.js script is done on the fly from Meteor.startUp()
I am doing something similar to create and import the MongoDB collections that the new module needs.
I would be interested to learn more about how to use the levels and roles that you have referred to as a way to achieve my goals.