what's the best solution to make kotlin and elasticsearch comunicate - spring-boot

Using google i found two possible solution for now:
-using spring boot with kotlin
-using this kotlin client https://github.com/jillesvangurp/kt-search
I've already finished the android client application in kotlin but now i have to find a way to make this client comunicate with elasticsearch.
What would it be the best solution for my problem that i could look up online
Thanks in advance

First, if you don't use Spring in the current application, integrating it (if possible) would be a lot of work and most likely not worth it.
Another alternative would be to use the officially supported Java client for Elasticsearch (https://www.elastic.co/guide/en/elasticsearch/client/java-api-client/current/index.html).
BUT, you should keep in mind that, if you put the Elasticsearch client in your client application, that the credentials, you may use, will also be in the client application.
They could be accessible for everyone using the Android client and the user could perform any request on the Elasticsearch. Also you couldn't change them without updating the client.
So, it is likely better to use a Three-Tier-Architecture (https://www.ibm.com/topics/three-tier-architecture) and creating an API service to handle the Elasticsearch requests.

Related

How to consume external websocket API in Apache Camel since ahc-ws deprecate?

ahc and ahc-ws (Async Http Client) components have been deprecated in Apache camel version 3.16: https://issues.apache.org/jira/browse/CAMEL-17667.
Is there an alternative for ahc-ws? The component was very easy to use to consume external websockets API.
Other libraries like Jetty, Undertow, Atmosphere, don't seem to offer this kind of features. I have not been able to configure them and the documentation remains unclear. They only provide the server part.
For the websocket-jsr356 component, I can't configure the component to consume a WebSockets over SSL API (wss). The library seems to support only classic websocket (ws).
I looked for alternatives on the camel doc, examples on github but I didn't find anything.
Is there a viable alternative to ahc-ws to consume external websocket APIs simply with camel?
Thanks a lot
Looks like it's not deprecated yet. There is just a suggestion for that. ahc-wss is very useful currently and there is no viable alternative for the same. websocket component requires tedious tweaking of secure storage parameters and is just kills the purpose of wss. I hope they don't deprecate ahc-wss without a proper replacement though.

Jersey for desktop application [duplicate]

I have a small Java SE application, it´s practically a fat client sitting on top of a database. To further my Java skills, I decided to make a client-server application out of it. The server application communicates with the database and handles all kinds of lengthy operations, while the client application only receives the results, mostly ArrayLists of moderate length and primitives.
To this end, I started reading on RMI and did the Oracle tutorial, which I found surprisingly difficult to understand and even get to work.
Is there anything else I can use instead of RMI, without having to dive into JavaEE?
One way I would suggest would be to use JSON as the format for data exchange. You can use GSON to convert the data from Java objects to JSON and back. The transport could be done directly on the HTTP protocol using REST. You can use Jersey as a REST server/client or roll your own (since you don't want to use JEE, which Jersey is part of).
SIMON is as simple to use as RMI, but with fewer traps in the initial setup. It also has some advantages over RMI. Here is a simple hello-world example:
http://dev.root1.de/projects/simon/wiki/Sample_helloworld110
I take it RMI = Remote Method Invocation ...
You can have a look at XMLRPC, JSONRPC, JMS, or if you want to roll your own, use JSON to POST messages and convert the JSON back to a java object on the other side using GSON (from Google) or setup RabbitMQ and use AMQP to submit and receive messages if you don't want to handle the POSTing yourself, Spring AMQP makes it fairly easy to do this.

Elastic search high/low rest client vs spring rest template

I am in a dilemma over to use spring's rest template or elasticsearch's own high/low rest client while searching in es . Does es client provide any advantage like HTTP connection pooling , performance while compared to spring rest template . Which of the two take less time in getting response from the server . Can some one please explain this ?
The biggest advantage of using Spring Data Elasticsearch is that you don't have to bother about the things like converting your requests/request bodies/responses from your POJO domain classes to and from the JSON needed by Elasticsearch. You just use the methods defined in the ElasticsearchOperations class which is implemented by the *Template classes.
Or going one abstraction layer up, use the Repository interfaces the all the Spring Data modules provide to store and search/retrieve your data.
Firstly, This is a very broad question. Not sure if it suits the SO guidelines.
But my two cents:
High Level Client uses Low Level client which does provide connection pooling
High Level client manages the marshalling and unmarshalling of the Elastisearch query body and response, so it might be easier to work using the APIs.
On the other hand, if you are familiar with the Elasticsearch querying by providing the JSON body then you might find it a bit difficult to translate between the JSON body and the Java classes used for creating the query (i.e when you are using Kibana console or other REST API tools)
I generally overcome this by logging the query generated by the Java API so that I can use it with Kibana console or other REST API tools.
Regarding which one is efficient- the library will not matter that much to affect the response times.
If you want to use Spring Reactive features and make use of WebClient, ES Libraries do provide support for Async search.
Update:
Please check the answer by Wim Van den Brande below. He has mentioned a very valid point of using Transport Client which has been deprecated over REST API.
So it would be interesting to see how RestTemplate or Spring Data ElasticSearch will update their API to replace TransportClient.
One important remark and caveat with regards to the usage of Spring Data Elasticsearch. Currently, Spring Data Elasticsearch doesn't support the communication by the High Level REST Client API. They are using the transport client. Please note, the TransportClient is deprecated as of Elasticsearch 7.0.0 and is expected to be removed in Elasticsearch 8.0!!!
FYI, this statement has been confirmed already by another post: Elasticsearch Rest Client with Spring Data Elasticsearch

How to integrate Zipkin tracing to thrift microservices

i know this is a very general question but i simply don't know how to start.
I have spring-boot applications which serve a thrift API via HTTP.
The same or another spring-boot app is using the thrift-client of another application to communicate.
my goal is to trace the communication path with zipkin.
i could imagine, i need to somehow intercept incoming and outcoming http-calls with the application-type x-thrift but simply have no idea how to do this and properly integrate with zipkin libraries.
any hint how to start on this is highly appreciated, thanks a lot in advance
i think i found a suitable way to do this. After further thinking my idea went into the direction of using annotations and aspects for intercepting HTTP requests from/to thrifts http client which seems to be quite some work.
after further search, i found this library for spring-boot serving exactly my needs:
https://github.com/aatarasoff/spring-thrift-starter

ElasticSearch HTTP client vs Transport client

What is the best practice using ElasticSearch from Java?
For instance one can easily find documentation and examples for delete-by-query functionality using REST API.
This is not the case for Java Transport Client.
Where can I find usage examples for Java Transport Client ?
Does Java Transport Client cover whole ElasticSearch functionality like HTTP client via REST API?
The best practice of using Elasticsearch from Java: Follow This
Nexts:
You can follow the library : JEST
Yes, in maximum time, Java Transport Client cover whole ElasticSearch functionality like HTTP client via REST API
To complete #sunkuet02 answer:
As mentioned in documentation, the TransportClient is the preferred way if you're using java (performance, serialization, ...).
But the jar is quite heavy (with dependencies) and it requires that you use the same versions between client and server to work.
If you want a very lightweight client, there is a new Java REST client in Elastic 5.x.
I don't know the differences with Jest, but it's compatible with last Elastic 5.x versions (but not with previous versions) and it's developed by the Elastic team.
So it might be a good option to consider, according to your needs.

Resources