We should’ve started a thread way back there. Yeah for me it’s really a bunch of synergistic things. There are individual things I like about other options, but when I add them all up, Clojure wins big time. And really, one of the big things is being able to leverage Java and JS things too.

Same language front and back ends

For sure. Do you have any experience with Datomic Cloud and Ions?

Simplicity, design ethos, immutable data, data-oriented, rich extensible data format (this is big for me)

Are they worth looking into?

I don’t have any experience. I think they’re worth looking into

What’s your project? Any required tech stack?

Hm. Alright.

It will likely be on AWS. It will be a video hosting service, so UI and transcoding pipelines for that

My project is for non-profits and I’ll move to Cloud when/if it’s making enough money to justify. In the mean time it’ll run on a little DigitalOcean droplet

Ah sounds big

Yeah, has the potential

I’m liking serverless architectures as well

Do you plan on using a lot of JS NPM for the UI?

Hence the AWS focus

I’m not sure but I’d like access. I know there’s shadow-CLJS

I haven’t done a side-by-side comparison, but I’m pretty sure using webpack you can get a smaller JS executable

You can do a double build with webpack and CLJS but then you have more issues with externs.

Hmm

I just use shadow-cljs and it handles NPM stuff, but I’m pretty sure it doesn’t get as small because it doesn’t do tree-shaking of the NPM stuff

Right, as far as I know, there is no tree shaking except for the closure libs and the app code

but that’s something to ask on #shadow-cljs

So you were able to go from Datomic database to Panthom backend in one day?

yeah, that said, doing SSR with loadable modules and sending over a pre-rendered page with a small JS file and data is totally doable. I’ve rolled this custom myself in the past.

Did you need to write the Pathom resolvers manually? Or is there an automated alternative?

Yes, I set up 2 pathom resolvers, one for idents, and one for general table lookups for ~30 tables that I migrated from MySQL to Datomic. I use my own spec file to describe all of the tables and columns (entities and attributes in Datomic parlance)

automated?

spec = clojure.spec?

I guess integrated would be a better word

spec == my own custom specification

I’m thinking of something like generated GraphQL resolvers with something like AppSync or Hasura

https://github.com/thosmos/riverdb/blob/master/resources/specs.edn

Oh! Does this repo have an example of the resolvers you mentioned?

Here are my resolvers: https://github.com/thosmos/riverdb/blob/master/src/server/riverdb/api/resolvers.clj

Thanks! This will be nice to reference

A client project or your own?

yeah it handles paging, filters, sort, etc

Yes, this is my current project

Nice

Thanks for sharing

my pleasure

glad to be working on something I can share. Much of my work over the years has been closed source

There’s a lot of hackery in there (learning by doing)

Yeah. I understand

Nice to have an open source project or two

I just pushed my latest changes. I will probably change the lookup-resolver to build on the map-form of Datomic query. instead of the vector form. I’m surprised it’s worked so far, but can be a little hard to parse what’s going on.

I also use this little library i made to convert the specs into various things like Datomic schema, datascript schema, etc: https://github.com/thosmos/domain-spec

The idea of having just two resolvers for pretty good base API from Datomic, Pathom, and Fulcro seems like something worth sharing

Do you a github gist or blog post about it?

I will … there’s a lot I’m doing in the app that I think is innovative 😉 hehe and yes planning to write about it

Cool

Do you have a place you post so I can look out for it?

https://code.thosmos.com my latest post describes some of the design goals

Thanks

oops, not latest, this one: https://code.thosmos.com/posts/2019-12-04-spec-driven-ui.html

that was written before I made the leap from react + JS + graphql <-> lacinia + datomic to Fulcro + Pathom + EQL <-> datomic. I’m so much happier now!

Less work / code I presume?

yes I think so, even though I’ve built my own replacements for some of what react-admin provided

I think the crux of my decision is based on my design goal of using my domain specs to generate as much as possible. so now I have one list component that can be used for all the different tables, one dropdown lookup for references to joined entities, etc

Certainly sounds powerful for what you’re doing

Yeah it makes doing a bunch of similar CRUD stuff so much more realizable in a relatively short time. The universal list is in this file: https://github.com/thosmos/riverdb/blob/master/src/main/riverdb/ui/theta.cljs