We previously talked about how Gluon CloudLink can run serverless code for Mobile Enterprise applications. Today we give a concrete real-world example on how a mobile application benefits from a Function-as-a-Service (FaaS) platform. MyDevoxx is a conference scheduler application created in Java for the different Devoxx conferences. Users can view the session and speaker catalog, create a personal schedule, mark sessions as favorite and much more. The project is open-source and hosted at GitHub.
The Devoxx team hosts a backend application that is used by a number of clients (e.g. web-based). This backend provides functionality to the different Devoxx conferences through a REST API that is available at https://cfp.devoxx.be/api. The MyDevoxx mobile application uses this API to retrieve the session catalog. However, retrieving this catalog doesn’t happen in a single call.
First, we need to retrieve the list of days for a specific conference. The following REST endpoint is called to get the conference schedule for Devoxx Belgium: http://cfp.devoxx.be/api/conferences/DVBE17/schedules/
The response of this REST call contains links to a subsequent REST call that will return the detailed schedule for a specific day, i.e. http://cfp.devoxx.be/api/conferences/DVBE17/schedules/monday
Hence, in order to retrieve all sessions for a specific Devoxx conference, a number of REST endpoints need to be called, in the correct order. Previously, this was all done in the mobile application code. The code first retrieved the days for a specific conference and then subsequently retrieved the sessions for each day. A CountdownLatch was used to make sure the retrieval method only returned when all sessions for all days were obtained.
While this code works, it requires boilerplate code and there is a fair risk of introducing bugs. Moreover, if any of the Devoxx REST endpoints ever change, the mobile client code would need to be changed as well. All instances of the MyDevoxx application on all mobile devices would need to be updated or they would stop working. That is a huge issue, as it is not possible to force the end user to update a mobile app.
By moving the code to a backend environment, these problems can be solved. The combination of Gluon Mobile on the device with Gluon CloudLink allows for a simple and decoupled approach. On the mobile client, we simply use the Gluon Mobile APIs to call a function that is defined at Gluon CloudLink. The definition of the function at Gluon CloudLink maps the function name to a remote invocation, which can be a REST endpoint or an invocation of a serverless Function. Gluon CloudLink supports two types of serverless Functions: AWS Lambda and Functions created with the Fn Project. The commit log of the My Devoxx app shows that by using a serverless Function, more than 100 lines of code could be removed from the client.
The logic that previously was applied in the client code can now be uploaded as an AWS Lambda or an Fn Function. The logic is completely stateless, so it doesn’t make sense to create a complex backend application for this. For these use cases, serverless Functions are a perfect match. In case something changes in the Devoxx backend, the Function needs to be updated. This is something that can easily be done by an operator and doesn’t require any change at all to the (hard to control) mobile devices.
Serverless programming can make the development of Mobile Enterprise applications easier, more flexible and less error prone. With Gluon CloudLink, you can easily manage Functions that need to be called from your mobile applications.
If you want to hear more about how the MyDevoxx mobile app has been created, you can attend our BOF at the Devoxx Conference, Thursday at 7 pm.