Details
-
Improvement
-
Status: Resolved
-
Minor
-
Resolution: Won't Fix
-
1.0.0-incubating
-
None
-
Apache Geode + RESTful-based application clients in Geode's non-supported native languages.
Description
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.