#BlueCloudMirror Game – highscores

I am a part of the team along with @Niklas and @Harald , who created and developed the fun Blue Cloud Mirror Game. 

This is my first blog  about this topic, and I will follow with future posts to detail the different parts of highscores (scores) and the technologies and components involved.

You can also take a look at other existing information:

• PLAY THE GAME 
• basic overview of the game (3mins)
• simplified high-level architecture 

• users of Kubes and Couches 

• source code on github
• pattern on IBM Developer

The motivation for the highscores (scores)

If you play a game, you usually want to compare yourself with others. To do this, you simply have to save scoring information somewhere and provide access for the players who want to see the highscores, even if they do not play the game.

The high-level architecture overview on scores

The objective was to implement this on the cloud with state-of-the-art runtimes, services, security topics, to cover microservices, and to have an easy scalable cloud architecture.
I developed the scores part and the functions-api for users.

The Game, Scores Service UI and the Highscores webapp are hosted on different runtimes and for the execution they will be loaded into a browser.

Here is a short description of the major elements on the diagram.

• WebApp

The WebApp is the Highscores WebApp for the Blue Cloud Mirror Game. It is implemented in VUE a very easy and a great open source framework to develop interactive web UIs.

It uses the scores functions API to display the scores list and high scores.

The reason we decided to create an extra UI for the Highscores, was to offer users an independent view and to get a good starting point for other management abilities in the future.  You can navigate from the Highscores App to the Blue Cloud Mirror Game just using a link.

The live running sample App is hosted on a Cloud Foundry Enterprise Environment using  Node.js and is tested on Chrome browser for desktop.  A Cloud Foundry  environment made it easy for me during development to not waste time with the infrastructure.

• Functions API

The functions API is our serverless approach to secure the service API or scores service. For the future we plan to integrate with the APP ID service, so we are more flexible for an OOTB user login for both Apps. (user authorization serverless web applications openwhisk)

For this implementation IBM Functions is used. IBM Functions is based on Apache OpenWhisk and it involves the IBM Lite API Management which exposes the APIs. The APIs here are implemented in actions or sequences. 

 
Note: You also can combine API Connect with Lite API Management.

Actions enable the access to service API or scores service and this can be configured, so not two API Managements need to be in place.

Here you can see an execution of an action to get the scores list.

• Service API

The service API is realized with API Connect. API Connect is a professional API Management service to create, secure, manage and scale APIs. This was our choice to secure the REST calls from the scores service. 

In this gif you can see how to test a rest call internally in API Connect.

• Scores Service

The scores service is responsible for managing and saving score data.
At the moment, I have implemented the service to use the nosql database Cloudant. The major objective the scores service is to provide the add score and list score functionalities for the Game results.

This gif shows small view of the scores-service UI to test the service.

Note: The live scores service is hosted on a Cloud Foundry Enterprise Environment.

I hope this was useful for you and let’s see what’s next?

Greetings,

Thomas

PS: By the way, you can use the IBM Cloud for free, if you simply create an IBM Lite account. Here you only need an e-mail address.

#BlueCloudMirror, #IBMCloud, #VUE, #APIConnect, #CloudFoundryEnterpriseEnvironment, #IBMFunctions, #OpenWhisk, #Node.js, #IBMDeveloper