This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # bangalore-clj (1)
- # beginners (28)
- # boot (33)
- # chestnut (3)
- # cider (35)
- # cljs-dev (64)
- # cljsrn (16)
- # clojure (95)
- # clojure-android (6)
- # clojure-austin (1)
- # clojure-italy (5)
- # clojure-korea (1)
- # clojure-russia (55)
- # clojure-sg (1)
- # clojure-spec (25)
- # clojure-uk (57)
- # clojurescript (120)
- # code-reviews (7)
- # community-development (2)
- # core-async (3)
- # cursive (6)
- # data-science (3)
- # datascript (10)
- # datomic (12)
- # devcards (1)
- # emacs (9)
- # gsoc (7)
- # hoplon (18)
- # lumo (2)
- # off-topic (10)
- # om (24)
- # onyx (17)
- # pedestal (46)
- # powderkeg (1)
- # protorepl (7)
- # re-frame (31)
- # ring-swagger (34)
- # spacemacs (10)
- # specter (9)
- # sql (39)
- # unrepl (9)
- # untangled (3)
- # utah-clojurians (1)
@souenzzo I struggled a lot to get working route reload in repl also... In the end (after I realized I needed to deref the var) it was when someone here helped me figure out that cider-refresh doesn't work well with pedestal and I started to use cider-load-buffer instead.
@sineer Oh, that’s interesting! I never ran into that because I just habitually use cider-load-buffer.
Are there any libraries available that help define routes and documentation, parameter validation and docstrings, etc, but with these features: a) expressing all that goop as pure data, b) sharing it with CLJS for interactive docs, c) using pedestal to generate / process interceptors that do most of the heavy lifting
Because I'm about to write one … I want to write a single piece of data that describes my route, then some code that implements the logic, then walk away and be done
1. A library to describe routes as data. This exists in the form of Vase. We just need to think about how to surface the specs about request bodies.
2. The ability for Pedestal routes to have extra data that Pedestal doesn't care about, but carries along.
I'm currently at this point where I use the content-type detection and either serve up json, or serve up a full blown CLJS SPA that lets you explore the whole data structure. It also includes individual timings of each pedestal interceptor so I can locate problems.
So I started falling pretty hard for this idea of the self describing API, or the self reporting application, and wondered how close I could get to having this all spun off for free
so the CLJS thing I wrote is cool (and my first CLJS project) in that I've just implemented a bunch of multi methods to handle different key types that come across the wire. So it's the same page for every single route, and as long as each route coughs up the right shape of data, you get a free web viz out of it
(and I cheat and just stuff the data into a transit json encoded body attribute, no websocket here 😬)
If you were going to express your routes, docs, & validation as data, what would it look like? Have you tried writing a spec or example for it?
I've spec'd the parameters one of my routes accepts … it was kind of fiddly. I went as far as writing generators for everything so I could generate sample parameter data for my routes.
So I'm not 100% sure what I'd like that to look like in data, I do know I wouldn't want to do this for every single route by hand
Russ Olsen and I have been working on something to help with that. Still very much alpha.
The basic idea is to write something by hand that's easier, then grab a key and pull a tree out of the flatter file.
I have an experimental fork of Vase to try using this format as a more human-friendly representation than straight .edn
right, it just so happens that integrant is using such a structure for app config bootup goop
I can see fern being really great for composing data structures together, for sharing and reusing parts of structure. That's a big component of how I'd want to configure the routes in my app.
It's actually one of the lightbulbs I had with namespaced keywords … wait a second … this keyword has a specific, global meaning in my app
Yes. I also wanted to be able to extend Vase with "literals" from other libraries like pedestal.views
I've got to run, but will keep thinking about how to move more of the API into data.