Sharing Rquest API Models across libs?

[beforan]

Moving discussion out of a code comment / PR thread:

Originally posted by @AndyRae in #49 (comment)

Basically, RACKit contains API Client services for the RQuest REST API, and as such also contains Model/DTO classes the request and response payloads for that REST API.

However, it may be desirable for these models to be used as-is elsewhere. In fact we know this to be true; We expect the as yet unnamed Query library to accept raw response payloads e.g. for a job and to create and return raw request payloads for submitting job results.

To avoid duplication, it's clear that both RACKit and the query library should use the exact same classes for this (and anything else in future that wants to.

The question then is around the packaging strategy and as I see it there are 2 sane options

1. Move the models to their own POCO library that is used by both RACKit and Querylib
2. Leave the models in RACKit as they are really API Models and so belong with the API Clients; have Querylib have a dependency on RACKit as a whole, even though it's only using POCOs and not services from that library.

Thoughts?

[AndyRae]

I actually like Option 2 here.

Having the POCO library creates just a little more friction, not much, but enough.
But it would seem reasonable to have them as part of RACKit. If you want to use the API models then of course you would have a dependency on the API code.

Ultimately the Hutch applications that will then use these libraries, will use/inherit those models as part of their API also.

[AndyRae]

You could extend the thought also - why are we building two libraries?
If a Hutch job execution layer has to have a dependency on RACKit now anyway, then why not just one library for RQuest API AND job execution?

But no - the libraries should do one thing well. We should stick to one for API, and one for job execution.
I mostly wanted to write this down so I don't have to cover this line of thought in my head again.