Leafblower: Winner of the MongoDB March Madness Ha

In March, 10gen hosted a Global Hackathon called MongoDB March Madness, and challenged the community to build tools to support the growing MongoDB community. Leafblower, a project built at the Sydney March Madness Hackathon, was the global

In March, 10gen hosted a Global Hackathon called MongoDB March Madness, and challenged the community to build tools to support the growing MongoDB community. Leafblower, a project built at the Sydney March Madness Hackathon, was the global winner of the Hackathon

Who are rdrkt?

Andy Sharman and Josh Stevenson work together on independent projects under their brand rdrkt (pronounced “redirect”) and capitalize on their largely overlapping skillset, but unique passions to build cutting-edge web applications. Josh is passionate about flexible, scalable back-end systems and Andy is passionate about accessible, responsive user interfaces.

Josh, originally from the United States, now lives and works full-time in Sydney, Australia for Excite Digital Media. He has experience with the LAMP stack, CakePHP, ZendFramework, and MongoDB. He’s also worked on projects which have required his significant expertise with jQuery, HTML5 and CSS3. He’s very active in the Sydney area tech community, regularly attending PHP, MongoDB, WebDirections and WebBlast meetups.

Andy, from the UK, also now lives in Sydney and works for Visualjazz Isobar. He has frontend experience with HTML5, Vanilla JavaScript, jQuery, Mootools, and WebGL with Three.js. In addition to that, he has experience with backend languages such as PHP, C#.NET, Node.JS and CMS’ such as Sitecore, Magento, Joomla, and Wordpress.

What is Leafblower?

Leafblower is a real-time dashboard platform we conceived and programmed for the MongoDB March Madness Hackathon. Its primary focus is on bleeding-edge, up-to-the-second application analytics and monitoring to help campaign managers and system administrators to react quickly to ever-changing trending and traffic spiking. We live in an age where one link on Reddit or a viral post on Facebook can mean the difference between “getting your break” and catastrophic failure of the application’s server infrastructure. Leafblower helps users understand what is happening “right now” in their applications and most importantly their server availability and usage by cutting out as much aggregation as possible and focusing on capturing and reporting data samples as-they-happen.

Where did the idea for Leafblower come from?

At the start of the Sydney-based MongoDB hackathon, Andy wanted to build some sort of analytics or reporting toolset to help people learn the way Mongo databases function and grow, but it wasn’t until the starting bell rang that Josh had the idea of doing real-time monitoring rather than historical analysis. That’s how Leafblower was born.

We went on to win the Sydney hackathon, and decided to really buckle down and clean up what we worked on for the global competition, rather than trying to build out too many extra features.

Anyone can look at and download everything needed to install Leafblower on Github

How does Leafblower work?

After the initial idea for Leafblower was formed, the rest of the project flowed together organically. The platform uses MongoDB as the storage engine to run all the data “blocks” which display statistics intuitively for end-users. Blocks render themselves using information passed to them via a Node.js communication layer which itself connects to a backend API server. This allows many clients to be connected and viewing dashboards without requiring any additional load on the API server and thus the application itself.

Leafblower is currently running on a Linux/Apache/MongoDB/PHP/Node.JS system, however, Linux could be swapped out for any OS, and Apache could be swapped out for any web server assuming that the correct version of the required services are installed and configured to play nicely. There is a full list of required software available on our Github page. Leafblower uses well-supported cross-OS services it so you can run an instance with the operating system you’re used to.

Rather than trying to create a platform that is generic enough to be useful to all the different applications out there, our goal was to create enough useful Blocks and then put the power to customize or extend block functionality with the people actually using Leafblower to monitor their apps. NoSQL solutions like MongoDB are the perfect fit for projects looking to allow developers to extend our platform with minimal-to-zero prior knowledge of how data is stored and passed around, internally. For example, while some of the elements of the configuration documents in MongoDB are required to function properly, whole portions are completely arbitrary depending on the data needs of a given block. With MongoDB this is no sweat. For us, the advantage is not so much about “No Schema” as is it is about a “Flexible Schema”.

When will it be ready for a production environment?

After completing the early stages of the project and successfully winning the MongoDB Global March Madness Hackathon Josh and Andy have a number of features and services, both short and long-term, to implement. Some of the items on their shortlist are:

• Users and Groups to which profiles can be assigned
• Easier setup and installation/configuration for users who want to deploy Leafblower on their own hardware
• A full suite of Blocks of both a basic and advanced nature, such as API Blocks for Twitter/Facebook/Google which do live social/analytics monitoring
• Automatic historical data comparison to make it easier to compare current live data with past trends
• Admin panel enhancements to make users, groups, profiles, and Blocks easier to configure

User logins and access groups are our first priority and we expect to include them in the next release of Leafblower on Github. We’re also hoping the community will engage with Leafblower and help us build out our library of standard Blocks.

Why did rdrkt use MongoDB?

Leafblower is a real time monitoring platform, not a complete self-contained application. In order for it to be flexible enough to monitor all sorts of potential data feeds and apis, we knew a flexible schema was the way to go. For example, let’s look at a document from the blocks collection

{
    "_id" : "geoCheckIns",
    "type" : "geospacial",
    "title" : "Visualize checkins as they occur.",
    "description" : "Block for visualizing the checkins occurring in your app bound by a circle centered at a given lat/lon and radius",
    "ttl" : 5000,
    "options" : {
        "lat" : -33.873651,
        "lon" : -151.2068896,
        "radius" : 50,
        "host" : "localhost",
        "db" : "demo",
        "collection" : "checkins"
    }
}

In the case of a block, each one will always have the fields _id, type, title, description, ttl and options, however, options is a subdocument and may contain an arbitrary number of fields. In this example, we need to know which database host, database name, a collection name with checkin data to monitor, a center point to draw our great circle and the radius of the circle. From those data points, the block will be able to render a map centered over our point and drop pins onto the map as users check in to your application. This particular block would be useful for someone monitoring their social media campaign as it goes live in a specific city or region.

Let’s look at another block type for contrast:

{
    "_id" : "memory",
    "type" : "system",
    "title" : "Memory",
    "description" : "View statistics about the memory usage on your server.",
    "ttl" : 1000,
    "options" : {
    }
}

In this example, we left options completely empty because we are retrieving the monitoring data from the server the user is currently connected to. Our application still expects an object to exist when we access options, so we maintain the structure of our document despite not needing to read any further data for this type of block. We might expect sysadmins to use a modified version of this block for monitoring servers they administer.

This is a good illustration of what we mean when we say “flexible schema”. It’s an important distinction to make from “no schema”, since there is a clear idea of how the data is structured, we’ve just allowed for flexibility in certain places where advantageous. NoSQL solutions like MongoDB are very attractive to many developers, because they can interact with the database as if they are simply storing and retrieving objects from a datastore. This is a dangerous path to follow, however, because a “set it and forget it” attitude will quickly lead to scaling and performance issues as an application grows. Know the structure of your data and only make changes to that structure incrementally.

MongoDB is easy to scale and has a vibrant user community. Leafblower gives back to the community by creating useful tools to showcase MongoDB’s advantages while teaching them how it works. It’s a win for everyone: for ourselves, for MongoDB, and for the IT Community at large.

Want more information?

Leafblower:

• Github repo
• Twitter
• Angelist

rdrkt:

• Facebook
• Website
• Twitter

原文地址：Leafblower: Winner of the MongoDB March Madness Ha, 感谢原作者分享。