Clojurians Log v2

I'm using vanilla Emacs and Leiningen so not exactly sure about Doom and deps.edn specifically, but according to the docs you'd do that by customizing the variable cider-clojure-cli-parameters``, while for me, with Leiningen, it's cider-lein-parameters`` https://docs.cider.mx/cider/basics/up_and_running.html

I got some help over at #emacs as well. I'm now just setting a .dir-locals.el file that sets the cider-clojure-cli-aliases variable to the thing i want. It works!

Or perhaps cider-clojure-cli-aliases now that I read your question again and you seem to be using an alias

Yeah

according to this interaction in #cider you can also pass a prefix argument to jack-in https://clojurians.slack.com/archives/C0617A8PQ/p1568144401230400

i don't think there's anything that's "canonical", as it all depends on the desires of the person writing the wrapper

For example, #cljfx is a wrapper around javafx, but it's got a whole DSL attached, and does a fair amount to smooth over the rough edges of javafx. i wrote https://github.com/NoahTheDuke/fluent-clj/ to wrap java and javascript Project Fluent libraries, and i expose a very minimal api (much less than the originating libraries) because I personally only needed a small surface area

I actually think seancorfield's HoneySQL is a very nice example of 'clojures cultural ergonomics' when compared to your typical ORM/query-builder https://github.com/seancorfield/honeysql

It really depends on what the API being wrapped looks like. For example, a Java API that is heavily reliant on the "builder" pattern is not very nice to use via interop from Clojure really, so when folks wrap those, they often adopt a data-first approach: you give the Clojure wrapper a hash map, and it deals with the repeated calls to builder methods under the hood. org.clojure/java.data is a generic example of that: mapping hash maps (and a class name) to a fully populated Java object and back again.

oh yeah, i forgot about java.data, that's a good one

Sometimes, just generating a Clojure ns full of functions to wrap Java classes and methods is enough to make something more usable, taking care of mapping from plain Clojure vectors and hash maps to Java objects and back. But the generated code is often horrible. Hand-writing such a wrapper can produce better code but is a giant, tedious, PITA. clj-time (deprecated) is a good example of the latter, I'd say. Very thin wrapper.

next.jdbc is also a fairly thin, hand-written wrapper (around JDBC) and it presents a fairly simple, idiomatic Clojure API. So that might be another project to look at. HoneySQL isn't an API wrapper per se, except insofar as it wraps SQL generation so you can avoid string bashing 🙂

What is SQL (the language) if not the API to SQL (the database) 😄

@anthonykfranco Just noticed your edit about invoking the Clojure API from Java -- you won't find much of that. The expectation (in the Java world) is just to use those APIs directly, and any such SDKs tend to expose idiomatic Java APIs. Calling a Clojure API wrapper from Java is likely to be non-idiomatic for Java developers, and also generally requires the Clojure API wrapper to provide an AOT-compiled ns to act as a Java class for Java developers to instantiate and use. In addition, most Clojure libraries are published to Clojars, not Maven Central, so that would also be an extra complexity for Java developers.

Without that AOT-compiled shim, your Java devs would have to follow this https://clojure.org/reference/java_interop#_calling_clojure_from_java which would be even less idiomatic for them, I suspect 🙂

@seancorfield I was thinking more so along the lines of remote HTTP API's, like say if servicedotcom released a public API for a few CRUD-style things, the ergonomics that a Clojurist would expect for a library wrapping it to feel idiomatic. And then regarding Java interop, I mean an example of using the published Clojure library from Java code (so that the Clojure library could end up being the canonical wrapping library for the JVM ecosystem as a whole)

Right, but an idiomatic Clojure API for that service is not going to be idiomatic for Java developers -- and that usage would add a lot of complexity around making it callable from Java and explaining how Java developers should depend on it from Clojars etc etc.

An idiomatic Clojure wrapper is probably going to involve passing and returning Clojure's immutable hash maps, for a start, whereas an idiomatic Java wrapper would likely have dedicated input and output classes, probably with a builder API for the input classes.

Those idiomatic Clojure hash maps would have keywords as keys. Java maps usually have strings as keys. Etc.

I see, so when I said bonus points, I really meant it. The data structures themselves would not feel right in Java

At work, we interact with a lot of remote HTTP APIs. We mostly use Hato (a Clojure wrapper for Java's built-in HTTP client) and very little else, i.e., we tend to use the APIs directly -- because a wrapper is rarely even worthwhile, assuming it accepts and returns JSON. We just use org.clojure/data.json (no dependencies) to encode the parameters and decode the response body. We have a thin, generic wrapper for Hato that handles JSON in/out, just to remove a bit of boilerplate.

I'm working with an HTTP API right now that accepts plain old form POSTs and returns (flat) XML, so I've written a very thin custom wrapper that accepts hash maps (which Hato's form POST handles just fine) and parses the returned XML into a hash map. But even that's pretty generic.

That makes a lot of sense to me. No need to reinvent the wheel if it's simple enough not to. Is there something flat like that for GraphQL?

No idea. I hate GraphQL. We implemented it for one of our own APIs (and our own app as a client) and it was horribly complicated. We'd never use it again.