Fork me on GitHub
#yada
<
2016-08-31
>
frozenlock06:08:27

Do I have the right approach?

lmergen09:08:08

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 ?

dominicm09:08:26

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

lmergen09:08:43

not really, let me explain by example

lmergen09:08:52

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 ?

dominicm10:08:53

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

dominicm10:08:17

Alternatively, you might want to look into REST HATEOAS, https://en.wikipedia.org/wiki/HATEOAS which is a more universal solution (non-clojure services)

lmergen10:08:39

right, this sounds like a good approach

lmergen10:08:59

i think we might have to combine this with more formalized ‘service dependencies’ and configuration

malcolmsparks19:08:10

@imre really appreciating your recent contribs

malcolmsparks19:08:16

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

imre19:08:30

@malcolmsparks: no worries, hope the direction aligns with what you envisaged and the quality is sufficient

lmergen19:08:10

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

lmergen19:08:11

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