CloudMine.Logo.HiRes.type_1.png
Ë
Blog Home
By 0to5 • June 30, 2014

Why Biomeme is Using CloudMine

 

This is a guest post by Maximilian Maksutovic, Biomeme's software lead responsible for iOS, web, and Arudino development. Biomeme is a startup developing a smartphone attachment that can perform realtime DNA analysis, and is backed by Mark Cuban and Dreamit Ventures. Product systems will sell for around $2,000, but the company is hoping to bring it to drugstores around the world for around $200 in a few years' time. Just a few applications include tracking diseases, testing food and water for pathogens, and serving as a detector for bioterror agents.

Being a relatively young developer, I am fortunate enough to work in an era of incredible tools: sophisticated IDEs, excellent compilers, and every sort of library and API imaginable. The one thing I am most thankful for is cloud-based backend systems. I can imagine some older, more stubborn developers would like to say that building and maintaining custom servers "builds character." However, I also understand that most startups, including Biomeme, do not have the time or money to properly build these systems. In addition, these systems are often painfully overkill unless your startup is serving large amounts of users and data concurrently; which, let's be honest, it isn't. 

My first introduction to cloud-based backends was Parse. I used it for my thesis software engineering project, where I built a self-guided tour for iOS of the Fairfield Osborne Preserve at Sonoma State University. The app consisted of a map with the trail of the preserve overlaid on it. As you would walk on the trail, the app would trigger certain geopoints that would attract the user to a specific cultural, geological, or ecological point of interest. The user would then be asked to look around their current position and be quizzed about certain features regarding the point of interest.

 

Using a cloud-based backend made this project feasible in a very short amount of time. It took only 4 weeks. I was able to capture geopoints for both the trail and points of interest. I could easily tag the data necessary for the internal database for the app. Using this system also allowed for my biology major collaborators to have a central place to upload additional content (the quiz questions, detailed narratives, additional photos/maps/scientific data/etc.) without the need for email attachments and USB drives.

 

Why Biomeme is Using CloudMine

Prior to graduation I was hired at Biomeme, an incredible startup that enables anyone to do mobile real-time DNA analysis on a smartphone. We had some initial talks about the data management that would be required: we would have to collect and store both experimental and patient data. We would need to configure, save, and share different tests. We must have been able to display data on different devices, porting it to the web, integrating with disease monitoring sites such as collaborate.org, HealthMap, and SAGES, as well as electronic health records. Working with such sensitive data, I knew HIPPA compliance was going to be an issue and needed to be addressed from the start. My main problem with Parse is that it had directly stated it is not HIPPA compliant, and hadn't made any promises of being compliant in the future. Regardless, we were at such an early stage that I told the team we should use Parse to get off the ground. I was thinking that, by some miracle chance, I could address the HIPAA compliance with some other solution or subcontract someone to help me do it.

 

Interested in more CloudMine case studies? Request a demo here!

 

 When I moved to Philadelphia to join the team, we were working out of VentureF0rth, a co-working space that also played home for CloudMine. I hadn't heard of them, but after some introductions they told me they had an open source API that was similar to Parse's. I was certainly interested, especially considering that they said the magic words of, "Oh, and we're HIPPA compliant." After building up their MVP to our first beta, it came time to start the data integration.

 

After a very clear and simple "getting started" guide and tutorial, I noticed one thing right away working with CloudMine: the API felt so natural to the iOS SDK, as if it was written by Apple engineers.

 

My biggest pet peeve with Parse was subclassing, let's compare the difference: Parse Subclassing:

After setting up the class, you then have to "register" the subclass in your AppDelegate:

Now let's compare how we would implement this ISCoordinate subclass in CloudMine:

So let me explain some of my resistance with Parse. For the subclass you need to add this class method +(NSString) parseClassName, which was needed for my purposes just to return a string. This certainly seems a little superfluous. Next, the class has to delegate to <PFSubclassing>, which seemed cryptic to begin with. If one looks under the hood to better understand this process, the result is even more incomprehensible. You also need @dynamic instance variables, which are not well explained. Finally, you are forced to create a Parse instance method which requires the following line: MySubclass object = [MySubclass object]. The ["¦ object] message, again, seems rather cryptic; and again, looking under the hood is even less helpful.

 

With CloudMine, the code is standardly defined, using the default initWithCoder and encodeWithCoder methods. This is helpful because now all of your CMObjects are compliant with NSSerialization. With this, we can store all of our objects locally in case the user does not have an active Internet connection, and the app can continue to function without an active connection. Moreover, nothing about subclassing with CloudMine feels out of the ordinary; I feel completely at home making CMObjects just as I would NSObjects. A good API written for a specific platform should feel completely native to the parent language, and I feel that CloudMine does perfectly.

 

Now, some developers reading this are thinking "Big deal. Every API has its quirks. Every language has its quirks. We just have to grunt, bear it and learn it." Do you want to work with an API that forces its own architecture down your throat and requires a workaround from the developer, or do you want an API that works hard to conform to the language you are working with? I prefer the latter.

 

To drive the issue further, lets talk about business. Every choice of language, platform, and API has a direct business cost, especially for a small startup. A quick example: Biomeme's app needs chart functionality, which a previous developer quoted nearly $20,000 plus many months to implement. I looked at the (free) Core Plot API and thought it was feasible, but to make it look pretty and perform well it would take a large chunk of time we just didn't have. I decided to get a ShinobiCharts license (which was $400), however I had a beautiful Biomeme branded chart running in less than 3 hours. Should have I used a free API? Maybe. Would the extra time learning and the API to deliver a half-baked product been a good decision for Biomeme?

 

Definitely not. The same goes for our cloud backend. Wouldn't it be an amazing, fun project to build a HIPPA compliant backend hooked up to a Rackspace server, shuttle data in and out using Ruby or Python scripts, and encrypt and isolate the data with OpenSSL? Definitely! Would the massive time sink to do that, –plus the bug hunting, –plus writing the necessary documentation for other recently on-boarded developers be a good decision for Biomeme? Definitely not! All that time I would of taken to build such a solution would take me away from building core functionality of the Biomeme App, delay the ability to demo the system to customers, and delay our chances of making it as a startup.

 

By using CloudMine, I was able to deliver a brilliant product with all the necessary data being stored and retrieved from the app, hassle free. Better yet, all of the code and architecture I have currently written is completely future-proof for when we want to extend this data to web apps and other platforms such as Android. Best still, once we require HIPPA compliance, all CloudMine has to do (in the words of co-founder Ilya Braude) is "flip a switch" and we are fully compliant. I recently brought on a contractor for some work and he helped augment some data management within the app, and immediately fell in love with the ease of CloudMine's API. Within a weekend, we had created a perfect, elegant, future-proof solution for shuttling data back to CloudMine, even in scenarios where there is no active Internet connection.

 

Of course I could have done all of this with Parse. Despite my minor problems, it is a fine API and used fairly extensively across the development world. But without HIPPA compliance and the lack of personal support, the platform falls flat for me. CloudMine is a company that I feel partners with you to help bring your product to a higher level. The level of support that CloudMine provides is second to none, and that is worth every expense of the platform. If I were to receive strange messages or if code seemed to not work right with the API, I could contact CloudMine and within a few hours have a detailed response, complete with code examples.

 

All in all, I chose CloudMine because I want a system that simply works. I want a system that allows me to write native Objective-C, perform tasks asynchronously, subclass to my heart's content, and to be future-proof for things like HIPPA compliance. And most importantly, I want a system that has the incredible support CloudMine offers.


Source: Hubspot Feed

 

Request Demo