I did a clone of HN in Clojure 10 years ago (wow, time flies), but it just wrote the state out to files: https://github.com/cubix/simplenews

No ClojureScript then, of course. I was planning something more sophisticated for persistence, but never got around to it.

Neat, could you provide some annotations or a readme? I'm curious to see how you made this. Only if you have some extra time laying around of course

I might have some time to dust it off tonight.

Cool! I'm currently working through the lacinia tutorial to learn GraphQL (I've invested a lot of time in getting good at designing RESTful APIs, so GraphQL definitely feels alien to me), making a few changes as I go (I prefer mount to component, for example).

And what are you discovering about GraphQL? What have you lost and gained in translation?

Nice job!

On the whole the howtographql series is instructive but results in a ton of boilerplate code. The GraphQL framework[1] 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.

[1]: https://github.com/manifold-systems/manifold/tree/master/man...

No relation to Clojure's own manifold library, I guess? I was a bit confused when I visited that github repo you posted and saw a bunch of Java code :P

This is the one I thought of: https://github.com/ztellman/manifold

Ah, no relation, but interesting library!

Interesting. I have wanted to get into GraphQL. As Clojure person I liked the idea but we had some similar stuff already.

I will defiantly look at that code later.

In Clojure we have walkable which can handle graphql and EQL, personally I found holes in the graphql type system that EQL wouldn't have had a problem with @see: Fulcro EQL walkable

I like the idea of EQL, but I'm not sure I want to tie myself to Fulcro. Looking forward to more projects adopting EQL.

GraphQL definitely has a number of issues (type explosion being one) that can be avoided with EQL.

EQL as a pull syntax for Crux is definitely interesting (and we're considering building something more official): https://github.com/souenzzo/graph-demo

Been looking for a fun way to learn Clojure. Thanks!

I've been looking for a motivated tutorial to learn Clojure beyond the syntax and similar basics, thanks for sharing!

thats a lot of code

Clickable links:

https://promesante.github.io/2019/08/14/clojure_graphql_full...

https://github.com/promesante/hn-clj-pedestal-re-frame

Thanks! We've clickied the main ones.

Most people new to languages with Lisp syntax find it difficult to read at first. At some point, it becomes natural to read and write it that way. More importantly, it becomes obvious how useful having a consistent and extensible syntax is to writing all sorts of things.

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.

Imperative code is structured with ; that terminate statements. var foo = 42;

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

> 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

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.