...
The public client is read-only and could do all its interactions with elasticsearch. A small amount of work is needed to add more information to ES to enable this. Most interactions are already with ES. There are a few - mostly those related to accounts and calendar suites which still touch the database. The back end needs refactoring into a db + ES version and ES only. Benefits are a much more lightweight client with faster responses and less load on the database.
Limit interactions with db for updates.
Do For this we would do all interactions with ES - and connect to and update db only as needed - use timestamps . Use sequence numbers to ensure db and index correctness. Benefits are shorter db interactions - only at point we update. Less complexity in web clients - no need to have conversations stretching across multiple requests. This can build on the work of the previous item. The web client code is already structured ro assume that it will do an explicit update of entities which shoudl facilitate the change.
Move business logic out of webapps into core
...
Searches of other entities such as locations. Search for events near a geo-location (requires locations to have geo)
Caching
Implement caching of feeder data as a built in feature of the quickstart.
Deployment
Finish off the deployment process - it's THAT close (is there an emoticon for 2 fingers very close together?) to allowing deployers to just replace the ears from prebuilt ears on the site. No builds required - server can detect an update is available.
...