Last week, we were left with a dilemma: potentially, a Furni user could log in via any of several services – and if we ever decided to actually release the app, we wanted to make sure people would always have easy access to their own data inside the app.
Part four: creating a backend to manage services, data, and identities
A common theme across the apps on my phone, apart from offering a way to log in, is that when I save data on them, it’s persisted somewhere besides just on my device. I can tell this because when I log in from another device or from the web, my information appears. Just a few years ago, this felt magical. Remember the first time Google Maps automatically put directions on your phone to the place you just searched on your laptop? Now, it’s table stakes. Apps need to store data, and people expect to manage and access that data wherever they are.
There are so many options for how to structure and build your backend that it would be absurd to try and make broad recommendations in a post like this. “Backend” comprises so many pieces — and at each level you have tons of choice: programming languages, frameworks, databases, and — unless you’re building your own data centers, or expect to run everything off a machine in your garage — hosting providers.
Making all of these decisions is mostly a question of taste, skillset, and the balance between control and flexibility you want on the infrastructure. At one end you have full MBaaS (Mobile Backend as a Service) options like Parse (Facebook), Kinvey, Feedhenry (Red Hat), Azure (Microsoft), and Cognito (Amazon). These give you easy to use, native-feeling APIs for storing data to the cloud, and you don’t need to manage any of the infrastructure directly. On the other end, you have IaaS (Infrastructure as a Service) like EC2 (Amazon) or Heroku (Salesforce), which give you tighter control over resource management. PaaS (Platform as a Service) choices like App Engine fall somewhere in between.
Data for our furniture items gets pulled from DynamoDB
Cognito also helped solve our multiple-login problem, binding them all to one user with a unique Cognito ID. Cognito is also available through Fabric, so Digits and Twitter login are already login providers that are easy and quick to set up. We chose the structure we did based on ease of implementation and cost.
What did you choose when you were launching your app? Has it changed as you’ve grown? What do you wish you’d known when you started? Tweet at us at #MobileAppPlaybook with your comments.