The MongoDB Scala driver advertises that it is a "modern idiomatic MongoDB Scala Driver". I would mostly agree, if there wasn't one big issue: The codec resolution is done at runtime via reflection. This is not idiomatic scala and has limitations. We can do that better

One of the biggest drawbacks of the current approach is that the jvm does not provide type information for Generic types at runtime. We can therefore not properly deserialize a List[String] since the information that the List contains String is not available via the reflection api.

Another Issue is that a codec for class that may some how be contained in the class-structure of the elements store in the Database must be explicitly registered. If I for instance have a `case class Foo(a: Either[Bar, Baz])`, I must register a Codec for the case classes Foo, Bar, Baz and the types of any fields of their fields.

The Solution

A more idiomatic scala way to implement codec resolution would be to use implicits instead. This would for instance solve the issue of deserializing Lists, as generic types are available at compile time. There will even no longer be any runtime overhead for the lookup up of codec classes in the CodecRegistries.

To implement that, the Driver should provide a Generic Codec[A] class. When creating for instance an MongoCollection[A], a Codec[A] class would be implicitly resolved. There is no longer a need for manually registering codecs.

For me this is one of the most anoying aspects when working with Mongo on the JVM. While I've currently decided to just no longer use Mongo when writing Software for the JVM, I've written a small/incomplete wrapper around the Mongo java driver in the past. This incomplete wrapper implements Codec resolution at compile time using implicits and can serialize Lists and Map[String, ?] properly. It can even serializes any "case class" or ADT (sealed trait + case class implementations) data structures using shapeless, without defining or registering codecs somewhere. A cust om written Macro as currently used could make this even more performant.

This wrapper (see attachment) is far from beeing an ideal implementation and was never used seriously, but take it as an inspiration of what the future Mongo-Scala-Driver might look like. You may also take at the Couchbase Scala Driver. Their Scala driver and its serialization mechanism feels way more idiomatic!

Could this be a potential candidate for next major release of the Mongo-Scala-Driver?