The ability to dynamically, yet intelligently create Regions on the client as well as the server is being handle in SDG^2 right now, under the new Annotation configuration model (inspired by *Spring Boot*, *auto-configuration,* work I did in *Spring Session *and *SD Cassandra,* and tidbits I came up with specific to SDG).
The main driver for this is PCF, and in particular, PCC (and now even SSC), which will replace the needless and "explicit" look-aside caching in developers' application code given *Spring (Boot)* is the primary *programming model* on PCF and Spring's Cache Abstraction <http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#cache> [1] has been around basically since the inception of SDG (in 2010), which employs AOP and basically makes "explicit" look-aside caching moot (actually quite ridiculous). Given the Annotation/auto-configuration model and approach, there will be no explicit APIs the user needlessly call to make certain things happen on the server, yuck, why!? We know all we need from the application and that is what SDG can and will do. Of course, it does not mean the developer will not be able to customize things as necessary, but the developer certainly will not be tied to any Geode API when doing so. For instance, I know that when a developer is using the SDG mapping infrastructure <http://docs.spring.io/spring-data-gemfire/docs/current/api/org/springframework/data/gemfire/mapping/package-summary.html> [2] and specifically, the annotations (e.g. generically @Region, or specifically, @PartitionRegion), most likely because the developer is also using another very powerful concept, *Spring Data Repositories* (for CRUD, querying and in certain cases (Function/Procedure) executions, depending on the store) the Regions the application will need. I plan to extend this "intelligence" for *Spring's Cache Abstraction* since SDG is a provider <http://docs.spring.io/spring-data-gemfire/docs/current/reference/html/#apis:spring-cache-abstraction> [3] and again, it is another simple matter to derive the Regions needed for "caching" (whether that is arbitrary @Service methods or Session state... enter SSC). This is the second time today I heard of yet another API for Geode, when we seemingly already have too many ways to skin a cat... Geode public API <http://geode.apache.org/releases/latest/javadoc/index.html> [4], cache.xml, *Cluster Config* with *Gfsh*, SDG. Yikes, talk about confusing to users especially when I messaging is mixed across the org. In my mind, there really are only 2 approaches... *Spring* and non-*Spring*, or rather PCF and non-PCF, and since PCF is primarily based on Boot (given Microservices/applications are the new concurrency), then I am really saying the same thing. Now, having an *async API* is something that I think is very interesting and maybe worth the effort since it serves a specific purpose. I also heard that there may potentially be a JSR-107 Cache API implementation coming, which would be great! But I would *caution* not to create overlap! If there is, there better be a pretty good reason for it, otherwise it will only add to the complexity/noise of what the user already needs to understand to get started. While SDG's dynamic Region creation is similar (in implementation) to *Gfsh's* `create region` functionality (that is not the hard part if the user really wanted similar functionality from the client, honestly), it is also very "unique" in it's approach since it is *driven by the application domain/UCs* and *automatic*. Much of the "future functionality" is already covered (e.g. Durable Clients, Serialization, Function Execution, Querying, CQs, RI, etc, etc) in SDG today, or by other means, depending on what you mean. Pertaining to some of the other comments/feedback... *+1* to distinguishing clients and APIs. *+1* to REST API for mobile. *-1* to referring to this as a *Reactive* API. Keep in mind that Async and Java Futures are not "Reactive". Reactive <http://www.reactive-streams.org/> [5] is all about async, "non-blocking" and "back-pressure" [functional] APIs. The eventual call to Future.get() blocks. A more robust solution would be Java 8's CompletableFuture <https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html?is-external=true> [6] and prior to Java 8, *Spring's* ListenableFuture <http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/util/concurrent/ListenableFuture.html> [7], which supports callbacks, but these are not completely "*Reactive*" in nature (i.e. no back-pressure) unlike Mono <https://projectreactor.io/docs/core/release/api/index.html?reactor/core/publisher/Mono.html> [8] and Flux <https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Flux.html> [9] types in *Reactor*. I should also mention that since "*Reactive*" is a main theme in *Spring* 5 and *Spring Data* builds on core *Spring*, that *Reactive* stores are all the buzz right now, which was definitely apparent in the Berlin-DE JUG I attended recently. Many were using Mongo and Couchbase, which like Redis, have Reactive drivers already. Plus, it simply does not make sense to have a Reactive front-end (e.g. Web) without a Reactive backend (data access tier). Therefore, my eventual goal (EOY), given much of the *Spring Data Reactive Repository* infrastructure <https://github.com/spring-projects/spring-data-commons/tree/2.0.0.M2/src/main/java/org/springframework/data/repository/reactive> [10] is already in place, will be figuring out what parts of Geode/GemFire to make Reactive, or rather wrap in an Reactive API (e.g. CQ -> Flux using *Reactor*). Food for thought. I am very much open to more discussions on these sort of matters (API design, Reactive Stream, etc). Cheers, John [1] http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#cache [2] http://docs.spring.io/spring-data-gemfire/docs/current/api/org/springframework/data/gemfire/mapping/package-summary.html [3] http://docs.spring.io/spring-data-gemfire/docs/current/reference/html/#apis:spring-cache-abstraction [4] http://geode.apache.org/releases/latest/javadoc/index.html [5] http://www.reactive-streams.org/ [6] https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html?is-external=true [7] http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/util/concurrent/ListenableFuture.html [8] https://projectreactor.io/docs/core/release/api/index.html?reactor/core/publisher/Mono.html [9] https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Flux.html [10] https://github.com/spring-projects/spring-data-commons/tree/2.0.0.M2/src/main/java/org/springframework/data/repository/reactive On Mon, Apr 24, 2017 at 4:30 PM, Michael Stolz <mst...@pivotal.io> wrote: > We used to always say "client library" but somehow people started dropping > "library". > > -- > Mike Stolz > Principal Engineer, GemFire Product Manager > Mobile: +1-631-835-4771 > > On Mon, Apr 24, 2017 at 7:07 PM, Michael William Dodge <mdo...@pivotal.io> > wrote: > > > Perhaps I'm picking nits, but I think a library that provides an API for > > interacting with Geode isn't a client. (I like to call it a driver.) The > > client is the application that someone write to use that API to interact > > with Geode. I recognize that in the past the C++ library for Geode has > been > > called the "native client" but to me the term "client" implies a > > stand-alone application that has user functionality built into it. > > > > Sarge > > > > > On 24 Apr, 2017, at 15:03, Fred Krone <fkr...@pivotal.io> wrote: > > > > > > In an effort to improve Java developer ease of use for caching with > > Geode I > > > am looking for feedback on going forward with creating a Java client. > > This > > > client will allow for server-side region creation and distributed data > > > caching. This would allow for a thin client that fits with > microservice > > > caching patterns and also abstracts a cleaner client-server experience > > > driven interface. > > > > > > Initially we were going to update the Region interface but were > concerned > > > with breaking existing applications. We also would like to provide > > Region > > > creation to a client application and so propose here solving both of > > these > > > areas with a Java client. > > > > > > It would have new project repo for the client. > > > > > > It would provide new Region interface for clients. The specifics of > the > > > API design are too lengthy for this conversation but implementation > will > > > resemble JSR 107 Cache interface. > > > > > > It would use the new security framework. > > > > > > > > > *An example*, > > > > > > The client application simply creates an instance of client and points > it > > > to the locator: > > > > > > > > > org.apache.geode.client.Client client = Client.create(locatorHost, > > > locatorPort); > > > > > > > > > Client has the following methods: > > > > > > package org.apache.geode.client; > > > > > > > > > public interface GeodeClient { > > > > > > /** > > > > > > * creates the region on the servers, or gets the region if it exits, > > > returns a PROXY region > > > > > > */ > > > > > > public Region getOrCreateRegion(RegionAttributes attributes, String > > name); > > > > > > > > > /** > > > > > > * Returns a PROXY region if the region exists on the server > > > > > > */ > > > > > > public Region getRegion(String name); > > > > > > > > > > > > > > > > > > > > > MVP > > > > > > The smallest set of features to test this idea, learn and iterate, and > > get > > > the client into the communities hands for future iterations is: > > > > > > > > > Create a server side Region from a client > > > > > > Region interface has CRUD on par with javax.cache.Cache (from JSR 107) > > > > > > Calls are asynchronous -- futures > > > > > > > > > > > > Also would like feedback on which future functionality would be most > > useful > > > from a thin client: > > > > > > Function execution > > > > > > Durable clients > > > > > > User defined serialization > > > > > > Register interest > > > > > > Queries > > > > > > CQ > > > > > > Near side caching > > > > > > Create disk stores from client > > > > > > Region group membership > > > > > > Client subscription load balancing > > > Transactions > > > > > > > > > Thanks, > > > -Fred > > > > > -- -John john.blum10101 (skype)
