I've been working on a data model that turns out a bit more tricky than I would've liked. The project I'm working on wants to return collections of products, let's say type of cars, and each type has several configurations. For example, car type SUV, with a red V8 configuration, a blue Hybrid and a full electric silver one. Then you have a sports car, with similar car configurations, but still unique to the family. We would like to browse, filter and/or sort on Car Type, and on car configuration attributes itself, depending how deep you're into the user journey.
Nested objects would be ideal for this. Unfortunately App Search doesn't support this, as per JasonStoltz' reply: Nested field in app search.
One of the questions would be: is this ever going to be on the roadmap for App Search to support?
I've considered all options Jason already helpfully outlined in his reply, and we opted for a seperated Car Type and Car Index. While my example is simple, the real situation is far more complex, and I fear that pushing and pulling from seperate indexes would create a huge overhead on the front end team to litterally make ends meet. It may also be likely we end up creating even more indexes. Am I overthinking things here, and perhaps missing a feature within App Search that either makes it easier or allows for a circumenvented nested object?
The Project lead opted for App Search as this allows the marketeers to easily influence search rankings through the GUI per engine, though, when I really look at the requirements, they in the end will eventually run into the same issues I am (in context to all solutions provided by Jason): wanting to influence multi-level boosting, cars in relation to car type, filter on multiple levels, etc. However, they don't want to lose out on the simplified GUI of App Search when they'd be opting for full-pull ElasticStack.