Closed pcriv closed 6 years ago
@pablocrivella thanks for the write up. The idea of using dry makes some sense, the hurdle would be tying in the query builder and association handling.
I think the next logical step taking any of these ideas forward would be to eliminate inheritance / class variables and move to a mixin architecture. This put us in the best spot to allow threading support in future versions.
I'm pretty attached to Faraday for the foreseeable future, unless rest-client offers something Faraday cannot?
I would like to see how we can bring in dry-types / dry-struct into the project without breaking a bunch of existing features. LMK your thoughts.
On my implementation of a client i used dry-types and dry-struct to define the types on the jsonapi spec.
For example: (copied all the types for the sake of sharing one snippet 😅)
Then you could just parse the payload like:
What i like of this approach is that the types definition of the spec could be extracted to a gem in other to be used on different projects.
I also went for using rest-client instead of Faraday. Because i wanted to have a client class that was usable on a more higher lever without known about resources:
On top of this i started implementing the Resource functionality
ActiveResource
style:Of course my client is far from being as feature rich as this gem, but i needed a bit more of control, so i went for it. 😅 I wanted to share it to see if there is some ideas you think are worth including on this gem. I totally understand if you don't agree on the decisions i took. Just trying to see if we could collaborate on just one library :)
Resources