Disrupting the Liquor Inventory Industry with Meteor and React

This is a guest post by Mark Shust, Innovation Engineer at Chanj.

Chanj FLOW is a mobile app designed to solve liquor inventory for bars and nightclubs. Frustrated with the existing liquor inventory systems for nightlife venues, we sought to create a new solution that was simpler, more efficient, and affordable. The app is available for download on the iTunes App Store. In this post, I’ll talk about the technical decisions we made while developing the app, why we chose to build it with Meteor and React, and how Meteor’s 1.4’s recent updates have delivered even more value.

 

Choosing an Architecture

The first step was to quickly narrow down possible architecture platforms. JavaScript was chosen for the ability to code in the same language on both the client and server side. This would greatly improve efforts to find future development resources, and create a consistent development environment with JavaScript being used on both the frontend and backend systems.

Faced with the decision to create our own custom solution or choosing to build from a framework, various platforms were analyzed and discussed. Meteor jumped out at us; not only would it help us solve the “JavaScript Fatigue” problem, but it also played right into our need to develop a real-time app ecosystem. We believe real-time is the future of the web. More practically, we wanted to allow multiple users to take inventory of the same section of their bars at the same time without stepping on each other’s toes, and to provide management with instant feedback about their progress.

We also quickly narrowed down our strategy to mobile-first. Smartphones and tablets are prevalent and cheap, while the liquor inventory vertical is presented with many hardware-based solutions that are expensive to set up and to maintain. This was an interesting pick for us, as at that time we had experience creating rich web applications, but absolutely zero experience creating and deploying mobile applications. Meteor’s Cordova integration would help us build hybrid apps on a single, consistent architecture. It filled our knowledge gap around Objective C and Java and solved our need to build multiple apps for each of the Apple and Google app stores.

There were some drawbacks to choosing Meteor at the time, such as the lack of support for NPM, controlling load ordering of files, and ES6. Working with React was then filled with NPM-wrapper packages in Atmosphere, which was also less than ideal. Even with these challenges, however, we thought it was the most promising solution available, so made the decision to move forward with the platform and start our project with Meteor 1.2 in late 2015.

Creating a Solution

At Chanj, we’re devoted to creating high-quality, pixel-perfect, hand-crafted graphical imagery. Our competitors don’t have an appreciation for the arts or a focus on accuracy, so we wanted to play right into their weaknesses by creating the highest quality liquor app available. The process of taking inventory would be as simple as tapping and dragging your finger across the screen, eliminating the need to purchase expensive hardware such as barcode scanners or weigh scales.

Meteor would also make our app so cost-effective for us to host and maintain that it would allow us to create a basic offering for free, while offering subscription plans containing advanced functionality for customers needing more. A big side goal for us in developing this app was also to change the misconception that you can’t create a native-looking and feeling app with something like Meteor and Cordova.

 

During the design phase, we also chose to utilize some of the Google Material Design standards, as we believe them to be an extremely-well crafted solution to common design problems. The great material-ui library is available for React, which we chose to implement for most of our interactive React components. The Material Design standards also helped us stay on track and develop a solution quickly that works on both iOS and Android platforms, as well as on both smartphone and tablet devices.

To provide some native mobile integrations, such as a camera and in-app purchase capabilities, we looked to the many Cordova plugins that were available. This allowed us to retain all of the code within our web app, and splash Cordova/native-specific functionality within the code where needed. Most Cordova plugins we utilize are also cross-platform, so they work across both Apple and Android devices.

Meteor 1.3

Halfway through our development, Meteor decided to do something which they’ve never done before: open a beta release for their new 1.3 release. There were obvious improvements coming to the architecture, and we thought they provided too many benefits for us to pass up for our initial launch. We decided to be early adopters of this beta, and believe we helped give back to Meteor by filing a lot of early bugs and reporting performance problems during this preview phase.

The Meteor team was fantastically involved with the community through the release of 1.3. They listened to a lot of the feedback we provided, were extremely responsive with any issues, and were a delight to communicate with. Because of this, we felt very comfortable upgrading all of our code to ES6, using imports to eliminate globals, as well as porting all of our NPM-wrapped atmosphere packages to direct NPM package integrations. It was a lot of work, but solved all of our previous problems with Meteor and laid a great groundwork for future development on the app.

Initial Launch

Even with all of this work and a very small development team, we were able to upgrade our entire codebase, fully test our app, and release ahead of schedule by the end of February 2016. We launched on the build of Meteor 1.3-beta.10, as during our testing it appeared to be more stable than the current release of 1.2. The improvements made to mobile hot code push were also very welcomed, as we could now bypass waiting for App Store delays of any kind.

We initially only launched on iPhone, to combat any complexities with submitting app builds and diagnosing device-specific issues with other app ecosystems. We followed the lean development methodology, launching just with the free version of FLOW. This helped us get to market quickly, and put us in a position to listen and respond to customer feedback. We also launched with a number of subsequent apps developed on Meteor, including a backend administration app and backend worker instances.

With everything being based on Meteor, including a few server-only builds, we created a very solid, consistent ecosystem for daily development. Our entire application infrastructure is deployed with some basic bash scripts that build out Docker images, which in turn get deployed with Kubernetes to Google Cloud Platform. This platform architecture also allows us to push out hot code pushes with zero-time deployments, and a MongoDB replica-set helped us to achieve a true high-availability setup. Since our release, we’ve had absolutely zero downtime, even with over 30 new builds and pushes to production.

 

Meteor 1.4, 1.5 and Beyond

The recent release of Meteor 1.4 provided us with an opportunity to upgrade to the much newer Node LTS and Mongo 3.2 WiredTiger storage engine. We’ve already updated all of our app infrastructures to this new version, including our main app and all related backend systems. By keeping up to date with new Meteor app versions, it allows us to keep up with all of the latest and greatest features of the Meteor architecture and the JavaScript ecosystem.

We are excited about what is coming in Meteor 1.5 and Apollo, as we think reactive GraphQL will play right into our desire to build out great, real-time analytics for our customers. The ability to run SQL databases alongside MongoDB will allow us to use the best of both worlds, and also provide us with advanced possibilities for filtering out and querying our data for analytics.

Roadmap and Future

At Chanj, we have a pretty extensive roadmap planned, including developing Android and tablet versions, integrating third-party API’s (as well as offering our own), an enterprise offering, and more. After six months or so of working with Meteor, we are extremely happy with our choice, as it already appears to have perfectly validated our app use-case. Future apps we plan on developing will also be built on top of Meteor, as we feel it perfectly fits into our lean business and development methodologies. We’re so excited about what the future brings with this development ecosystem.

SOURCE: http://info.meteor.com/blog/disrupting-the-liquor-inventory-industry-with-meteor-and-react