/ til

Some best practices while developing meteor.js apps

Recently I was working as a consultant for a meteor.js app, reviewing the entire codebase, and came across some of the common mistakes the developer makes when writing his/her first meteor.js app. Though some of them are trivial, some others can have bigger consequences on the security of the application itself, and some others can affect the performance.

So I thought of scribbling down some of the best practices, do's and dont's in writing a metoer.js. Some of the points are just best-practices(maybe opinionated), and your app will work totally fine even if you don't follow those.

  • Don't re-invent the wheel; use packages.
  • Choice of router? - iron-router vz flow-router. iron-router was once the de facto choice, but time has changed and flow-router has taken over the reins now.
  • Data modeling: Choosing between a normalized schema or embedding everything into the same document possibly creating duplicates. The choice depends on how often you want to read/write the data and how often the collection would be updated.
  • Schema for collections and validation: Use collection2 package for attaching schema and validating the inputs.
  • Use collection-hooks package for managing the before-, after- hooks in your code.
  • Use meteor-autoform package to keep your forms clean.
  • Use check package for in your app for advanced security.
  • Try to cache the data that is subscribed, so that you don’t need to hit the database each time.
  • Use pagination, won’t be an issue in the initial stages, but when the data grows, you wouldn’t want to load all the data in the initial load.
  • Try to avoid the usage of Sessions whenever possible; Query the data from the server instead unless you really want the data to be there in multiple sessions or hot reloads.
  • Have control of what data you expose and who can access what. Publish only those data that is needed.
  • Never trust the user, and don't allow the client to update the data.
  • Components - This can be debated - Blaze vz React, turns out that Blaze is now meteor's ex and React is its new crush.
  • Remove auto publish and insecure from your packages before you deploy to production.
  • Organize your code into directories, so that when the codebase grows, it can be maintained.

Hope the above best practices turns out to be helpful for you. Let me know of any best practice that you follow as comments.

Manu S Ajith

Manu S Ajith

Tech Entrepreneur, dating Elixir, in long-term ❤️ w/ Ruby, had multiple one night stands w/ Go. Into functional paradigms DDD/CQRS/EventSourcing architecture these days. @manusajith on the interwebs

Read More