Sangeeth's technical blog: Kitura/iOS: Running a Microservice farm on your iPhone

Originally published in 2017 in the IBM swift initiative blog website. Entire project initiative failed and all the articles were removed including this. Republishing the archive here just to keep my content alive. In 2021, this content is not so relevant.

Full disclosure: I'm a newbie Swift developer. That said, in my opinion, opening the Swift language to server side development is the best contribution that Apple has made to the enterprise world. IBM turbo charged this engine with the powerful framework Kitura.

Since WWDC 2016, I have learned from many technical folks who contribute to the world of Kitura. These folks have inspired me to explore and thus understand the capabilities of server side Swift. Fellow IBMer Vadim Eisenberg published the blog post "Kitura/iOS: Running a Web Server on your iPhone" about the ability to run Kitura on iOS device with some use cases. In this blog post, I'm expanding on Vadim's idea to create a Kitura server farm with iOS devices using a modularized approach.

Typically, when I think about rapid prototyping to showcase a business use case to clients or to add a quick feature (say Oauth2.0 Authentication) into an existing application to understand how the feature binds work with the app, iOS development skills are not enough. Next thing I know, I'm searching for a backend developer to create a quick microservice and deploy it to the behemoth deployment server instances, whether on-premise, Bluemix cloud, or others.

The rapid iOS application development process is a focused area in agile-based projects. In this post, I've extended this to a rapid end-to-end app prototyping process. The feature components are independent, pluggable, and loosely coupled. Developers on an iOS team can reuse their iOS device/simulators to set up a farm of independent microservices for rapid prototyping before migrating to a cloud-based solution like Bluemix.

This approach leverages and extends iOS-only features to the Kitura server side application.

With it, any iOS developer can create the backend microservice in just a few minutes and deploy it on a phone or simulator. The microservices are more independent and modularized. They're also consumed as REST APIs in the iOS application.

This advantage is efficient and maximizes device vitalization. You don't have to rely on a heavy cloud deployment platform to perform a simple feature test (that's pretty cool!). It is simply iOS to iOS. A web application can also use these microservices running on our devices.

Before you upgrade the backend feature on the production environment, you'll want to quickly prototype the new feature service to understand the behavior of the iOS App. For example, if you have an iOS app that uses Simple Digest Authentication and the client wants to upgrade it to OAuth for its advantages and benefits, you'll want to prototype this feature.

Possible approaches

Create a Kitura-based microservice, convert it to an iOS compatible app and deploy it on your iOS devices, such as an iPhone, iPad, or an Xcode simulator. Use the built-in core data light weight DB service rather than a cloud-based DB service. Run the container app and expose the service as a REST API and consume it from the external client app.

You can independently create several services and deploy them on different iOS devices. Make sure you use a feature service toggle to understand the behavior. For example, run two authentication services – SSO open ID and OAuth2 on two devices. Let the client application use the toggle to switch and bind between the two different services.

The first approach is straight forward and a direct use case. However, I am more interested in showing the second approach which explains the farm of server concept.

You might already be thinking about the potential drawbacks and wondering how a simple iOS device in your pocket can achieve the benefits of an enterprise server. After all, when you think of "server," you think of:

· Reliability

· Availability

· Robustness

· Fault tolerance

The most visible issue people think of is that the iPhone running the microservice disconnects from the network or the battery dies. There's a simple and feasible solution for both those issues.

“There exist many simulator instances and other devices in the development team. Cluster them to make a network of always-available service.”

</pullquote>

Referring to the original article that inspired this, "Kitura/iOS: Running a Web Server on your iPhone," I created a working PoC model to demonstrate using a farm of Kitura/iOS as an available-server for rapid prototyping. I also created an iOS Book Listing application and an authentication and book listing page (all available on GitHub, referenced from the bottom of this article).

The iOS app uses two different API services:

· An authentication service that takes a username and password to validate the user.

· A book service that fetches and returns a list of book names from Cloudant DB on Bluemix.

In addition, you'll use the Kitura based controller service, (API Gateway Bluemix Service) that runs on Bluemix to:

· Register or deregister the feature service nodes

· Return the available service node’s URL address to the app when requested.

Bluemix is used to differentiate and demonstrate the controller. The node can run on any iPad/MAC OS/ Linux based systems in realtime. The architectural diagram below explains the concepts.

Work flow

Two simple Kitura based services - book and authentication service are created and deployed on different available iOS devices and simulators. Once the app launches, the service running container App registers the iOS device as a participating node on the controller server. When the Kitura server starts in the service running iPhone node, the API manager service updates with new node’s service availability. Now, the controlling node or the manager service contains information like URL endpoints, availability status, etc. about all the participating devices.

When the ‘Book List iOS App’ is launched with the login page, it requests the controller to return any of the available node’s end-points for the login service. The user logs in with credentials and enters to the next screen where view loading function requests the end-point of a book service node and starts to make HTTP Rest API calls. With the second service end-point, the app fetches the list of book names and displays the result in a table view.

A negative scenario: The controller assumes that the service providing node is available and returns the end-point URL to the client App. By the time the client application sends requests to the REST API, the service providing node might fail. In a typical client - server language – we say, ‘status code 500 Error: Server down’.

To solve this, the iOS app reports the unavailable or faulty end-point to the controlling node immediately, where an algorithm at the controller determines the next available alternate service node (which is nothing but another iPhone or iPad device) and returns the new end-point URL to the App to continue client-server communication. So, in simple terms, the controlling node mimics a middleware or load balancer role.

Below are some screenshots and demo video to demonstrate the design model and flow.

Demo video

https://ibm.box.com/s/z9kyae6oqvcc9zbrq0r022jk0pkf8ohr

Conclusion

This is an attempt to showcase the capability of KITURA + IOS + SWIFT as a modularized approach for Rapid Prototyping. We could also think about a use case where clustering these idle devices can be sued for backend computation [2]. I have focused more on the approach above and not on the details of the code. For the developer’s reference, the source code is available in my GIT repository (given below the links). I encourage you to create Bluemix account, try out and learn Kitura Swift.

Special thanks to all my mentors and managers for their support and motivation.

Get the code

Four different individual applications were developed and checked in to different repositories on GitHub for you to reference. You will need to add the credentials and Swift package build.

· API Gateway Bluemix Service

· Authentication Service

· Book Service

· iOS Book Listing

https://github.com/sangy05/Kitura_IOS_ExtendedServer