You can implement a CacheStore interface that will utilize this REST API for reading-through and writing-through your changes back to the stores. Or just deploy Ignite independently, preload it with the data from those stores. Use Kafka or anything else to stream changes from those stores to Ignite in runtime. If Ignite needs to write-back then you can do it explicitly from your Ignite-enabled app.
- Denis On Wed, May 1, 2019 at 11:33 AM Enrique Medina Montenegro < [email protected]> wrote: > Hi, > > Yes, I considered this approach, but my heterogeneous sources are actually > REST API calls. > > Regards. > > On April 30, 2019 23:42:10 Denis Magda <[email protected]> wrote: > >> Hi, >> >> Are you thinking of deploying Ignite as a shared layer on top of the >> sources? If that's the case then attach those sources to your in-memory >> cluster via the CacheStore interface: >> https://apacheignite.readme.io/docs/3rd-party-store >> >> >> - >> Denis >> >> >> On Mon, Apr 29, 2019 at 9:54 AM Enrique Medina Montenegro < >> [email protected]> wrote: >> >>> Hi, >>> >>> I came across Apache Ignite because I am struggling to find the best >>> solution to support a federated search from completely heterogeneous >>> sources. Let me elaborate a bit more. >>> >>> I have two distinct sources from different providers and I want my users >>> to be able to search in a federated way and apply criteria and >>> sorting/pagination/ordering to the merge of the results coming from both >>> sources. While at the beginning there will only be two sources, I expect to >>> keep adding new ones as users start familiarizing and finding advantages >>> based on its use. >>> >>> Therefore, would Apache Ignite be the proper technology to achieve a >>> temporary federation mechanism able to support my use case? Has anyone done >>> this successfully? If so, would you mind to share the approach? >>> >>> Thanks, >>> Enrique Medina. >>> >> >
