I have a confession to make. I have a preference for mobile development over web frontend. Don’t get me wrong, I’m falling in love with React, but I’ve been doing iOS development for many years before joining Vibbio and it’s where I can do a lot very fast. I also love backend development, specially Node since I did some performance tests 5+ years ago. And Serverless… butterflies in my stomach.
Back to mobile. Because of that, I’ve been working on the side on a iOS mobile app for Vibbio. It’s not core to the mission of the company, but I felt the itch to write some Swift and I had some free time in the evenings.
I spoke to my boss and she was incredibly supportive and encouraged me to share with the rest of the company.
Now, this article is not about that. It’s about how to build something on the side without interfering with the rest of the developers, operations, etc.
The mobile app needed access to some of the data in the core platform. We’re currently moving the backend to a new platform, and we’ve made a lot of progress but we’re not done.
Even with that, we will keep adding more features and modifying features, which will lead us to modifying the APIs as well. Right now the APIs are only for ourselves, so we don’t really need to be careful modifying them or implementing versioning. Frontend and backend move together.
Because of this evolving API, we have identified several types of requests that we have to deal with from the mobile app:
- Requests to third party services. What we’re building in the core platform is not affected by this.
- Requests to basic, existing endpoints that are quite solid and most probably won’t change in the short to mid term.
- Requests to endpoints that might be changing soon because we’re working on the features.
- Requests that don’t exist. On these requests the data could be obtained from several requests (e.g.: list of elements, get details for one element), but it’s something I’d do in one single request if the API was being built for the mobile app.
So, there were some things to consider.
No feature of the mobile app was going to be left behind because there was no API yet.
Whatever built should not interfere in any way with current development or operations of the core platform.
Development should be done as forward as possible towards the core API, and whatever solution was going to be implemented it should be as minimal and temporary as possible.
Having in mind all this, the decision taken went as follows:
- A new, separate mobile API was going to be built.
- All mobile requests that could go directly to the core API would be routed through this new API transparently, calling the core API and returning the result, including status codes. Changes could happen to the API and it’s faster to fix and deploy the backend than to fix and deploy a new version of the app. Also, dealing with two *BASE_URL*s doesn’t sound like a good idea.
- The new mobile API would be implemented on Google Cloud Functions because of the easy development, easy deployment (one single command),
httpssupport, low cost and because (
fanboy mode on) …it’s the future!
A few months after all this was done, I can say that it is working perfectly fine. The app is not out yet because priorities, but most of the functionality is implemented and the mobile API works beautifully. We even brought an intern during the summer who built an Android version of the app basically duplicating the iOS features, and following the exact same usage of the API in the client.