Orchestrate is closing doors. I used it as the store for mysnippets service. The service had a decent data access abstraction, it tests with maps, it was originally implemented with an RDBMS, and then Orchestrate so swapping in another store wasn’t a big deal. Looking around, MongoDB seemed a good choice. My snippets service runs in the cloud and operates inservices free tiers. So looking around for a free tier of MongoDB I found two likely choices, using OpenShifts MongoDB support, or mlabs dev sandbox. I went with mlab. The port was simple and performance seems good.
Keeping PersistenceImplementation IndependentImplementing basic CRUD operations in an implementation independent way is generally pretty simple. The toughest part of moving from one implementation to the next is supporting the change ofquery language. Query languages tend to be very semantically different. One tactic that eases transitions is implementing your queries over the in memory data structure, which works for any store, and then implementing store specific queries as an optimization. You can honor the API contracts by working in memory and get the app working. The down side is that to perform searches you need everything in memory and loading the whole store into memory isn’t efficient. Implementing the queries with the stores native mechanism will get you a big bump in performance.
If you abstract your queries to a generalized query description, and then convert that description to different store specific implementations you can keep a consistent API (i.e. your query structure) and handle a myriad of implementations. Make sure one of the concrete implementations is something like Java Predicates allowing you to search the data in memory, that allows you to test your queries, and supports migrating the store.