Related reading
FACETED SEARCH FOR EDS
Search for Adobe Edge Delivery Services that works on day one and is built to grow
Start from a ready-to-use connector and search blocks. Extend the schema, facets, and frontend as your implementation grows.
FACETED SEARCH FOR EDS
Start from a ready-to-use connector and search blocks. Extend the schema, facets, and frontend as your implementation grows.
THE PROBLEM
AEM EDS was built to make modern websites easier to build and fast to deliver. But it doesn't come with search, so every project has to choose something to build it on and connect it back to the site. Search ends up off the edge, on its own path, updated on its own schedule: a fast site with a search layer that behaves like a separate system, because it is one.
AEM EDS makes content live in moments. The search index updates on its own cycle, often a crawl that runs later. Between the two sits a gap where the page is live but not findable.
Facets and filters depend on accuracy, not timing. A scheduled crawl only sees whatever metatags happen to be there when it runs, with no fixed way of reading them from one pass to the next. Facets built this way are only as reliable as whatever the last crawl happened to interpret correctly.
Your content is served from the edge. Search usually runs somewhere central, and "distributed" often just means replicated copies that sync one location at a time. So every request leaves the edge to go get an answer, and some locations answer with older data than others.
There is no out-of-the-box connector, so the team builds one. Then indexing jobs, then delete and unpublish handling, then retries and monitoring, then the frontend integration. Each piece is reasonable on its own. Together they are a custom search backend that someone owns for the life of the site.
THE SOLUTION
StreamX does not wait for a crawl cycle to notice a page changed. When content publishes through AEM EDS, that event tells StreamX exactly which resource changed and when. StreamX fetches that page, parses it against a defined structure, and updates the search index right away. Facets come from the metadata already rendered into the page: category, region, content type. The difference isn’t where StreamX reads from. It’s that StreamX knows the moment something changes instead of finding out on the next pass.
Publishing and indexing run on the same flow. New and updated content shows up in results without waiting for the next crawl, so live and findable stop being two different states.
Filters are built from the metatags already in your content, parsed the moment StreamX reads the page on publish. Category, region, type, and date stay accurate because they update every time the content does, not on a separate schedule. That accuracy still depends on the structure you define, StreamX keeps it current, it doesn't invent it.
When content publishes through EDS, StreamX knows exactly which resource changed. It fetches that page, parses it against a defined structure, and updates the search index right away. Facets come from the metadata already in the page: category, region, content type.
StreamX includes a production-ready connector for AEM EDS, It automatically picks up published content and feeds it into StreamX’s continuous materialization pipeline, which continuously updates search as content changes. Instead of building and maintaining your own integration, you configure what is already there.
Start with a production-ready AEM EDS connector, a search reference to build from, and an architecture designed to fit Edge Delivery Services. Configure what's already there instead of building it from scratch, and get continuously updated, accurate results from day one.
Configuration not construction
With a custom EDS search implementation, your team is responsible for every layer between published content and the search experience. StreamX provides that foundation so you can focus on the customer experience instead of the underlying infrastructure.
|
Responsibility |
With StreamX |
Build it yourself |
|||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
Connector |
Custom-built, maintained |
Production-ready, |
|||||||||
|
Indexing pipeline |
Written and tested |
Included, triggered |
|||||||||
|
Facet extraction |
Manual mapping logic |
Pulled from metadata |
|||||||||
|
Lifecycle handling |
Update/delete/unpublish |
Scoped per implementation, |
|||||||||
|
Frontend |
Built from zero |
Reference component |
|||||||||
|
Monitoring |
Another system to own |
Part of the platform |
Here are answers to some of the most common questions about how StreamX search works with AEM Edge Delivery Services.
StreamX connects directly to Edge Delivery Services publishing. When content changes, the StreamX connector receives the event, extracts and transforms the relevant content and metadata, and updates the affected search documents. There's no separate crawler or indexing job to build and maintain.
As soon as content changes, StreamX processes the publishing event and updates the affected search documents. The result is a much smaller gap between content being published and users being able to find it in search.
Updates, deletes, and unpublishes are all handled as part of the same event-driven publishing flow. When content changes, the corresponding search documents are added, updated, or removed so the index stays synchronized with published content.
Metadata is extracted from your published content as it's processed by StreamX. You can configure searchable fields, facetable fields, schemas, and field mappings to match your content model and search experience.
Yes. StreamX can connect Edge Delivery Services alongside supported enterprise data sources, allowing search experiences to combine content from multiple systems through the same processing pipeline.
StreamX separates content processing from search delivery. Search indexes and lightweight search services can be deployed in the regions where users are located, helping keep search both fresh and responsive.
Looking for more detail?
Tad Reeves
Principal AEM Architect,
Arbory Digital
"Even with a move to AEM Edge Delivery (Helix), one is still faced with the problem of how to architect around the availability and performance of backend systems that you now have to stitch together at the CLIENT side.
That’s where StreamX (...) can be used as a potential for dramatically increasing speed and reliability for complicated web/mobile experiences."
From article in Arbory Digital Blog
Ready to see what StreamX can do for you?