For Performant Swift Serverless actions…
While coding and drafting “Mobile app with a Serverless Backend”, We came up with an idea to use Swift on the server-side for the iOS app (it’s an interesting use case).So, that it will cater the full stack swift developers out there. The same is true for the Android version of the app as well. Here’s an architectural interpretation of what we wanted to achieve,
As an initial step, I started exploring Swift actions under Functions (FaaS) on IBM Cloud. My first challenge was to authenticate the user through AppID service and this should entirely happen on the server-side in a Swift action. I figured out that there is an introspect API endpoint which will validate the token your pass. This is good, can I use external packages like SwiftyJSON inside a Swift Cloud Functions action? This will be answered soon.
Here’s the action to validate a token
You can find other actions here.
Clone the code from by running the following command on a terminal or download the code from the github repo,
From the architecture diagram, you should have figured out that once we are authenticated the next steps are to add the user through one of the actions and then save the feedback provided by the user along with his device id (to send push notifications). There is a trigger associated with feedback table so that once a new feedback is added to the table, the trigger will be triggered to send the feedback to Watson tone analyser and the output tone is passed to Cloudant to map and send the associated message as a push notification to the feedback provider/customer.
This is all good and interesting. What will be the execution time for this flow to complete?
Ok, let’s see the execution time of one action and also, how to improve the performance?
If you observe, the initial serverless action call took 5.51 secs to complete and subsequent calls are faster. So, what exactly is the reason? Here’s what IBM Cloud Functions documentation says
When you create a Swift action with a Swift source file, it has to be compiled into a binary before the action is run. Once done, subsequent calls to the action are much faster until the container that holds your action is purged. This delay is known as the cold-start delay.
How to overcome this and make our Swift Cloud Functions actions performant from the word go by avoiding cold-start delay.
To avoid the cold-start delay, you can compile your Swift file into a binary and then upload to Cloud Functions in a zip file. As you need the OpenWhisk scaffolding, the easiest way to create the binary is to build it within the same environment it runs in.
See the following steps:
Run an interactive Swift action container by using the following command:
Copy the source code and prepare to build it.
(Optional) Create the
Package.swiftfile to add dependencies.
This example adds
example-package-deckofplayingcards dependencies. Notice that
SwiftyJSON are provided in the standard Swift action so you can include them in your own
Copy Package.swift to spm-build directory
Change to the spm-build directory
Compile your Swift Action.
Create the zip archive.
Exit the Docker container.
You can see that ValidateToken.zip is created in the same directory as ValidateToken.swift.
Upload it to OpenWhisk with the action name authvalidate:
To check how much faster it is, run
Refer this link for installing Cloud Functions standalone CLI
The time that it took for the action to run is in the “duration” property and compare to the time it takes to run with a compilation step in the ValidateToken action.
So, what will be the performance improvement when I run an action with a .swift file for the first time and an action with a binary file.
Here’s the answer,
auth-validate is an action created with .swift file and authvalidate1 is an action created with a binary file.
Don’t forget to refer our other solution tutorials covering this end-to-end usecases and scenarios.