During the presentation I give some insights on how we weighed the pro’s and con’s while deciding to use Meteor for this project. After this I address 4 specific challenges we faced during development.
The slides and code can be found at Part-up: a Meteor Production Story
Teamwork -> Component directory structure
We made heavy use of components to split up the functionality of the web application. This allowed the team to work on isolated pieces of functionality without running into loads of merge conflicts while working in the same files. We documented all of the components API’s so it would be clear for every team member how to use the re-usable blaze components and how to set each of the parameters.
This first snippet shows the top level of our application, with the packages folder containing all of the separate components and the
client-pages packages containing all of the page templates that are used in the routing
.. (up a dir) /Users/peter/development/partup/ ▾ app/ ▸ client/ ▸ i18n/ ▸ lib/ ▾ packages/ ▸ cfs:file/ ▸ partup:client-activity/ ▸ partup:client-base/ ▸ partup:client-columns-layout/ ▸ partup:client-commentfield/ ▸ partup:client-contribution/ ▸ partup:client-copy-to-clipboard/ ▸ partup:client-dropdowns/ ▸ partup:client-focuspoint/ ▸ partup:client-forgotpassword/ ▸ partup:client-gallery/ ▸ partup:client-invite-to-partup/ ▸ partup:client-loader/ ▸ partup:client-location-autocomplete/ ▸ partup:client-login/ ▸ partup:client-network-settings/ ▸ partup:client-pages/ ▸ partup:client-partup-tile/ ▸ partup:client-partupsettings/ ▸ partup:client-popup/ ▸ partup:client-rating/ ▸ partup:client-ratings/ ▸ partup:client-resetpassword/ ▸ partup:client-spinner/ ▸ partup:client-update/ ▸ partup:client-usercard/ ▸ partup:client-widget-spinner/ ▸ partup:lib/ ▸ partup:meteor-bender/ ▸ partup:newrelic/ ▸ partup:server-base/ ▸ partup:server/ ▸ private/ ▸ public/ ▸ server/ ▸ tests/ ▸ uploads/ package.json scss.json ▸ backups/ ▸ bin/ ▸ config/ ▸ devops/ ▸ docs/ CHANGELOG.md ERROR.md methods_documentation* README.md
This second snippet shows the directory structure of the Activity component.
▾ partup:client-activity/ ▾ i18n/ en.i18n.json nl.i18n.json ▾ templates/ ActivityForm.html ActivityForm.js ActivityFormPlaceholders.js ActivityView.html ActivityView.js Activity.html Activity.js package-tap.i18n package.js
Activity.js is the entrypoint for the component, which also contains API documentation how to use the component:
Code reuse -> Lib package with namespaced functionality
The following snippet shows the directory structure of the lib package
▾ partup:lib/ ▸ collections/ ▸ helpers/ ▸ private/ ▸ schemas/ ▸ services/ ▸ startup/ ▸ transformers/ error.js namespace.js package.js
The functionality in the lib package would be defined in separate files adding functionality to the namespace object:
The following snippet shows our use of collection helpers and specific model helpers that operate on the document instances
Micro service integration -> Event based meteor methods
To allow external micro services outside of the meteor system to hook into functionality from our main meteor application, we have introduced an event pattern. This pattern consists of emitting an event after each meteor method call, such as
partups.updated. The events are emitted with EventEmitter2 package and all include the details of the document that was inserted or updated. These events are broadcast both internally and externally.
The events would be triggered in a method as follows:
Internally we use the events to trigger the creation of updates, notifications and emails, as seen in the following example:
Externally the events are submitted to a message bus, such as RabbitMQ, that allows outside systems to listen to the stream of events and react on updates in the system. For instance, the micro service containing the recommendation engine could use these events to build its recommendation graph and emit recommendation events on the message bus. These recommendation events can then be used by the meteor application to store recommendations on meteor collection documents and present these recommendations to the user.
Scaling meteor -> modulus.io, compose.io and wercker
In our deployment setup we use modulus.io as an auto scaling application server, compose.io as scalable MongoDB host and wercker.com as a continuous delivery platform to run unit tests and automatically deploy builds to acceptance environments.