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.
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:
docker run — rm -it -v “$(pwd):/owexec” openwhisk/action-swift-v3.1.1 bash
This example adds swift-watson-sdk and example-package-deckofplayingcards dependencies. Notice that CCurl, Kitura-net, and SwiftyJSON are provided in the standard Swift action so you can include them in your own Package.swift.
One key aspect of a robust architecture is that it is built to smoothly handle system failures, outages, and configuration changes without violating the data loss and consistency requirements of the use case. To proactively build such solutions needs an understanding of the possible exceptions and risky scenarios and preparedness to manage them efficiently.
To hit the ground running for any project based on cloud-based applications, it is very important to set up the associated infrastructure for the development of microservices. Quick and high-speed development can be achieved if the team has a way to do Continuous Integration (CI) and Continuous Delivery (CD) of the application.