> Does seem to take a lot of work to redefine all the types from the existing services (unless I'm missing something).
The goal is to keep this type of rework minimal-to-none, by leveraging the type data that's already there. In typed languages, if the contracts are well typed, then you're already 90% of the way there.
> Given a rest service output, can't some of these things be auto generated ?
Exactly. For example, Vyne can work with a plain old swagger file, which many services already have. From there, it's a little additional metadata to identify ID's etc.
However, the idea is that getting Vyne working should be much less code than the alternative - which is to write the integration code manually. Also, getting Vyne going is a one-off cost, which should remain robust as the surrounding services change their APIs.
Absolutely, and I've had a cursory play with this.
The big challenge is the lack of type data, which makes the upfront plumbing kinda painful.
The ideal setup would be to leverage Typescript's type data to generate the schemas, for those who have written their API's in TS. However, that requires hooking into the compilation phase, and I haven't had time to explore that in anger yet.
I know that getting a great solution for the Node community is really important, I just haven't cracked it yet.
> Does seem to take a lot of work to redefine all the types from the existing services (unless I'm missing something).
The goal is to keep this type of rework minimal-to-none, by leveraging the type data that's already there. In typed languages, if the contracts are well typed, then you're already 90% of the way there.
> Given a rest service output, can't some of these things be auto generated ?
Exactly. For example, Vyne can work with a plain old swagger file, which many services already have. From there, it's a little additional metadata to identify ID's etc.
However, the idea is that getting Vyne working should be much less code than the alternative - which is to write the integration code manually. Also, getting Vyne going is a one-off cost, which should remain robust as the surrounding services change their APIs.