Chestnut - Adding Server-side API


#1

I often need a setup with Om Next + a server-side transit middleware with an API. I wonder if this is something that people are interested enough because I’ve been considering extending Chestnut with this setup.

The idea is pretty simple. We could have a middleware with transit support enabled and properly setup and a query and/or mutation sending it over to a server route on, say /api that returns a “hi from server” message. Nothing too fancy.

Is there any interest to add this kind of feature for Chestnut? I would be glad to take it on.


#2

Hi Luchini,

Welcome to Chestnut! Thanks a lot for wanting to contribute!

I think having an example of how to do client-server communication would be useful and great to have. The main reason it’s not there is that there’s no real consensus in the Clojure world of how to do it. REST? Something with event sourcing? Replikativ? Datalog? That said I think Transit as a format and a traditional REST-ish API are still good defaults to start from. I’m not sure if it should be behind a feature flag or not, but I’m leaning towards putting it behind a flag. Maybe +api or +ajax?

Do you have an example project that people can look at? If not I would suggest to start there, generate a Chestnut app and start making the changes you want to bring in. That’s easier than immediately trying to weave it into the template, it gives you an opportunity to experiment with the approach you want to take, and it’s also an easier way for people to look at it and give feedback. In the end you take a diff and you see exactly what to add to Chestnut.

Which middleware and which ajax lib were you thinking of using? I personally have good experience with ring-middleware-format and cljs-ajax. I like ring-middleware-format because it does HTTP content negotiation, so it’ll serve transit if a client asks for it, or JSON or something else. cljs-ajax also defaults to transit so that tends to work out of the box.


#3

I particularly like ring-middleware-format myself as well.

The setup I’ve seen recurringly over here is a Transit layer passing the datalog-like queries from Om:next to the server. Of course, this might be skewed due to our usage of Om:next.


#4

Interesting! From my anecdotal experience people see Om.next more as a testing ground for interesting ideas than as something to build real world applications with :slight_smile:

Or maybe I’m just projecting my own ideas there. I definitely see/hear more about use of Reagent here, with either re-frame or something similar (precept, re-posh).


#5