Why use NEST client in C# and not directly query elastic search server through elastic search JSON query?

前端 未结 2 1156
感情败类
感情败类 2021-01-25 22:56

We always create elastic search query in sense and then create corresponding version of it in NEST.

What is benefit of using NEST client and not directly putting JSON e

相关标签:
2条回答
  • 2021-01-25 23:33

    There are 2 major reasons to use a strongly typed library like NEST.

    1. It protects you from attempting most invalid requests

    The DSL can feel cumbersome at first, but once you get used to it you realize that it's strict structure prevents you from chaining filters and aggregations together in an invalid way. This means that errors can be caught when you're writing the code, and ready to fix it...and not later in production.

    #2 Give IDEs like Visual Studio and Code everything they need for code completion

    Just like Kibana helps you writing Elasticsearch queries in the dev tools, your IDE can provide syntax highlighting and code completion that can save you time running back and forth to the docs or Kibana. This is really useful when you are dynamically constructing queries.

    Source: I wrote a blog about this recently, on the benefits of using a strongly-typed library like NEST for generating Elasticsearch queries

    0 讨论(0)
  • 2021-01-25 23:34

    Here's a non-exhaustive list of reasons why you might choose to use NEST, the high level client for Elasticsearch:

    • Supported and tested with .NET 4.5, .NET 4.6 and .NET Standard 1.3 (and above)
    • All requests and responses modelled as types
    • Allows documents to be modelled as Plain Old CLR Objects (POCOs)
    • All Elasticsearch APIs mapped
    • Powerful fluent API using lambda expressions makes building queries much easier. Includes features such as conditionless queries.
    • An object initializer API if you prefer to compose objects together, rather than use the fluent API
    • Exposes the low level client if you need to perform requests with strings, byte arrays, anonymous types. Allows mixing and matching request/response types with more primitive types
    • Automatic failover and retry semantics
    • Intrinsic knowledge of valid responses for endpoints e.g. a 404 response for a document not found may still be considered a valid response
    • Observable helper methods for longer running operations e.g. BulkAll, ScrollAll, Reindex
    • Maintained by Elastic as an official client, with great contributions from the community (thank you!). Includes documentation that is built from source code to mitigate drift from source, and make it easier to constantly improve
    • Pluggable components e.g. IConnection, IRequestPipeline, IElasticsearchSerializer, etc.
    0 讨论(0)
提交回复
热议问题