I have been seriously confused at times, too. Most often when trying to do weird things to build helper libraries. I’ve heard several things about why the driver is the way it is, but to try to repeat that would be all hearsay… I won’t. I recall it gave me some reassurances at the time, though. I do hope that this topic can shed some light again.
I also want to say, I think stating that “everyone” will have DX issues is a stretch. Personally, I do not understand why any intermediate API (e.g. serverless function on Netlify/Vercel) would have to worry about serializing/deserializing – there are many a Fauna App that just query for data, use it, modify it, and update the DB in a straight forward way with the js driver. You can also store responses and pass them right back into new queries. The classes for sure obfuscate the underlying data structure, but the getters/setters make sure (most) code can just consume it like plain ol’ JSON.
I guess what I am saying is that I am super interested in knowing why it is why it is, and also why it isn’t just plain old JSON. For me, though, it is an academic exercise: the nature of the class-based query results have no impact on my code (just that once when I tried to be too clever).
Final thing: I really love the work you are doing with
typed-functional-fauna. It introduced me to
io-ts and re-excited about
fp-ts. Inspired by your work, I implemented codecs that check class prototype, and I still get very useful results from validating query responses.
faunadb-io-types. There of course holes in my implementation, for example I am trying to validate Ref Ids to such an extent, which I understand now to be a big problem for you.