This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-09-13
Channels
- # announcements (1)
- # babashka (12)
- # beginners (10)
- # biff (9)
- # calva (2)
- # cherry (21)
- # cider (14)
- # clj-commons (76)
- # clj-kondo (8)
- # clj-on-windows (34)
- # cljs-dev (5)
- # clojure (48)
- # clojure-austin (7)
- # clojure-europe (97)
- # clojure-nl (1)
- # clojure-norway (14)
- # clojure-uk (22)
- # clojurescript (137)
- # conjure (33)
- # cursive (4)
- # datalevin (1)
- # deps-new (4)
- # devcards (2)
- # duct (3)
- # events (1)
- # fulcro (12)
- # graphql (9)
- # hyperfiddle (16)
- # jobs (8)
- # kaocha (1)
- # leiningen (6)
- # lsp (39)
- # malli (38)
- # membrane (20)
- # nbb (68)
- # observability (7)
- # off-topic (49)
- # pathom (11)
- # polylith (8)
- # portal (22)
- # re-frame (6)
- # releases (1)
- # remote-jobs (2)
- # shadow-cljs (24)
- # spacemacs (2)
- # squint (6)
- # xtdb (7)
I got 20 minutes to show off and narrate Hyperfiddle & Photon as possible substrates for a future experimental stack at work. With all this automatic compilation of client & server interactions, someone asked: what will we do when we need to expose a classical HTTP API for third-party integration?
Here's a tab overview of the few things I showed. 1. https://www.hyperfiddle.net/ 2. https://news.ycombinator.com/item?id=31217448 (first long comment by Dustin) 3. https://hyperfiddle.notion.site/Hyperfiddle-Photon-progress-update-57aee367c20e45b3b80366d1abe4fbc3 4. https://gist.github.com/dustingetz/2c1916766be8a61baa39f9f88feafc44 5. https://gist.github.com/dustingetz/dd67a35d818e3a1bf6733147cf5cdea7 6. https://gist.github.com/dustingetz/c2185feeda4067704f671b13b79eb362
we're embedded in clojure, you still get clojure
i.e. no need to use Photon for everything
Yeah, that was my on-the-fly answer: iterate N times faster to a "perfect" design, and when you know it's the one good for your product, then finally, start expanding efforts to produce the integration endpoints which are required. At least you won't have had to start from there, iterating it like we're used to!
What is the complete concrete circumstance the person has in mind? We can make an example to avoid confusion
HF Photon is great to produce interactive client-server code for a UI, but what if we want to expose an HTTP e.g. REST API for some external clients to integrate with their backend instead of having someone clicking through our UI.
B2B interactions.
so a backend REST endpoint side by side with the photon app?
yeah - I was wondering if Photon might be put to automation for this kind of task too.
e.g., yes you generate this UI client, but also publish specs for external callers to the backend "api" you generated based on this DAG.
obviously, not sure it's a good idea to have it auto-generated, since it's so easy to edit client-server code, programmers might forget they'll break external clients. Might be better to go the traditional route.
We can probably generate HTTP endpoints from HFQL definitions, and with clojure specs to document the interface
Thinking about it, if this generated concrete artifacts (git-versioned files), then at least breaking changes would be apparent.
Even if you didn't generate concrete artifacts, you'd gen data, and we could spit it to git-versioned files if-when it makes sense, I suppose.