@ben606 an ORM is a step in the middle that may or may not help you to achieve your ultimate goal. For me the goal is mostly the api endpoint, and an ORM offers more annoyance than help when it stands between the api endpoint and the database

there's a Clojure library for making APIs from sql database directly: http://walkable.gitlab.io

it makes use of EQL, an Clojure native version of Graphql - but you can add a RESTful or Graphql layer on top of it very quickly

Walkable is mentioned in Luminus doc but it may look mysterious without the context above

I think there's also the fundamental issue that ORMs are a "workaround" for the disconnect between the Object model and the Relational model -- they're fundamentally different and there really does need to be a "mapping" between them in the OOP world. In the FP world we deal with pure data a lot more and we don't conflate/complect a lot of the things that OOP does, so ORMs really don't make sense in the FP world.

I've dealt with ORMs in various forms over the decades (and full-on Object Databases too, back in the day, anyone remember POET etc?) and they're all a giant pain in the @$$ because they're all deliberately papering over a semantic mismatch. I've even given conference talks about this (yeah, it's that much of a hot button! 🙂 )...

Read this https://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/ (and Ted Neward's original article and his follow-up). Just don't get me started on ORMs...

In my current (java) team there is also a resistance to ORM. We are moving to using PostgreSQL more instead of MongoDB, and getting data out with custom queries.

I was initially quite enamored with MongoDB seeing it as a way out of the OOP/ORM minefield but the more time I spent with it, the less I liked it.

We had a pretty sizeable MongoDB setup for a while, but we eventually either migrated all the data back into Percona/MySQL or threw it away.

Saved us a bunch of money to stop using MongoDB as well as MySQL 🙂

We were kind of forced to use MongoDB because of a company shared library. They ran into performance problems for some analytics which introduces PostgreSQL to the project. Now we move more to PostgreSQL its getting confusing. But discussing if we really need the shared library and/or if we not better ditch MongoDB, or maybe keep it just for 'real' documents.

A "real" document is just a JSON blob to be stored in a large text field 🙂

or better, json(b) on postgres/mysql 🙂

So we are using Mongo at work now (unfortunately). On one hand, it’s annoying and badly designed. On the other hand, the fact that we use no ORM and have to hand-craft our queries and pipelines, makes me not want to go to writing pure SQL statements by hand again. But I haven’t really done hand-written SQL in a very long time now, so perhaps I overplay the hand-written SQL a bit?

For a long while we had a dedicated DBA so "raw" SQL was good because they could write it for us, if needed, or review what we had written. Where we build queries dynamically, we use HoneySQL, which is better than bashing strings together. Overall, SQL is good at what SQL is designed for -- and I think developers who work with RDBMS should know SQL.