Fork me on GitHub
#pedestal
<
2017-05-12
>
sineer00:05:37

@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.

mtnygard12:05:32

@sineer Oh, that’s interesting! I never ran into that because I just habitually use cider-load-buffer.

hagmonk21:05:13

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

hagmonk21:05:58

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

mtnygard21:05:08

@hagmonk That's on my wish list. Pretty much exactly as you described.

mtnygard21:05:17

But maybe with a twist...

mtnygard21:05:58

I've been thinking of it in parts like this:

mtnygard21:05:29

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.

mtnygard21:05:54

2. The ability for Pedestal routes to have extra data that Pedestal doesn't care about, but carries along.

mtnygard21:05:09

3. A library that can consume that data and generate UI & Swagger spec from it.

hagmonk22:05:29

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.

hagmonk22:05:05

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

mtnygard22:05:07

wow, that sounds fantastic

hagmonk22:05:14

I don't think there's anything proprietary in here, so, a screenshot:

hagmonk22:05:11

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

mtnygard22:05:38

nice and generic, open to extension

hagmonk22:05:52

(and I cheat and just stuff the data into a transit json encoded body attribute, no websocket here 😬)

mtnygard22:05:06

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?

hagmonk22:05:17

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.

hagmonk22:05:35

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

mtnygard22:05:18

Yeah, it gets tedious to write big data structures by hand.

mtnygard22:05:44

Russ Olsen and I have been working on something to help with that. Still very much alpha.

mtnygard22:05:18

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.

mtnygard22:05:46

I have an experimental fork of Vase to try using this format as a more human-friendly representation than straight .edn

hagmonk22:05:33

Oh man, weavejester is going to have to update integrant 🙂

mtnygard22:05:42

What is integrant?

hagmonk22:05:03

i'm using it in my apps now, I like it a lot

hagmonk22:05:20

It feels like a subset of fern after my very superficial skim through your page

mtnygard22:05:54

There's some definite similarity.

hagmonk22:05:56

less dogmatic than component, less hope-and-pray than mount

mtnygard22:05:21

But fern is only about making it easier to write nested data structures.

mtnygard22:05:37

It looks like Integrant does more

hagmonk22:05:44

right, it just so happens that integrant is using such a structure for app config bootup goop

hagmonk22:05:35

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.

hagmonk22:05:11

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

mtnygard22:05:14

Yes. I also wanted to be able to extend Vase with "literals" from other libraries like pedestal.views

hagmonk22:05:39

Hmm not sure I've looked at pedestal views

mtnygard22:05:49

(It's not quite ready to unveil.)

mtnygard22:05:11

Fern also has some pretty nice error reporting:

mtnygard22:05:02

I've got to run, but will keep thinking about how to move more of the API into data.

hagmonk22:05:58

Yeah for sure! I’ll think more on this too 👍