Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Thoughts about HTTP layer

Thoughts about HTTP layer

Ff66c7d282da623a53f6b6da87782a56?s=128

Rostislav Zhuravsky

December 06, 2021
Tweet

Transcript

  1. How we have been taming Faraday

  2. None
  3. My first task

  4. We use Faraday

  5. What else can be used for HTTP calls?

  6. More detailed overview

  7. My experience

  8. HTTParty

  9. Faraday using class methods

  10. Faraday using connection

  11. Get back to the task

  12. How bad requests are handled

  13. The problematic code

  14. If you wouldn’t approve it, please, raise a hand

  15. What problems have we got?

  16. Adding a new request requires remembering about a lot of

    things: • Which statuses can be returned? • What errors can be thrown? • How to handle the errors? • What to do with a failed request? Retries?
  17. Our codebase is heavily glued to Faraday • What if

    Faraday API would be changed? • What if we would want to change the library? • What if we would need to fix/extend current implementation? • How to test it? Should we stub HTTP requests or mock objects?
  18. Everything we’re trying to achieve is to get some data

  19. HTTP is only an implementation detail

  20. Transportation layer Business logic Gem API

  21. Isolate all transportation details

  22. Business logic Transportation layer Gem API

  23. Isolate your dependencies

  24. Business logic Transportation layer Library wrapper Gem API

  25. Situation on the project Business logic Transportation layer Gem API

  26. Our plan was • Look through all the places where

    Faraday is used • Collect all the features we need to implement in our wrapper • Replace step by step Faraday with our library using feature toggles
  27. Features we need to support • Retries • Follow redirects

    • Raise an error on failure • Notify to Bugsnag • Parallel execution • Configure timeouts • Different request/response data format
  28. An example of serial requests

  29. An example of concurrent requests

  30. How have we implemented that?

  31. Faraday has a great feature: middleware

  32. Faraday::Response::RaiseError

  33. Retries

  34. The hardest part was concurrent mode

  35. We use Typhoeus for concurrent requests

  36. Usage

  37. Solution #1: Faraday supports Typhoeus adapter

  38. None
  39. Why is that problem for us?

  40. Solution #2. Gem parallel

  41. Final version

  42. How to test an HTTP client?

  43. None
  44. Mock requests

  45. Webmock

  46. More about the topic

  47. Summary • Write a high-level abstractions which correspond to actual

    business rules • Isolate dependencies on gems/libs • Explicit is better than implicit a.k.a keep everything you can under your control • Write tests
  48. Useful links • https://github.com/lostisland/faraday/issues/1310 • https://thoughtbot.com/upcase/videos/testing-interaction-with-3rd-party-apis • https://gist.github.com/woarewe/543a1275382941ffbb87324d2b302100 • https://gist.github.com/woarewe/81e2f8d181f99511985f91926d7f2f54

    • https://gist.github.com/woarewe/16a33e3eecbd7e2af9622afb2898db28 •
  49. Thanks