Komfo Platform API Explained

fishhookFladgeInternet και Εφαρμογές Web

13 Δεκ 2013 (πριν από 3 χρόνια και 10 μήνες)

124 εμφανίσεις











Komfo
Platform
API Explained

Description of concept and principles behind the scene in
Komfo Platform API proposal





Author: Daniel Zahariev







Abstract:
The proposed API for
Komfo Platform

aims for scalability, security, stability, increased speed,
independence from consumer’s device.

Editor:
Petar Atanasov

20 May 2011

1

|
P a g e


Table of contents:


1.

Introduction

2.

Terminology

3.

Concept

4.

JavaScript Template Engine and JavaScript API explained

5.

Proof of concept

6.

Migration

7.

Conclusion



2

|
P a g e


I.

Introduction


The current architecture of Komfo
P
latform will soon hit it’s limits with this pace of
growing which will be caused by the concept it was built around


that is MVC (Model
-
View
-
Controller) . The possibility of scaling this solution is strictly tied to arhictecture
power which is measured wi
th the number of application servers and their hardware
limits. One more
thing can become a major problem in long term evolution of the
system and it is the fact that the system is currently tied to browser clients, e.g. specific
consumer of the product. S
o in brief: the proposed API for Komfo Platform aims for
scalability, security, stability, increased speed, independence from consumer’s device.


II.

Terminology


In order to understand correctly the content of this document several specific terms
are
explained

and denoted
:



system



Komfo Platform



client



any user of Komfo Platform



consumer device



this is the device or software that the client uses to interact
with the system



Business Logic layer



a layer in the system architecture which takes care
of doing
the actual tasks of creating, replacing
, updating and deleting of objects in the
system



API



Komfo Platform API



SDK


Software Development Kit



c
luster


a group of servers which are running specific tasks



JXR (jaxer)



JavaScript Template Engine
and formatter



JS API


JavaScript API which will be developed as part of the proposed API







3

|
P a g e


III.

Concept


The concept around the proposed API is very simple and yet powerfull because

of it’s
basis. Graphical representation

of current architecture state
:


4

|
P a g e


As
can be seen the current architecure

is built to serve content to only once consumer
device


computer. On top of this the Business Logic layer and UI generation layer are
internally separated but come together as a single unit in the system. Following the
growing market of mobile devices and their rapidly increasing CPU power the market for
mobile applications is growing accordingly. They already have the power to run
customized browsers and many applications use them as base SDK
. There are several
consecut
ive restrictions this

environment: smaller screen leads to different design and
HTML; browser specifics and user interactions are handled in a different way; internet
speed isn’t comparable to computer’s. But in the end the actual data remains the same
and

only the representation and interaction are device aware. One more alternative to
the only one customer device now supported are external services and applications that
can be built ontop of the system or integrate with it in some way. Currently they can’
t
benefit and actually use the business logic in the system because it is bound to it’s visual
representation using HTML. Having all this in mind we’re proposing a new conceptual
architecture:

5

|
P a g e



In both graphics the connection between consumer devices is o
nly referred as AJAX
request because this is the main target for the proposed API in the scope of client
interaction. In the proposed architecture design all business logic will be deployed to a
new cluser

and it is referred as Komfo Platform API. The curr
ent application servers will
be using it in order to perform business operations
. Also the clients can connect directly
to the API
using JS API which will be loaded in the browser and will be unified for all
consumer devices. This will increase the latency

of the servers, lower the trafic, and
boost the

speed, which we have to prove.

The latency will be increased because the API
will be built on a lower level of code abstraction and will be more fast which means that
the same tasks will take less time to do
. Lowering the trafic is a result from the concept
6

|
P a g e


of the API to return only raw data which is less than when it is represented with HTML
which is also faster. Boosting the speed


well
having in mind previous two points we
are also going to use JXR


a Ja
vaScript Templating Engine that is very fast and is going
to translate the raw data coming from the API to an actual HTML representation using
templates that are consumer device aware.

IV.

JavaScript Template Engine and JavaScript API explained


The JavaScript

API can be tho
u
ght

of

as Facebook’s JavaScript SDK which provides
access to almost all of their APIs (except when uploading files) and is strictly tied to the
permissions the user has. The same concept is proposed to be implemented.

When this
JS API makes

a call to the system’s API the returned raw data will be processed and
transformed to HTML which is then displayed to the client. The JavaScript Template
engine is called JXR (pronounced: jaxer) and is well suited to our needs.

V.

Proof of concept


A small
proof of concept page is created to present the principle described above.

The page is located here:
http://test2.komfo.net/komfo_api_concepts/fb.html
. It uses
Facebook’s Graph API as a data

source


more specifically to extract the feed of a given
Facebook Page (
f8
) and display it. This example uses JXR and a template built to
transform the raw data to a nice view. There is no server side code


it
is pure JavaScript
+ HTML + CSS.
This aims to prove the efficiency of such model and concept where the
the raw data is transformed to specific view/design depending on the consumer device.

Here is the process in behind:




7

|
P a g e


VI.

Migration


The process of impleme
ting the API has several steps which can be done one by one
and be spreaded to a long term effort to improve the system and will not interfere with
other of it. Here are the the main steps

of migrating to the API architecture
:



Create a cluster for the API
and define basic rules for the code



Move Business logic part by part to the API


there is no need to move
everything at once



Create a JS API


once created it can be used with all parts of the Business
logic implemented on the API


VII.

Conclusion


As a conclusion we may say that
this concept will grow the Platform’s potential for
new exciting mashups of any kind which is something notable.