Skip to content

Latest commit

 

History

History
34 lines (26 loc) · 3.74 KB

Roadmap.md

File metadata and controls

34 lines (26 loc) · 3.74 KB
Raw

Roadmap

Sherlock development has begun to run into growing pains as more advanced features are added. What originally started as a hobby project is quickly being used by multiple people and companies. It is important that feature additions are balanced by robust internal code organization, proper documentation and a full test suite.

0.2 Roadmap

  • First class Facade pattern: Sherlock is currently using a half-baked Facade pattern, but its kludgy and inconsistent (and clutters up the main class). Builder methods will be moved into their own Builder class, accessible by statics for convenience. These will simply be a facade for the underlying component objects. Taking a lot of inspiration from Laravel here

  • Dependency injection makeover: DI is used sporadically in Sherlock, but there is also a lot of hard-coding and just plain weird shit (EventDispatcher usage...I'm looking at you). All of this needs to be refactored into a simple DIC, probably Pimple. This will also make it easier to configure Sherlock, and instead of a gross parameter array you can simply operate on the DIC. Consistent DI is needed to make Sherlock testable.

  • Syntax: generally make the syntax consistent and fluent. Singular/plural methods. Make constructors consistent (e.g. everyone can use array and inline)

General, long-term Roadmap

This is a rough roadmap that Sherlock will follow. No deadlines, but a general overview of what is coming down the pipeline. If you have questions or comments, please send a message to the mailing list.

  • Transport refactoring
    • The transport section of code is a complete mess. The current request/response model works fine for single requests, but batch commands makes the paradigm messy. This is reflected in an external API that is unintuitive and quickly devolves into naming random classes - something I want to avoid in Sherlock
    • The refactoring will rip out much of this internal code and place it under a coherent queuing system so that one or more commands can be specified in a fluent manner.
    • The API will transition from a "index a document" namespace to a generic "document" namespace. A document can be indexed, deleted or Get using the same syntax.
  • Documentation
    • The current documentation is not sufficient. Work is needed to flesh out the entire usage guide. This should be done, however, after the transport refactoring since that will significantly change the indexing API
  • Unit and Integration Test Suite
    • The current tests are basically poor integration tests that simply check for exceptions/errors. The test suite needs to become much more robust to include real unit tests, and more functional integration tests that check response values for accuracy.
  • Test Server
    • Sherlock needs a dedicated test server to run CI, code analysis and performance benchmarks/regression testing. I have most of this infrastructure set up already, it just needs to be tweaked and put into usage.
  • Consistent Code Style
    • Sherlock needs some love in the code-style department. Nothing serious, just a tightening of conventions and formatting style across the whole project.
  • Retire magic methods
    • The heavy reliance on magic methods was a boon at the start of Sherlock, since it allowed me to add the majority of the Elasticsearch query DSL quickly and easily. However, in some internal performance profiling, it is clear that magic methods are upsettingly slow compared to native properties. I want to refactor the majority of Sherlock off magic methods.
    • Luckily, this will not affect the external, developer-facing API. This refactoring can be performed in the background without breaking the API or requiring development to halt in other locations.