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

["Anthony Baker (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anthony Baker resolved GEODE-125.
---------------------------------
    Resolution: Won't Fix

Closing due to lack of interest.  Please reopen if needed.

> 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
>              Labels: ApacheGeode, Bindings, NativeClient, REST_API
>
> 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
(v7.6.3#76005)