Closed bbarker closed 7 years ago
Something like
- AutowireServer.route[Api](service)(autowire.Core.Request(url, body))
+ AutowireServer.route[Api](new MyService(extraArg))(autowire.Core.Request(url, body))
Where
trait Api{
def methodA(a: Int): String
}
class MyService(extraArg: Thingy) extends Api{
def methodA(a: Int): String = {
doSomething(a, extraArg)
}
}
This is the general technique you can use for injecting "side-channel" information into your autowire methods: request metadata, user session, authentication credentials/tokens, logging context, etc. etc.
At some point this should make it into the docs; if someone wants commit access to help freshen them up I'd gladly give it
Thanks! I thought of that, but assumed it would be less than ideal to create a new Service every time a new request comes in ... but, maybe I could make the service extra light and wrapped in some other service that stores state.
On Wed, Aug 2, 2017 at 5:57 PM, Li Haoyi notifications@github.com wrote:
Closed #67 https://github.com/lihaoyi/autowire/issues/67.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lihaoyi/autowire/issues/67#event-1190410611, or mute the thread https://github.com/notifications/unsubscribe-auth/AA37julPg5tW0yiS5eZmPUCGbTOz9iBSks5sUPC_gaJpZM4OrpyF .
-- Brandon Barker brandon.barker@gmail.com
Yeah it's a bit annoying to have to instantiate a thing every time, but in the end it's just a single object allocation. If there's heavy initialization that needs to happen you can move that onto some other object, delegate to it, and re-use the heavily-initialized other-object over and over.
It might be possible that there's some clever way of changing the macro to implement this using implicits, but that's basically a research topic and I don't know what such a solution would end up looking like
I had a same question & this one really helped. Thanks! It would also be great to see implicit context macro someday :)
Sorry if this has been addressed before (tried a few searches without luck):
I haven't been able to think of a good way to inject additional information into an autowired API call on the server side. Traditionally, we might use an additional parameter to our API function ... but the fact that, on the server side, the API service is being abstractly handled as follows:
combined with the fact that the additional parameter wouldn't exist on the client, seems to make this impossible or non-obvious.
Example use case: running an API command that has metadata as a parameter - the server needs to fill in the remote ip address as a field in the metadata, since the client can't be trusted to do this.