For my last Meteor React app I’ve designed the most simple role based access control. The basic idea is that users can have multiple roles and every action possible is only allowed by a specified set of roles. For my Meteor React app the following scenarios were considered:
Get the latest version of this specification here: https://gist.github.com/d4755eb1b7a9d6b08515408ea6fd69bb
The Meteor project structure (MPS) is a proposal for a simple file and folder naming specification.
There are several basic distinctions when building a Meteor project structure. First there is a client, server and an imports folder. All folders have specific naming rules and differ in their structure.
PM2 is a well-known node process manager. Not so well-known is its deployment feature. With pm2 you can reasonable easy deploy any node application. As Meteor is always a node app at its heart I’ve decided to deploy my current Meteor project with PM2.
One requirement for my current Meteor project was that a user must login with their ActiveDirectory account. This means that Meteor must be able to authenticate against LDAP. In atmosphere there are already a few packages available which implement and support LDAP authentication. However, they are either outdated or difficult to configure. This is why I’ve decided to build my own custom login request handler for Meteor.
One of the popular features of Meteor is its accounts package. As you know, it makes it fairly easy to add a user authentication solution to your Meteor app or add support for different oAuth services. With the possibility to integrate an Apollo GraphQL API into your Meteor app this became a bit more difficult. The Apollo stack does not support an out of the box solutions to authenticate users with Meteor accounts. Jonas Helfer, one of the Apollo core devs, proposed two ways to authenticate users with your app:
For my last project I had to build a web application to administrate a MongoDB database. Due to using Meteor quite a lot I heard about Graphql and the Apollostack. Graphql, which is a specification done by Facebook engineers, promises to be the better REST API (which I hope it is). I became curious and decided the build the server API with Apollo. First I tried to evade using the Meteor as build system as I don’t want to get too accustomed to this full-stack ecosystem. However, building a live-reload server and client build system in ES6 with Node.js, Babel and Webpack was simply too much work compared to building this simple web app. So in result this was my stack:
Together we’ve built an app to create and share events with friends. It was an awesome experience. Yesterday we launched a private version on heroku. For us this was a great accomplishment. I learned a lot from this project and thought about sharing it with world.
Some technical features and challenges we solved:
- Access control for methods, publications and routing.
- Mobile first ui with material design.
- Fulltext search everywhere.
- File upload to Dropbox with Meteor-Files.
- Images with different thumbnails.
- Keyboard navigation in single views.
- Ready for deployment to heroku.
Thanks to the makers of Meteor, React, Mantra and Mantra-CLI.
For Meteor there are not many options left when choosing a user account package. The built-in option is the only use- and successful solution so far. The package is well documented and works like a charm. However, whenever I set up the account system in Meteor I am confronted with these two scenarios:
- How can I extend the user profile object with data from a registration form? (A user should be able to edit the profile data himself later on.)
- And how can I add other attributes to the user collection object? (A user should not be able to change a custom attribute himself later on.)
These are two fundamental obstacles almost every developer faces when setting up the account system. There are a lot of solutions out there on how to do this in Meteor properly, but a lot of them are poorly described and make it difficult the get the right idea of how the account system works. It got even more difficult due to API changes and Meteor itself that changed a lot over years. Now I would like to give a good example for this two questions.
Recently I started using Mantra to develop my Meteor apps. As with any other framework You’ll find a lot of answers to common questions in a related forum or any other resource. However I couldn’t get a good answer on how to implement routing logic properly. The Mantra specs also don’t tell much about how to approach it. So here’s my solution.