Extract the oracle/price-feed interface to a separate library

[hussein-aitlahcen]

Extract the oracle/price-feed interface to a separate library

[KaiserKarel]

Probably a trait with the datatypes, and perhaps a a feature flag to only import the API definition without the actual server implementation (that's how I do it when using gRPC). Both the server and the client can depend on a single shared trait.

Server crate

pub trait API {
    fn get() -> Foo;
}

#[cfg(feature=server)]
mod server {
    pub struct Server {} 

    impl API for Server ...
}

Pallet crate

use server::API;

struct Client;

impl API for Client { 
    # pallet offchain worker logic here.
} 

[KaiserKarel]

I'd move the interface definition to the server implementation, and import that into the offchain worker. Where is the price-feed server defined?

[hussein-aitlahcen]

When you say importing that to the offchain worker. Do you mean importing the whole project as a dependency? The only "interface" we currently have is the http endpoint along with the JSON schema expected by the offchain worker (just wrapping the price), here in the server

[hussein-aitlahcen]

Ok that makes sense :)!

[KaiserKarel]

At least, I really like this pattern :) Since the server is kind of in charge of the API spec, it is logical to define the interface there as well. But now you do get a well defined API. It also allows for easy embedding in over different protocols.

tower plays really nicely with different frameworks and protocols too. If only we had async traits already, it'd be perfect.

[hussein-aitlahcen]

Of course this pattern is nice :).
It reminds me of Servant in Haskell, were we share the API so that you end up being able to automatically derive the client.