Why I’m Looking at Migrating My App’s Data from Apigee API BaaS to Firebase Cloud Firestore
I’m a web application developer who has fallen in love with APIs.
I love APIs so much that I completely refactored my North American hockey arena directory called RinkAtlas in 2016, from a traditional, LAMP stack web application, to an API-driven web app connected to an Apigee API BaaS backend.
API BaaS, also known as Usergrid, is a “Backend As A Service”. That’s a NoSQL cloud database optimized for mobile apps.
If you’ve never visited RinkAtlas.com before, it’s a directory of over 4,600 arenas and park rinks (outdoor rinks mostly in cold parts of the U.S. and Canada). I think it’s the most useful arena directory in the world. People in the hockey community need a modern arena directory because they travel to play, coach, officiate, or watch hockey, and often go to arenas with which they’re unfamiliar. RinkAtlas is a guide to those unfamiliar arenas and to the businesses near by.
The old RinkAtlas was a monolithic, PHP-based, Google Maps mashup. It told you where hockey arenas in North America were, but very little else.
The new RinkAtlas is aimed at the hockey community on the go. I added geolocation, so mobile users can find all of the nearby hockey arenas wherever they go. I also added API-based connections to Yelp, so that hockey fans could find bars, restaurants, coffee, and gas stations near each arena, and to Dark Sky so they could get 7-day weather forecasts.
The RinkAtlas Community has contributed over 1,500 arena photos. They give other hockey people a sense of the arenas that they haven’t visited yet.
The architecture of the new RinkAtlas is that of a thoroughly modern web app. It’s a mobile-first, single-page website built on AngularJS and Bootstrap. That web app connects to API BaaS through its own private API.
My App Isn’t in Apigee’s Target Market
I had my new RinkAtlas web app running on API BaaS in October 2016, when I attended an Apigee Adapt or Die World Tour event in New York. This was coincidentally a few weeks after Google acquired Apigee.
While everyone I met from Apigee was glad I was there and provided great guidance on how to use API BaaS, every aspect of the technical sessions I attended was aimed at the enterprise market. It was clear that Apigee’s focus was on helping larger companies develop, expose, and scale APIs. I love Apigee’s products, but they are aimed at my API and web services consulting customers, not at me when I’m wearing my RinkAtlas indie developer hat.
Getting My App to The Next Level
In the intervening 18 months, I’ve taken the RinkAtlas web app about as far as it can go in terms of features. To get RinkAtlas to the next level, I need to develop a smartphone app that will work in parallel with the web app.
The focus for this phase of development needs to be on finding an app platform that allows me to continue the cloud-based, mobile-friendly, API-driven development style I’ve used to get to this point — with as much code reuse as I can get. If I’m ever going to make a significant backend change, now would be a good time.
Searching for an App Platform Rather Than an API Platform
I’ve looked at a number of app platforms, but the one I keep coming back to is Firebase, because it offers a great set of integrated features. The draw back until recently was Firebase’s dependency on the Firebase Realtime Database. It’s a JSON document-based cloud database, but isn’t as scalable or flexible as API BaaS.
The new Firebase database offering, Cloud Firestore is much more comparable to API BaaS than Firebase Realtime Database. I want the scalability without sharding that Cloud Firestore can provide, even if RinkAtlas doesn’t need that much scaling yet.
Migrating My App’s Data from API BaaS to Cloud Firestore
Now I’m looking at what it takes to migrate RinkAtlas data from API BaaS to Cloud Firestore. I look at this as moving from place to place within the Google Cloud, since Firebase and Apigee are both part of Google.
This migration will probably involve the development of a few Python scripts to perform ETL (Extract — Transform — Load) operations between these two database platforms.
I hope to have a solution working soon, and I’ll talk more about the migration effort when I do.
