If you ask a developer what moments he enjoys most, 9 out of 10 times he’ll say, “It’s when the stuff works!”

As we move forward into beta, it’s like seeing your baby walk up from crawling. The zipBoard team is really excited, and now that we can finally take a deep breath of satisfaction, we decided to share our experience with using MeteorJS in this post. A must read for any team that plans to take their Meteor apps to production.

Let me start by saying that we absolutely loved coding with MeteorJS. Out of the box, MeteorJS offered us a fully reactive front-end, with an asynchronous back-end. Reactivity on the front-end meant that we had to write significantly less code. All client-side updates were automatically managed, so our event handlers were thin, and were primarily intended for database updates. MeteorJS is built on top of NodeJS; this makes it asynchronous, giving us outstanding gains in performance. Coming from a world of php apps, these out-of-the-box gains in performance were useful and very impressive.

Second, my belief about MeteorJS is that it’s exceptionally simple to learn, and the ramp-up time for a person familiar with coding is about four hours. Why four hours? Because every person on the zipBoard team has been able to complete the getting started tutorial for Meteor in half a day, and jump right into coding. In my opinion, MeteorJS code-flow is intuitively structured, and it’s all javascript, both on the client and on the server, which makes it very easy to debug and extend code. I must mention our experience with an extJS project, written with a php back-end last year, and trust me, it was a total nightmare to understand the existing code pool and write enhancements.

I must also credit the availability of spacebars in MeteorJS. Spacebars made it easier for us to write simple logic inside the HTML itself, thereby reducing our javascript code substantially. And at last, Minimongo is an ingenious concept in MeteorJS. Minimongo allowed us to publish our insecure data to the client, and run queries on the client itself. We believe, till date, that this makes our application faster, and reduces some bits of load on our host server.

 

Quite honestly, all of us were in absolute love with MeteorJS till the time we were testing it only on localhost. Our toughest moment, or let’s say, the day when our love for MeteorJS took the first blow was when we planned to deploy it on a web server.

Among the most popular PAAS that support MeteorJS applications, there were Modulus and DigitialOcean. Yes, of couse Galaxy came by a few weeks back, and I bet that like us, every developer working with MeteorJS celebrated this moment. But unfortunately, the excitement died out pretty quickly, as using Galaxy meant shelving out a minimum of $500 per month. This was nowhere comparable to <$100/month deployment on Modulus or DO, and hence, dubbed by many as a non-starter.

In any case, we created sample deployments on both Modulus and DO. With modulus, we found it to be extremely black-boxed. Modulus offered us a tool that packaged the application and deployed it on their servers. However, we had external dependencies, and external resources that we found to be extremely difficult to manage with Modulus.

So, now on to DO. The step-by-step guide provided by DO simply did not work; we improvised, made changes/updates and were able to deploy a few times. However, the process was not consistent, and not very reliable. In the end, our only hope was provided by Arunoda, and his mup tool. Thankfully, this worked for us every time, and provided a stable deployment process. But, once again, we are now bound-to-the-grave to a deployment tool that is a black-box to us, and like any developer, we are not fans of this hard-bound dependency.

My recommendation to the fellow Meteor community is to budget enough time for solving the deployment puzzle, if you are doing anything out of the ordinary. We were using external assets, and external HTML link-ups outside the application, so it took us an unexpected amount of time (almost 1/3rd of our total dev time) to get it all working in production.

The CFS package provides a filesystem for MeteorJS apps, and is among the most popular packages on atmosphere. This is a must-use package if your application is doing anything with upload/download of files and/or folders. For zipBoard, we upload zip files, and unzip them on the server to display them inside the application.

Once again, the CFS package was quick to get started and implement. However, when it came production time, and we got down to writing the ‘user-delight’ features, like ‘cancel a download while the file is uploading’, or ‘show a more reactive upload-progress bar’, there was nothing available. We were able to hack our way through, and get these options to work. But, it would be seriously nice to see this package mature up more before apps can use it in production. My suggestion would be for MDG to pick it up, and make it a part of core.

It would be super helpful!

Ah, and let me mention our biggest challenge! There is still no way to find out if a file has completely uploaded, and available on the server: kept us awake a couple of nights to write our own custom implementations and get this to work.

Sometime soon, I’ll write a post on the hacks that we used for CFS.

Well, there isn’t much you can say about an almost perfect technology.

A few other minor things though: once we got into production, we noticed that some of our helpers were running all over the place. It did not have any impact on the application as such, but still, I would like to understand the exact work-flow of helper functions. In some cases, we noticed that some our helpers ran three to four times, however, we could not figure out why.

Lastly, as we completed our application, we noticed that we ended up using a lot of NodeJS packages for parsing XML files, zipping/unzipping files, and file structure manipulation. The ecosystem around the technology sustains it in the long run, so it would be nice to see some dedicated effort from MDG to develop its package ecosystem.

Once again, we love MeteorJS, and will strongly stay behind it. Check out zipBoard, and it will convince you that MeteorJS can be used to produce brilliant applications.

I’ll see you in the next post.

-Pranab@zipBoard

The post Is Meteor Production-Ready? Our First-Hand Experience appeared first on zipBoard.