Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added support of unchanged requests #433

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

kvokka
Copy link

@kvokka kvokka commented Feb 1, 2017

Added middleware for correct support status 304 in responses

It gives huge speed boost, if you have to

request same resources offten

@edtjones
Copy link
Collaborator

edtjones commented Feb 1, 2017

Thanks @kvokka - any reason for writing this rather than using the https://github.com/plataformatec/faraday-http-cache gem?

Also, I wonder if you can fix up the failing tests?

@kvokka
Copy link
Author

kvokka commented Feb 1, 2017

Thank you for so quick response.

gem https://github.com/plataformatec/faraday-http-cache is great, but it targets to client-side optimizing, rather this middleware is targeting to back-end.

This chink was made to prevent heavy response generation on other side, in favor checking updated_at field only, so, 200-500ms sub-requests transformed to 2-5ms.

Travis is green now :)

I've fix syntax to the most common style for Ruby 1.9.3 support. Strange to see 1.9.3 in 2017

Added middleware for correct support status 304 in responses

It gives huge speed boost, if you have to

request same resources offten
@kvokka
Copy link
Author

kvokka commented Feb 2, 2017

In Caching part of the README shown way, how to implement caching, but, if on other side object will be changed there is no way to get this information. Only expire_in cache, so you will do lots of unneeded expiration's or use stale data. With this middleware there is the way on other side of back-end microservice to know, since what moment the object is fresh.

Of course it is not perfect solution, but it is much more livable, than that, which is included in README.

If you like the code, I can do README update also (or you may take comments from the middleware)

@edtjones
Copy link
Collaborator

@kvokka a quick holding message to say I haven't forgotten about this! Just want to find some time to review properly.

@edtjones
Copy link
Collaborator

edtjones commented Jun 2, 2017

@zacharywelch if you're feeling keen could you review this?

@zacharywelch
Copy link
Collaborator

zacharywelch commented Jun 6, 2017

Hi @kvokka, thanks for the PR! Do you mind putting together some specs describing the middleware behavior? See first_level_parse_json_spec for an example.

I'm also curious what the difference would be with something like faraday-http-cache where it caches api responses and checks whether they're stale on subsequent requests to another microservice or api. Do you have an example you could share?

Another idea discussed in #445 would be to package your own faraday middleware if it's something that could be used by other faraday consumers. Generally her middleware is fundamental to the ORM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants