Reflections on ElasticPress
Taylor LovettWith 2015 coming to a close, I’ve been reflecting on the ElasticPress project’s accomplishments since its inception one and a half years ago.
Today, we released ElasticPress 1.7, which completely restructures post meta storage. This enables performant post meta queries with complex comparisons against data types, such as integers, dates, and times. We also fixed some bugs.
Like many of our popular open source projects, ElasticPress was originally conceived as an internal tool designed to support some specific client needs. Since open sourcing the project, ElasticPress has garnered over 30 contributors (most of whom do not work at 10up), 16 major releases, and a thriving Github community where developers and site owners are collaborating. ElasticPress is used by major hosting companies and across hundreds of websites, some of which serve millions of pages each month. I have introduced developers to ElasticPress at speaking engagements around the world.
We’ve also learned our fair share of lessons since initiating the project. Here are a few that stand out.
1. Building software that relies heavily on evolving external dependencies is challenging, even if those dependencies are open source.
Elasticsearch is wonderful software maintained primarily by Elastic. The project is still young and has undergone significant changes as it became more popular. In the process of rapidly interacting, Elastic has pushed out some amazing features that have sometimes sacrificed backwards compatibility. We have to respond quickly and effectively to take into account breaking changes, while also ensuring backwards compatible for ElasticPress adopters who may not (yet) upgrade Elasticsearch itself. If you choose to develop on top of Elasticsearch, be aware that backwards compatibility is not a top priority; that can be especially surprising for those spoiled by WordPress’s firm commitment to non-breaking changes.
2. Integration tests are absolutely critical to the success of large software projects.
The ElasticPress test suite is 4587 lines of code, which is about 50% of the PHP code in the project. Using CI tools, we test our changes in:
- Every release of WordPress going back to 3.8
- PHP 5.2 through 7.0
- Elasticsearch 1.7 and 2.0
Because ElasticPress integrates deeply with WP_Query, it is very susceptible to even modest changes in WordPress itself. We make sure ElasticPress releases are stable using our automated test suite as well as more traditional quality assurance testing and review processes. We urge all contributors (10up’er or otherwise) to create tests for all enhancements and bugs.
3. Deploying Elasticsearch at scale has a learning curve.
At 10up, we’ve learned how to effectively operate and scale an Elasticsearch cluster for enterprise level performance and reliability… and we have the scars to prove it! I highly recommend working with an experienced partner if you’re considering hosting Elasticsearch.
4. Search is a very site-specific experience. There is no perfect, one-size-fits-all algorithm.
The more we engage businesses and developers adopting ElasticPress, the better we understand that different use cases need different search algorithms. For instance, the right degree of fuzzy matching and date weighting vary tremendously between applications. To get the most out of Elasticsearch and ElasticPress, you need to customize the search algorithm to fit your needs.
If you have any questions about the project or 10up’s Elasticsearch offerings, get in touch with our team or shoot me an email directly.