Play doesn’t care about the persistence layer. Play is one of the most
modular web frameworks. At the same time it is designed to be very easy to
get started with, so the documentation tends to focus on certain setups
(e.g. routes file and guice DI).
One of the reasons Slick’s codebase is so complex is that it was originally
designed to have broader uses, so they have a fine-grained cake, with
JDBC-specific code on top of SQL-specific code on top of
relational-specific code on top of more general code. So the bottom layer
could be reused for e.g. a document-oriented database, and a lot of the
code could be reused for a non-JDBC driver. At least in principle… I
don’t know to what extent the code follows the architecture.
Also it has support for more advanced use cases, like surfacing reads vs.
writes in the type system and support for Reactive Streams.
That said, like any project without a maintainer, the execution is lagging
far behind the vision. It’s too bad Lightbend had to take Stefan off it.
Maybe now that the collections redesign is wrapping up there’s hope of him
returning to it? In any case they really need to put someone on it. It
doesn’t put them in a good light, Slick was a major project of theirs.