Here at Palomino Labs, there are many things that are important to our culture. If you take a tour of our office, we hope many of these passions will be apparent. While you won’t see a taqueria built into one of our conference rooms, or a smoker out on our office patio (also known as the roof of the yoga studio next door), some things might catch your eye.
In the hallway you’ll find our coffee station, with a Breville espresso machine and a Chemex, as well as a dozen or so varieties of beans from a number of our favorite roasters. On display in the main work area are our bowling trophies, including Ron’s 1st place win. And then… there’s beer.
Backend as a Service (BaaS) companies seek to provide you, the developer, with a reliable backend solution that is quick and easy to use. With one of these services you can, in theory, save yourself the time and costs of configuring AWS servers and load balancers, or building and deploying a Ruby codebase to Heroku. However, from our experience working with Parse, one of the leading BaaS providers, we encountered a number of major gotchas that ended up making the development process take a lot longer than we estimated it would have, had we built out a Ruby backend ourselves. We hope this post will help developers realize the promise of Parse as a BaaS and avoid the efficiency killers that hampered us.
Parse is the latest BaaS provider we’ve experimented with, but it is not the first. If you’re familiar with our blog, then you’ve likely seen our post on how to build An App in an Afternoon using StackMob. We liked the idea of BaaS, especially as a tool for rapidly prototyping web apps, and intended to use StackMob as part of an application to help a startup vet their idea. We had just sent our client a proposal and were out for our regular Taqueria Tuesday lunch when it was announced that PayPal was acquiring StackMob.