Fork me on GitHub

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?


not really, let me explain by example


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, which is a more universal solution (non-clojure services)


right, this sounds like a good approach


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.


hateoas looks interesting btw, it fits nice within the whole CSP ecosystem.