Source code GitHub repo:
Suggestions and corrections, more than welcome.
No ClojureScript then, of course. I was planning something more sophisticated for persistence, but never got around to it.
On the whole the howtographql series is instructive but results in a ton of boilerplate code. The GraphQL framework from the Manifold project avoids all of that with the "manifold" concept, which is similar to F#'s type providers.
Currently manifold targets Java exclusively, but the framework is designed to support other JVM languages. Perhaps clojure could be on the radar? Food for thought.
This is the one I thought of: https://github.com/ztellman/manifold
I will defiantly look at that code later.
GraphQL definitely has a number of issues (type explosion being one) that can be avoided with EQL.
But the actual clojure code looks weird? I get that its a different way of writing from the C like syntax, just that fro a quick glance it doesn't look very pleasant to read due to the how messy the brackets everywhere nature is.
I also feel like reasoning about CRUD problems is easier in a non functional way, but again no real experience with functional languages to say for sure.
EDIT: To illustrate with an example:
In C# I can write LINQ using the lambda syntax for queries, however sometimes its useful to be able to break down complex queries into parts, step through with a debugger to follow the logic, don't see how the functional style of Lisp aids in doing any of that (at least not when writing it idiomatically).
Eventually the C-style syntax feels “messy” because the symbols are used less consistently. At the same time, Lisps like Dylan transitioned to a more conventional syntax and can still maintain lots of the power that they got with S-expressions.
Functional code is structured with () that composes function calls. foo(bar(42))
All else equal, composition has more interesting structure, which is very helpful for reasoning e.g. flow and dependency graph
In Clojure normally rather than a step debugger one would use an editor with REPL integration to aid in exploring and developing program behavior. E.g. you may capture inputs to the function, and then quickly and iteratively decompose the function and evaluate the building blocks. This type of workflow is often called REPL-driven development.