This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-31
Channels
- # architecture (1)
- # aws (23)
- # beginners (13)
- # boot (18)
- # cider (5)
- # clara (1)
- # cljs-dev (22)
- # cljsjs (9)
- # cljsrn (28)
- # clojure (120)
- # clojure-canada (12)
- # clojure-dev (6)
- # clojure-italy (4)
- # clojure-korea (1)
- # clojure-russia (18)
- # clojure-sg (8)
- # clojure-spec (45)
- # clojure-uk (12)
- # clojurescript (240)
- # component (4)
- # cursive (17)
- # datomic (91)
- # editors-rus (4)
- # figwheel (2)
- # flambo (6)
- # hoplon (163)
- # instaparse (6)
- # jobs (1)
- # leiningen (2)
- # luminus (5)
- # om (22)
- # om-next (2)
- # onyx (35)
- # perun (15)
- # play-clj (1)
- # protorepl (4)
- # re-frame (106)
- # reagent (4)
- # ring (106)
- # schema (1)
- # spacemacs (17)
- # untangled (40)
- # yada (14)
Do I have the right approach?
so, say that i have a yada service, and i want to expose its routes to other internal services, so that they can generate requests using bidi etc. what would be the best way to go here ?
@lmergen: Just so I'm sure I understand: You want to know how to give a handler a bidi route structure, when it is part of the structure itself?
we have many internal services, all using yada, but in isolated repositories. i would prefer some structured way in which they invoke requests on each other, without too many hard-coded paths etc. so, one very universal way to go around this is to use the swagger.json, but i personally am considering something more high level, to easily integrate other yada services into each other has any thought been put into this before ?
So, one idea might be as follows:
- Create a bidi structure using keywords in place of handlers
- Create a yada handler which serializes this structure and sends it to a client
- To create the handler-version, write a simple handler which just looks up a k/v for what the handler should be
- On separate services, query for the structure, and use that to do path-for
, looking up by keyword
Alternatively, you might want to look into REST HATEOAS, https://en.wikipedia.org/wiki/HATEOAS which is a more universal solution (non-clojure services)
i think we might have to combine this with more formalized ‘service dependencies’ and configuration
@imre really appreciating your recent contribs
@lmergen: @dominicm is right to nudge you towards hateos imho. Oliy Hine (a juxt colleague) is working on this very problem and has some corresponding libraries based on pedastal. While I am always supportive of trying new approaches, history in this area is littered with the corpses of failed attempts at distributing service metadata: CORBA locators, WSDL, W3C W*, ESBs, service repositories. The basic problem is supporting change and resulting chaos. The hypermedia crowd encourage limiting client coupling to only a few root URIs and providing links to the rest. I'm cautiously optimistic that might be a better approach, simply because I'm skeptical of alternatives that have been tried and proven to fail.
@malcolmsparks: no worries, hope the direction aligns with what you envisaged and the quality is sufficient
@malcolmsparks: I agree. I think however that trying to expose a bidi structure is a nice experiment and doesn't go full CORBA. I'm looking more for ways to generalize orchestration and configuration, not request invocation.