[jira] [Created] (GEODE-125) Provide additional native-language client bindings to GemFire's REST API.

["John Blum (JIRA)" <ji...@apache.org>]

John Blum created GEODE-125:
-------------------------------

             Summary: Provide additional native-language client bindings to GemFire's REST API.
                 Key: GEODE-125
                 URL: https://issues.apache.org/jira/browse/GEODE-125
             Project: Geode
          Issue Type: Improvement
          Components: client/server, general
    Affects Versions: 1.0.0-incubating
         Environment: Apache Geode + RESTful-based application clients in Geode's non-supported native languages.
            Reporter: John Blum
            Priority: Minor


This is an _Epic (story)_ to track the development of all applicable native REST client bindings implemented in different languages to allow those language-specific clients to interface with and use Apache Geode as the System of Record (SOR), Data Management Platform of choice.

Some *examples+ of different supported client languages could include, but are not limited to:

#. JavaScript
#. PHP
#. Python
#. Ruby
#. Scala

This effort would fill the void created as result of GemFire's native client *drivers* (C#/C++) not being open sourced.

The idea with the native client *bindings* would be to provide a native language look and feel to Geode's (GemFire's) API's.  For instance...

1. The binding could provide a first-class facade and support around Geode's primary data operations (e.g. {{Region.get(key)}}, {{Region.put(key, value)}}), as well as...

2. Provide support for the conversion of native language client class types and object instance into and from JSON automatically.  (Note, JSON is stored as a PDXInstance in Geode).  In this way, the native client application can work in strongly-typed objects natural to the language.

Keep in mind, that the performance characteristics as well as the UC's are different between native clients where a *driver* is available and where a *binding* could be provided.

The *drivers* are optimized for low-latency and will have an immediate performance advantage over the *binding*.

Still, there are things/features from the _driver_ the *binding* could implement, such as, but not limited to...

1. Single-Hop, direct data access to the Geode Server hosting the data (the "primary" in the PR case).

2. Load Balancing based on meta-data (JSON format) sent from a Locator.

3. Non-blocking, Reactive-style interface to Geode.

4. etc...

The later is important motivation for having the *bindings* over the *drivers* since the prevailing requirement and UC in most applications today is "responsiveness", which is not necessarily just a factor of latency.

There are many more ideas and things that could be explored here; please post in the comments to share your thoughts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)