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.
If you're looking to lower storage costs by compressing your data and get better query performance when querying the data in Cloud Object Storage, you may want to click to learn how to convert CSV objects to Parquet.
Consolidating PostgreSQL data into a durable and highly reliable data storage service like IBM Cloud Object Storage will not only reduce costs, but it provides a flexible, durable, and scalable solution for storing all sorts of unstructured data.
In this third part of a four-part series on Operationalizing SQL Query, we'll bring together the microservices we deployed in Part 1 to query data in IBM Cloud Object Storage (COS) using the techniques we developed in Part 2 using IBM SQL Query with the goal of connecting our application's data to Business Intelligence (BI) tools.