Fork me on GitHub
Jeff Evans17:11:22

Is there anything in the Clojure ecosystem approaching an auto-generated admin web interface, à la Django or JHipster?


I've used retool and react-admin via a REST interface for this sort of thing.


this was the primary feature of the defunct Caribou project (what I worked on at my first ever Clojure job ages ago...)


it's very old, and not under active development

Jeff Evans19:11:47

yeah, might still be interesting to peruse and see the approach taken, as compared to the aforementioned frameworks


the general idea was defining the content of the site via database, then using DB CRUD to control what's displayed


use case was the end user has content admins who could be trained to use the admin UI, with the power to create new assets paths and layouts via DB upload without dev work

Jeff Evans19:11:48

yeah, that sounds quite similar to what Django was originally envisioned to do, actually


the original sponsors ended up switching to squarespace


yeah, django was definitely an inspiration

Jeff Evans19:11:34

I have no clue how many deployments kept the auto admin interface, though, versus rolling their own


@U0183EZCD0D one example of an idea from that project that could be imported elsewhere: using a db data model for paths, and then consuming that in the back end to create a router


For read-only tasks you could use Metabase, I'm not aware of any solutions providing R/W access.


Does anyone have a source for "don't write wrapper libraries that are thin wrappers around Java unless you're adding value", I want to use some appeal to authority :)


I think I remember @U0NCTKEV8 saying something like that a few times.


Similar quote

Because the Java invocation syntax in Clojure is clean and simple, it's
idiomatic to use Java directly, rather than to hide Java behind Lispy wrappers.
in Programming Clojure


another one

Clojure embraces Java and its libraries. Idiomatic Clojure code calls Java
libraries directly and doesn't try to wrap everything under the sun to look
like Lisp. This surprises many new Clojure developers but is very pragmatic.
Where Java isn't broken, Clojure doesn't fix it.


personal experience: it's like a framework, it works perfectly until you leave the original author's happy path, then you need to fork it because they misunderstood or incompletely covered the underlying API


doing interop in the first place is less work than maintaining a fork of a thin wrapper


also the wrapper adds layers / complexity


Wonderful, thanks :)


it totally depends. wrappers can give idiomatic access while leaving the Java world open for extension


right - ring for example


@U051SS2EU Exactly right. Even just minor things like spending 30 minutes wondering why a property that's clearly in the libs docs isn't being applied until you reason the wrapper is shit and only passes along the 3 keys that the original author cared about. /tableflip.


but I haven't seen this for thin wrappers


Ring is not a thing wrapper - it's a unique abstraction :)


@U09LZR36F What wrapper is this about?


@U04V15CAJ just some react component that's pretty thin when used from Helix anyway.


ok. what I had in mind, e.g. babashka.process: it's a convenient way of creating processes from Clojure while still having access to the raw underlying java stuff

👍 3

That's not thin. It's a little bit of an abstraction. Like a cracker, but not quite a biscuit.


I like wrapper libraries. I have written many which I would characterize as thin but add a modicum of value. There are many situations where Java libraries have unwieldy class structure and wrapping eases the pain.


I really don't like when engineers create context-free edicts for all to follow. We don't need that much religion.


This is a good point and puts the quotes into context. Obviously if your wrapper provides some tangible benefits outside of just hiding Java interop, then it adds value. The point of the quotes are rather: Java interop by itself is both idiomatic and ergonomic and doesn’t require wrapper per se.


I agree, I have moved away from clj-time, but more importantly java-time , for example, and prefer java.time access via interop.


This is a very informative discussion! It particularly reminded me of a recent case where I recommended not returning AWS data *Response Java objects from functions, but rather converting them to Clojure maps. Does the maxim discussed here suggest that that was wrong? In other words, does the interop argument extend to directly working with Java data structures (in object hierarchies), rather than wrapping them in a thin Clojure data translation layer? How about when all the operations and data involved are limited to a single namespace?


the watershed line is if the wrapper is an external dependecy


bringing in an external dependency that doesn't justify itself is bad, and wrapping is no justification


for internal stuff the question is a lot less clear cut

👍 3
Asko Nõmm20:11:02

Does anyone have any experience with jdbc / mysql here? Namely I have an issue where after some time of inactivity, and then again trying to connect to the database .. it fails with a Operation timed out (Read failed) . I’ve been trying to find a way to configure it to reconnect on timeout, but haven’t yet found a way. Does anyone have any ideas?


#sql is your best bet as a channel for that Q @asko

Asko Nõmm20:11:16

Ah, didn’t know of it! Thank you for pointing me in a direction :)