Skip to content

Home

Jump to bottom
Andre Kless edited this page Sep 20, 2018 · 2 revisions

What this Repository contains

This repository contains a simple NodeJS ccm-compatible webserver for server-side data management via HTTP using MongoDB and CORS (index.js). See index.html in the Browser for testing CREATE, READ, UPDATE and DELETE operation. NodeJS and MongoDB and required npm modules must be installed (run npm install to use packages.json). Webserver and MongoDB must be running.

The following content describes ccm data management in general:

Table Of Contents

Introduction

The ccm framework provides a service for component developer for flexible data management. The service could be used with the method ccm.store. This method allows the usage of ccm datastores. A ccm datastore can manage datasets in one of three choosable data levels and could also be used autonomously of ccm components for easy data management.

Choosable Data Levels

Data Level 1: JavaScript Object

On the first level the data will be managed in a local JavaScript object. Than all managed datasets are fugitive data which are gone when webpage is reloaded.

Data Level 2: IndexedDB

On the second level the data will be managed in the client-side database IndexedDB. Than all managed data is still there after page reload. This is specially interesting for offline functionality.

Data Level 3: Server-side Database

On the third level the data will be managed in any server-side database of choice. The server must have an ccm compatible interface. Than all managed datasets are stored persistent on a server and they are not bounded to a specific client.

Dataset Properties

Every managed dataset must have a property key which contains the unique key of the dataset. There are no conventions for other properties. They can be as they want.

The following code shows an example for a ccm dataset:

{
  "key": "quiz",
  "question": "What is the meaning of life?",
  "answers": [ "nothing", "don't know", "ccm programming", "other things" ],
  "type": "multiple_choice"
}

Usage Example

The following code shows an first simple example for working with a ccm datastore:

// create a empty datastore of data level 1
const store = await ccm.store();

// store new dataset with unique key 'test' in created datastore
const created_dataset_key = await store.set( { key: 'test', value: 4711 } );

// get stored dataset
const requested_dataset = await store.get( 'test' );

// update stored dataset
const updated_dataset = await store.set( { key: 'test', value: 'foo' } );

// delete stored dataset
const deleted_dataset = await store.del( 'test' );

Supported Operations

A ccm datastore supports the following operation:

Operation Description
get(key) Gets a single dataset with the given key.
get(query) Gets all datasets that matches the given query.
set(data) Creates a new dataset that contains the given data.
set(prio) Updates an existing dataset with given priority data.
del(key) Deletes an existing dataset with given key.

Here you see which data level supports which operations:

Operation L1: JavaScript Object L2: IndexedDB L3: Redis L3: MongoDB
get(key) supported supported supported supported
get(query) supported - - supported*
set(data) supported supported supported supported
set(prio) supported supported supported** supported***
del(key) supported supported supported supported

* all specific MongoDB queries are possible ** no partial update (updates always complete dataset) *** support deep partial updates (with dot notation)

Note that on data level 3 the server not only can have Redis and MongoDB as database. This are only common examples. For example the server-side database must not be an NoSQL database. Which of the operations other databases support depends mainly on the server interface.

Server Interface

When a client uses a ccm datastore of data level 3 for data management, than the client must declare an URL to an ccm compatible server interface in the datastore settings. Then all datastore operations will be forwarded to this server interface. The server interface then can forward this operations to the server-side database. In this step the server interface must transform the according data in the form which the specific database can handle. Then the server interface sends the results back to the client in the form the client-side datastore can receive them.

The following example shows a very simple dummy server interface in PHP which receives the forwarded datastore operations and send them back to client without forwarding to a database:

<?php
// receive datastore operation
$get = $_GET[ 'get' ];  // READ operation: $get is dataset key (string)
$set = $_GET[ 'set' ];  // CREATE or UPDATE operation: $set is dataset (JSON)
$del = $_GET[ 'del' ];  // DELETE operation: $del ist dataset key (string)

// send dummy response back to client
if ( $get ) die( array( 'key' => $get, 'value' => 'foo' ) );   // get: result is requested dataset (JSON)
if ( $set ) die( $set[ 'key' ] );                              // set: result is dataset key (string)
if ( $del ) die( true );                                       // del: result is true (boolean)
?>

The server interface must not be written in PHP. For example it can also be written in JavaScript (with Node.js). An better professional server interface should think of the following aspects:

  • Cross-domain data transmissions with CORS or JSONP
  • Support of different network protocols
  • Security mechanisms for
  • More than one choosable database
  • Support of stable and efficient realtime communication
  • Server stability, availability and scalability

Usable Network Protocols

Different network protocols could be used for data transmission between client and server depending on the supported network protocols of the server interface. For example an server interface could support some of the following protocols:

To choose on client-side which supported network protocol should be used, simple use the corresponding prefix in the URL to the server interface in the datastore settings. For example:

  • http://path/to/server/interface.php
  • https://path/to/server/interface.php
  • ws://path/to/server/interface.php
  • wss://path/to/server/interface.php

Real-time Communication

In case of realtime communication with Web Socket as network protocol for a ccm datastore with data level 3, the server informs every active client about changing datasets. To react to this informations on client-side there only must be declared a onchange callback for the datastore. The parameters of the callback contain the server informations about the changed dataset.

The following code shows an example for declaring an onchange callback:

ccm.store( {
  store: 'my_store',
  url: 'http://path/to/server/interface.php',
  onchange: function () {
    console.log( arguments );  // Shows the server informations about changed
  }                            // stored datasets in the developer console.
} );

Note that changing a dataset not triggers the own onchange event. The server informs only other clients about changed data. Open the same website in a second browser tab to trigger the event.

Clone this wiki locally