:recycle: `Json` api support for the upstream search engines

[neon-mmd]

:recycle: `Json` api support for the upstream search engines

[neon-mmd]

Also, one thing I would like to suggest that is that you don't need to add to_vec() because the .bytes() function already returns a vec<u8> so converting a vec fo a vec does not make sense like it would be an unnecessary conversion and also redundant too.

Can you clarify this for me because I might be missing something here. Because the compiler advises me to use the .to_vec() method. I'm fairly new to the library and the language so please excuse me if I missed something 😅

But yeah, I agree, using references should be memory efficient and I would prefer to implement it that way if it's reasonably straightforward. Although, I believe we shouldn't optimize for the sake of optimization (aka "premature optimization"). What do you think 🙂

Yes, I agree, also I think from the compilor error it seems that you will have to go with the to_vec() method to fix this error. So I think that's the only way to fix this. So I would suggest going with the to_vec() method. 🙂

[github-actions]

The issue has been unlocked and is now ready for dev. If you would like to work on this issue, you can comment to have it assigned to you. You can learn more in our contributing guide https://github.com/neon-mmd/websurfx/blob/rolling/CONTRIBUTING.md

[jfvillablanca]

I'd like to work on this since I'll be using this to implement Qwant [#317]

[neon-mmd]

I'd like to work on this since I'll be using this to implement Qwant [#317]

Yes sure, we will assign this issue to you. You may start working on it right away 🚀 🙂

[jfvillablanca]

Is it okay for the return type to be a Result<Vec<u8>, EngineError> instead of Result<&[u8], EngineError>

in other words, instead of:

Ok(client
    .get(url)
    .headers(header_map)
    .send()
    .await
    .change_context(EngineError::RequestError)?
    .bytes() // This returns Bytes causing a compile-time error
    .await
    .change_context(EngineError::RequestError)?)

I rewrite it like this:

Ok(client
    .get(url)
    .headers(header_map)
    .send()
    .await
    .change_context(EngineError::RequestError)?
    .bytes()
    .await
    .change_context(EngineError::RequestError)?
    .to_vec()) // Turn into a Vec instead

what do you think? will this be a suboptimal implementation?

[neon-mmd]

Is it okay for the return type to be a Result<Vec<u8>, EngineError> instead of Result<&[u8], EngineError>

in other words, instead of:

Ok(client
    .get(url)
    .headers(header_map)
    .send()
    .await
    .change_context(EngineError::RequestError)?
    .bytes() // This returns Bytes causing a compile-time error
    .await
    .change_context(EngineError::RequestError)?)

I rewrite it like this:

Ok(client
    .get(url)
    .headers(header_map)
    .send()
    .await
    .change_context(EngineError::RequestError)?
    .bytes()
    .await
    .change_context(EngineError::RequestError)?
    .to_vec()) // Turn into a Vec instead

what do you think? will this be a suboptimal implementation?

Actually, I don't mind both implementations are good, but slices tend to be a little bit more memory efficient, that's why I had put the result with the slices in the sample code. Also, one thing I would like to suggest that is that you don't need to add to_vec() because the .bytes() function already returns a vec<u8> so converting a vec fo a vec does not make sense like it would be an unnecessary conversion and also redundant too. 🙂

[jfvillablanca]

Also, one thing I would like to suggest that is that you don't need to add to_vec() because the .bytes() function already returns a vec<u8> so converting a vec fo a vec does not make sense like it would be an unnecessary conversion and also redundant too.

Can you clarify this for me because I might be missing something here. Because the compiler advises me to use the .to_vec() method. I'm fairly new to the library and the language so please excuse me if I missed something 😅

But yeah, I agree, using references should be memory efficient and I would prefer to implement it that way if it's reasonably straightforward. Although, I believe we shouldn't optimize for the sake of optimization (aka "premature optimization"). What do you think 🙂