Those of you who read the previous blog know that I'm a huge fan of OpenWhisk. It's one of those neat new-ish ways to do server side stuff without having to deal with the server too much.
Quick Primer on OpenWhisk
The idea behind serverless technologies is to encapsulate code logic in actions: each action can be written in any language, take a json as a parameter, and spit out a json as results. You can chain them, you have mechanisms to trigger them via cron jobs, urls, or through state modifications.
The example I used back in the day was a scraper that sent a mail if and when a certain page had changed:
cron triggered a lookup, lookup was written in Swift, checking HTTP code and content, passing its findings along an action written in Python that would compare contents if needed to its cache data stored in an ElasticSearch stack (yes I like to complicate things), before passing the data needed for a mail to be sent to a PHP action that would send the mail if needed.
It's obviously stupidly convoluted but it highlights the main advantage of using actions: you write them in the language and with the frameworks that suit your needs the best.
One other cool feature of OW is that when you don't use the actions for a while they are automatically spooled down, saving on resources.
OpenWhisk for iOS
There is a library that allows iOS applications to call the actions directly from your code, passing dictionaries and retrieving dictionaries. It's dead simple to use, and provides instant access to the serverside logic without having to go through the messy business of exposing routes, transcoding data in and out of JSON and managing weird edge cases.
For the purpose of a personal project, I am encapsulating access to some Machine Learning stuff on a server through actions that will query databases and models to spit out useful data for an app to use.
I'll simplify for the purpose of this post, but I need to call an action that takes a score (or a level) and responds with a user that is "close enough" to be a good partner:
struct MatchData : Codable {
let name : String
let level : Int
let bridgeID : UUID?
}My action is called match/player, and my call in the code looks like this:
do {
try WLAppDelegate.shared.whisk.invokeAction(
qualifiedName: "match/player",
parameters: p as AnyObject,
hasResult: true,
callback: { (result, error) in
if let error = error {
// deal with it [1]
} else if let r = result?["result"] as? [String:Any] {
// deal with it [2]
} else if let aid = result?["activationId"] as? String {
// deal with it [3]
}
})
} catch {
// deal with it [4]
}A little bit of explanation might be required at this point:
[1]is where you would deal with an error that's either internal to OW or your action[2]is the probably standard case. Your action has run, and the result is available[3]is a mechanism that's specific to long running actions: if it takes too long to spool your action up, run it and get the result back, OW will not block you for too long, and give you an ID to query later for the result when it is available. Timeouts both for responding and for a maximum action running time can be tweaked in OW's configuration. Your app logic should accomodate for that, which you are doing already anyways because you don't always have connectivity, right?[4]is about iOS side errors, like networking issues, certificate issues and the like
That Whole JSON/Dictionary/Codable Thing
So, OW deals with JSONs, which are fine-ish when you have a ton of processing power and don't mind wasting cycles looking up keys and values. The iOS client translates them to [String:Any] dictionaries which are a little bit better but not that much.
In my code I don't really want to deal with missing keys or type mismatches, so I map the result as fast as I can to the actual struct/class:
if let r = result?["result"] as? [String:Any], let d = try? DictionaryCoding().decode(MatchData.self, from: r) {
// yay I have d.name, d.level and d.bridgeID
// instead of those pesky dictionaries
}Of course, the downside is that decoders are called twice but:
- DictionaryCoding is blistering fast
- As long as I pass this object around, I will never have to check keys and values again, which is a huge boost in performance
Why?
My front facing actions are all written in swift, using the same Codable structures as the ones I expect in the app. That way, I can focus on the logic rather than route and coding shenanigans. OpenWhisk scales with activity from the app, and the app doesn't need a complicated networking layer.
My backend actions responsible for all the heavy lifting are written in whatever I need for that task. Python/TensorFlow, for me, but your mileage may vary.
