Parse.com and the art of abstraction

Way back in the days of the dinosaurs, I was at Software Publishing Corp. internally evangelizing the use of a GUI abstraction toolkit we called PMRT. I forget the meaning behind the first two initials (the latter being "run-time"), but I remember they referred at least humorously to the initials of the original author of the system - Peter M. The point of PMRT was to provide a programming abstraction to the hottest GUIs of the time, namely OS/2 Presentation Manager (argh, there is that "PM" again), the soon-to-be-released Windows 3.0, X/Motif, and the Mac. This was in the days before you were born - around 1989.

I traveled to Madison, Wisconsin, to meet with the engineering team for a group that SPC had recently bought out, in order to convince them, by begging or issuing threats, to design their product development around PMRT rather than writing "native" UI code. The benefits included having a common UI code base. The drawbacks were everything else, primarily the lack of control over performance and the disparity between what the native system could do and the subset of which PMRT provided. There were other arguments for and against, but my point is to show that abstraction layers and the debates they inspired go back to when you were teething on Barney dolls.

The team at Parse is most impressive and recently gave a talk at the HTML5 Developer Conference in San Francisco regarding the virtues of HTML5 versus writing Native device applications, using a backend as a service, namely Parse. You can find the talk here. Enter a bogus email address to access the email if you don't want to provide a real one.

Again, it's the age-old debate regarding abstraction layers, but while the arguments for and against PMRT were relatively simple, I think the debate over these newer abstraction models contains much deeper, more subtle issues. What the Parse team is doing here is less discussing the issues of HTML5 versus native, than making an argument for the aggregating backend service. But make no mistake; the issues are closely tied together.

Parse argues from a historical perspective that providing a unified application development model is what everyone is working toward, and you really can't argue with that. Just as the SPC teams would be reinventing the wheel again and again in building system-native GUI code back in 1989, teams today are trying to solve the same problems covering user identification, push notification, and local and remote storage. Parse's value proposition is that they provide a sane, common layer that all can use. They're the PMRT of today, with a very nice acquihire exit plan to go with it.

The difficult thing for a company getting its feet wet in application development with the standard database+frontend app model is understanding the long term implications of using a short-cut model like Parse. I think Parse is similar, on a broader scale, to what Visual Basic provided when it first came out: a rapid development environment that allows the less technically inclined to get to market quickly. The downsides are hidden until the application or application ecosystem grows in size and popularity. Only then will issues of performance and scale arise and only then will you really know whether the system that got you to market so quickly gets in your way.

Hyperfine has been consulting for a company with a limited, but growing engineering team, and we've made several suggestions to point the group to the right long-term path. The best recommendation we've made, I think, is pushing JavaScript as the standard language, which itself implies certain directions in tools and platforms. There are several reasons we pushed this, including:

• It opens up hiring to a much broader pool of developers
• It is the basis of both server-side technologies, namely Node.js, as well as the ubiquitous client-side browser-based language
• JSON as a serialization standard becomes the natural, native data format, so models can be shared on both the server and the client
• NoSQL databases such as MongoDB are built around JSON as documents

There are other reasons slightly more political, including the ability to decouple your development efforts away from certain platforms and make your target environments more portable (think JavaScript versus C# and the .NET ecosystem, for example), and while these may seem, well, political, they also have implications regarding hiring, costs, product lifecycle flexibility.

So why do I mention Parse? Hyperfine investigated the use of Parse for rapid development and deployment, which seemed like an excellent solution for a small, growing engineering team in a company with limited product development experience. Parse's value proposition is a strong one. There are so many issues involved in building an application platform that it's easy for a young team to reach analysis paralysis. The issues include in part:

• Web engine platform
• Languages
• Database
• Hosting
• Deployment models
• Backup and disaster recovery

Parse answers many of these questions, hiding many of the answers behind an abstraction layer. They look to have done excellent work. Again, the Parse team looks extremely impressive.

So, what's the problem? As with any abstraction layer, it comes down to details, many of which don't become apparent until you're dealing with a production environment in full use with many users. If you run into performance issues, there is a barrier beyond which you can't travel, namely whatever happens on the other side of the abstraction layer's API. Now, this is a bit unfair, since any system you rely on can be defined as an abstraction layer. If you work directly against MongoDB's interface, that's an abstraction layer. You need to know the right things to do in the right ways to squeeze the best performance out of MongoDB. It's a similar story with Parse, except that Parse is an additional layer on top of Mongo. So, focusing only on the database layer of your application, the early question is can you do everything through Parse that you could do or needed to do through native Mongo?

If not, then you've got trouble. Now multiply these sorts of questions against the matrix of required features and abstraction layer APIs. At some point, you will grow so expert in the development and refinement of your application that you will need fine-tune access to the layers below you. What was a cure to difficulty in getting off the ground (Parse as a rapid development environment), can be a curse as you find you no longer need the crutches the abstraction layer provided.

There are no rights or wrongs here. What's important is for an organization to understand its strengths, weaknesses, needs, and market position to make the best choice of tools and strategy.

What Hyperfine suggested was to use Parse as a rapid development environment and build the company's expertise over time in the underlying technologies. At the same time, as hiring in the engineering group progressed, small teams could be assigned to build similar in-house abstractions natively against systems like MongoDB, push notifications, etc. In short, use Parse to buy time for building internal expertise. If it turns out that Parse imposes few or no limitations to rolling your own, it's all gravy.

Internally at Hyperfine, I'm working on a system built against MongoDB, using Mongoose as a model interface, with Node.js as a REST and web site engine. I'll have more to say about this effort in the future. Until then, thanks, Peter M., for the early learning!

-- Rob Bearman