Bodybuilder v3.0

Given our recent discussions in #281 I had a bit of an itch in my fingers to try if a new and simpler API to bodybuilder could be created given everything we’ve learnt over the years and https://github.com/johannes-scharlach/elasticbuilder is my approach to that. It already passes most of the test cases which have been written for this repository, which seems like a big step to prove that it indeed is possible to provide the same functionality with what is hopefully a smaller interface.

@danpaz @ferronrsmith (and if you’re interested also @quinnlangille) I’m looking forward to your feedback to see if we can/should turn that into v3 of bodybuilder. It might not be trivial to find a migration path, since it would be a complete rewrite of the library.

Example usage:

    const bb = new BodyBuilder();
    bb.query
      .must('match', 'message', 'this is a test')
      .filter('term', 'user', 'kimchy')
      .filter('term', 'user', 'herald')
      .should('term', 'user', 'johnny')
      .mustNot('term', 'user', 'cassie');
    bb.aggs
      .add('agg_terms_user', 'terms', 'user')
      .add(
        'agg_diversified_sampler_user.id',
        'diversified_sampler',
        {
          field: 'user.id',
          shard_size: 200,
        },
        new AggregationBuilder({
          keywords: {
            significant_terms: {
              field: 'text',
            },
          },
        })
      );
    const result = bb.build();

which brings up a couple of new questions:

1. Now the user will be aware of concepts like the query builder and the aggregation builder
2. given that those builders exist, it is no longer possible to do a single chaining which combines them – a real shame. Should we duplicate that interface on bodybuilder and muddle the responsibilities again?
3. the real difference in API can be seen in passing in new AggregationBuilder and these nested queries being evaluated lazily when you call build(). This would have helped me in the past, but is it worth it to expose those new concepts?

I’m happy to continue the work in this repo if you’re interested in v3 or I might even go in the direction of generalising the builder interface description as @ferronrsmith suggested to also construct other queries (e.g. mongodb).

[johannes-scharlach]

@danpaz I’d really appreciate your feedback here, too

[quinnlangille]

I like this! Moving to a more simplified api would allow for some good typing upgrades, and an overall boost to developer experience. I agree with @ferronrsmith in that we probably want to keep the single chaining. Regarding point 3, I think exposing the builder classes could be cool. For example, in a past version of our ES setup we would pass around a single instance of BB to many methods before sending it to ES:

class ProductAggBuilder {
    buildAgg(bb: BodyBuilder) {
          return bb.agg(...)
    }
)

This got a bit cumbersome with different business logic, and ended up being tough to follow. With the exposed classes, we could have written the above method like:

class ProductAggBuilder {
    buildAgg() {
          return new AggregationBuilder(...)
    }
)

I’m not sure if that’s how others use BB, but having the exposed builders as an option would let devs write code that is easier to read and test, IMO.

Our usage has since changed, but we still rely on BB for all our ES stuff at the office. I know we have done a lot of wrapping/hacking to get around some things, so I can check with some of the devs for any feedback/input they have and get back to you!