Serverless backends aren’t compelling enough yet

I’d originally thought I’d be blogging from the opposite viewpoint.

Starting my role at Highline BETA allowed me to come up for air out of the iOS-exclusive stack I’ve been working primarily in since late 2010. Apple’s development tools and frameworks are honestly a pleasure to develop in. Any occasional gripes against them are natural for a community with extremely high standards.

Even though I feel that I still have some areas in Swift and iOS frameworks to revise and catch up on (SceneKit, I’m not finished with you yet…and hello, CreateML), I needed to broaden my general scope. That includes learning what the deal is with React Native, Kotlin in Android Studio and its potential as a cross platform language, and yes, maybe even looking into server-side backends.

Any dive into server-side backends for mobile developers usually comes in the form of serverless backends.

Serverless backends have existed for a while in mobile, and my first experience was with the brilliant but now defunct Parse. I’ve dabbled in a bit of Firebase since, but I haven’t extensively researched the existing capabilities of post-Parse backend as a service (BaaS, or MBaaS seeing as they’re mainly used in a mobile development context) until recently.

Little known fact — backend exists on mobile

First up, let’s recap on what exactly a mobile perspective on backends is.

It may come as a shock to non-mobile developers, but most mobile developers are familiar with the principles and have acquired the skills for what is commonly referred to as backend. The commonly used terms to describe very web centric development — full-stack developer, frontend developer, and backend developer — doesn’t really demonstrate any awareness for what’s actually involved in mobile development (hint: it could also encompass the full-stack, frontend, and/or the backend).

Outside of mobile it’s not well known (“use your mobile cache, bro”) that there is a, ahem, mobile backend. Probably because there’s not enough of us to warrant fancy LinkedIn titles for this work. Personally I try to refer to what is commonly referred to as backend, as server backend instead, to distinguish it from mobile backend.

Nothing unusual here, I’m just a regular mobile backend developer going to work. This is not a made up job title.

The 1st part of mobile backend, is search queries, database schemas, ER models, relationships, cascade rules, foreign keys, etc. Especially if that’s been prior knowledge we’ve acquired at university, it’s continually applied by anyone who’s been in the mobile space over a few years.

Although it’s less common to construct SQL calls directly (if you find a mobile developer who’s written a 20 line join query, it’s more of a vanity choice rather than being optimal for the platform). In iOS for instance, the datastore is wrapped in an ORM, Core Data. Searches are optimal using “predicate” syntax, inserts are optimal if your relationships are normalized…using these approaches you leverage the optimization that Apple has already made on the query level instead of reinventing it.

For this reason also, a lot of computational logic on the device isn’t a big deal (less so for cross platform, obviously, although cross platform should arguably be a low focus until high growth PMF is reached). In WWDC talks, Apple rams down the fact that we have a very powerful computer in our pockets — use it! This is an advantage the browser doesn’t have (although since my introduction to programming 10 years ago, people who can’t distinguish between potential and reality have continually tried to argue that the browser is just as powerful).

The 2nd part of mobile backend, is networking. Sure there’s an element of API integration in web UI, but in mobile there’s a bit more work involved. There are multiple threads to manage for a single window…and don’t get me started on what is involved in syncing to the mobile datastore (which in my experience, is over 50% of the time). In web, the server backend is the web datastore.

Picture for example, creating a mobile app that will find you places for lunch, using the Foursquare or Yelp API. Obviously Foursquare is its own company, and we’re not in control of how they’ve structured their API. We have to still define our schema and object models, around accessing the data that best suits the use cases of the app, not the API.

There are also non-ORM/ER datastore alternatives, such Realm or Firebase, which I’ll get into in a moment.

Anyway, the reason why I’m getting into this is because in mobile, a lot of the backend work has already been created. This is why BaaS is particularly appealing to mobile developers — we don’t want to duplicate the work, especially considering a lot of the computational logic makes a lot of sense to do on the device (for reasons touched on above regarding predicate searches, speed, etc).

The search for a dream BaaS

Therefore the ideal scenario, is to define a schema and model objects in Core Data (or in Android, Room Persistence), and simply deploy that to a server and have it auto-generate an API based on the schema and optimizations already made. Or vice versa, if the data modelling tools are just as good in the BaaS GUI.

Wouldn’t that be cool? It’s just a dream and does not exist yet. Well, it does kind of exist with using CloudKit Web Services. But that’s no good for Android apps — it’s a shame, because Apple’s Core Data & CloudKit stack is hands down the best set of tools I’ve ever used with persistent data.

The developer can either choose to define the DB schema & computational logic in the cloud, or on the device, and whichever the defined platform will deploy to the other one.

But trying to find out if there was a BaaS solution that was getting to that level of CloudKit, or one that would at least allow me to even define a schema or handle migrations, is what propelled me on this latest path of research.

The main players other than CloudKit, tend to be Firebase, Azure, and Backendless. There are a ton of resources written up on what these services do, so I’ll just capture a main summary of each.

Firebase

Firebase is perhaps the most well known BaaS solution, and is owned by Google. To Google’s credit, Firebase has expanded to become quite a juggernaut now, as it’s so much more than just a backend. In addition to their backend offerings, Firebase is their main dashboard for analytics, A/B testing, and even their machine learning framework.

On the database side they have 2 types of offerings, which can be summed up as old and new, but they call them Realtime Database and Cloud Firestore. The latter is supposed to improve on the original with the ability to write custom queries, and at least gives you the ability what type each of the fields are that you define. But the interface is still very JSON-like. Both databases are built on NoSQL, so it kind of seems like a misfire (ugh) that they haven’t offered an alternative for developers looking for something more structured.

Azure

Azure is Microsoft’s solution to BaaS. I haven’t tried this as much as Firebase or Backendless, but it didn’t seem as compelling to me. It gives the impression that it’s something made more for the enterprise, rather than lean MVPs (nothing wrong with enterprise, it’s just not my focus).

They do offer SQL though, but you can’t even try it without even adding your credit card info…so enterprise like. The UI doesn’t look great though, and if I’m going to hand over my payments info, plus the fact that I’m looking for a codefree backend, I need 5 star UI.

Backendless

Backendless aren’t owned by any of the major players, so straight away it has that somewhat independent startup allure. Their UI is pretty great too, and they actually enable you to set up a proper schema, so I was getting all warm & fuzzy flashbacks to Parse.

Their REST CMS interface seems very intuitive too. Exactly what you’d expect if you’re creating a database and an API, free of code. I couldn’t see if their database was actually using SQL technically, but their docs claim their database offers the “qualities of both” a relational and NoSQL DB. Backendless seems like the most compelling solution to me for these reasons. They don’t offer as many languages to write custom business logic, just JS and Java, but at least they have 1 strong typed and 1 dynamic typed covered.

So with Backendless being a reasonable solution, and Firebase being a moderately ok option as well, why is serverless still not where it needs to be?

For the most part, this blog post captures it well. Some of it might be contrived, I think they were really trying to hit 10. But concerns around migration, relationships (or lack of), querying, and creating an API, seem like dealbreakers.

Oops, maybe it’s not a gamechanger just yet. Only conceptually.

Dealbreakers I originally thought were resolved.

“It’s perfectly healthy – encouraged, even – to have an idea tomorrow that contradicts your idea today.” – Jason Fried, Basecamp

Dealbreakers that are all capabilities of the dream scenario above using Core Data (or something similar). Until BaaS gets to the level of that dream scenario, it doesn’t seem compelling enough.

With my skillset being mainly Swift, Server-side Swift (SSS) using Vapor seems to be a better solution…and most importantly, realistic. Vapor is here, and with Vapor 3 — a major update to take advantage of the Swift 4 Codable protocol — they’ve created Vapor Cloud to enable use of AWS “with zero configuration”. I’ll be checking it out this fall, and will be blogging (hopefully positively) on creating a custom backend with Vapor soon.

For a more extensive dive into the pros and cons of BaaS, Martin Fowler’s blog has a long essay that’s as recent as May this year (although it mainly touches on FaaS, the distinction of which is explained in the article).

Serverless backends aren’t compelling enough yet was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.