4 ms·
A web app DSL that looks like: GET /hello |> jq: `{ world: ":)"}` pipeline getPage = |> jq: `{ sqlParams: [.params.id | tostring] }` |> pg: `
by williamcotton 1y ago
A web app DSL that looks like:
GET /hello
|> jq: `{ world: ":)"}`
pipeline getPage =
|> jq: `{ sqlParams: [.params.id | tostring] }`
|> pg: `SELECT * FROM pages WHERE id = $1`
|> jq: `{ team: .data.rows[0] }`
GET /page/:id
|> pipeline: getPage
WIP article that explains more:
https://williamcotton.com/articles/introducing-web-pipe https://williamcotton.com/articles/introducing-web-pipe
I would love feedback!
- duncanfwalker 1y agoI really like it. I particularly like that you've resisted the temptation to include SQL itself or the jq queries in the DSL. The validation piece makes it feel a bit a bit like the Rails mindset for people who work better in FP. I'd make a could of suggestions for the docs: Maybe a bit more discussion of how we'd test our webpipe code. I see why you've called them 'middlewares' but, maybe the term 'macros' or 'pipeline functions' might avoid confusion with express/connect middlewares
- williamcotton 1y agoOoh, I like “pipeline functions”! And thanks for the motivation to for figuring out a good way to talk about testing and generally clean up the (very messy) docs. It’s comments like yours that give someone the drive to continue.