Faraday: Liste de souhaits de Faraday

• rendre net-http-persistent moins piraté en conservant un objet de connexion afin que nous n'ayons pas besoin d'un cache global
• faire en sorte que net-http-persistent n'utilise pas le gem ... 90% de celui-ci gère net-http que nous faisons déjà, donc la seule chose dont nous avons besoin est la logique rescue + reopen qui est quelques lignes de code et supprimerait la logique de couplage/traduction pour la gemme voir https://github.com/drbrain/net-http-persistent/pull/100
• autoriser l'utilisation de net-http-pipeline

Merci, ce sont d'excellentes suggestions !

rendre net-http-persistent moins piraté en conservant un objet de connexion afin que nous n'ayons pas besoin d'un cache global

Ah oui, une autre raison pour laquelle l'implémentation de Faraday de la sémantique Rack pour les classes adaptateur et middleware doit disparaître. Si l'adaptateur actuel était une propriété Faraday::Connection#adapter longue durée, l'adaptateur net-http pouvait conserver l'objet de connexion. Je viens d'ajouter "Revisiter l'API interne de l'adaptateur/du middleware (sémantique de l'adaptateur de rack de suppression)" à la liste de souhaits pour prendre en charge cela.

faire en sorte que net-http-persistant n'utilise pas la gemme

Je suis à bord. Merci pour l'indication du PR.

autoriser l'utilisation de net-http-pipeline

Faraday prend en charge les requêtes parallèles, mais je ne suis pas sûr que nous puissions utiliser net-http-pipeline pour les implémenter pour net-http . J'ai ajouté "Revisit pipelining ou parallel requests (net-http-pipeline, typhoeus)" à la liste de souhaits.

Pour le pipeline : j'ai décidé de ne pas l'utiliser dans mes projets car cela signifie
réécriture de la plupart de la logique du gestionnaire, donc faible priorité pour moi

Le ven 31 mai 2019 à 10h31 risque danger olson [email protected]
a écrit:

Merci, ce sont d'excellentes suggestions !

rendre net-http-persistant moins piraté en gardant un objet de connexion autour
donc nous n'avons pas besoin d'un cache global

Ah oui, une autre raison pour laquelle l'implémentation de Faraday de la sémantique Rack pour
les classes adaptateur et middleware doivent disparaître. Si l'adaptateur actuel était
une propriété Faraday::Connection#adapter de longue date, l'adaptateur net-http
pourrait conserver l'objet de connexion. Je viens d'ajouter "Revisiter
API interne de l'adaptateur/intergiciel (déposer la sémantique de l'adaptateur rack)" dans le
liste de souhaits pour soutenir cela.

faire en sorte que net-http-persistant n'utilise pas la gemme

Je suis à bord. Merci pour l'indication du PR.

autoriser l'utilisation de net-http-pipeline

Faraday prend en charge les demandes parallèles, mais je ne suis pas sûr si nous
pourrait utiliser net-http-pipeline pour les implémenter pour net-http. J'ai ajouté
"Revisiter le pipeline ou les requêtes parallèles (net-http-pipeline, typhoeus)" pour
la liste de souhaits.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/lostisland/faraday/issues/953?email_source=notifications&email_token=AAACYZ5IS7IRWR45K7IFKL3PYFOILA5CNFSM4HAAQSK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX2Z79ZKLOWPWS4HAAQSK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX2HJKLOWPWS4E
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAACYZ6EKR7M4ARR47IAI23PYFOILANCNFSM4HAAQSKQ
.

@grosser, vous avez peut-être entendu dire que nous sommes maintenant en train de sortir les adaptateurs et les middleware de Faraday.
Nous avons déjà fait beaucoup de travail pour rendre cela aussi simple que possible, notamment en exportant des tests et en fournissant quelques exemples ( faraday-net_http faraday-http )

Compte tenu de vos contributions passées, je me demandais si vous voudriez devenir propriétaire de net_http_persistent ?
Tout ce que vous avez à faire est de l'isoler dans un dépôt séparé (cela peut être sous votre utilisateur !) comme nous l'avons fait pour les exemples ci-dessus, et de publier une version 1.0 qui est exactement la même que la version actuelle. Nous l'ajouterons ensuite à la spécification de gem Faraday pour une compatibilité descendante. Le plan est alors de supprimer ces dépendances pour Faraday v2.0

À partir de là, vous êtes libre de le modifier/refactoriser à votre guise et d'apporter tous les changements de rupture que vous souhaitez 😄
N'hésitez pas à me dire si vous êtes intéressé ou non ! Je suis également heureux d'aider avec la première migration car je prévois de faire ce travail de toute façon

ça a l'air facile, je vais essayer

Le jeu. 31 décembre 2020 à 04h03, Matt [email protected] a écrit :

@grosser https://github.com/grosser vous avez peut-être entendu dire que nous sommes maintenant dans
le processus de sortie des adaptateurs et middleware de Faraday.
Nous avons déjà fait beaucoup de travail pour rendre cela aussi facile que possible,
y compris l'exportation de tests et la fourniture de quelques exemples (faraday-net_http
faraday-http)

Je me demandais, compte tenu de vos contributions passées, si vous voudriez prendre
propriété de net_http_persistent ?
Tout ce que vous avez à faire est de l'isoler dans un référentiel séparé (cela peut être
sous votre utilisateur !) comme nous l'avons fait pour les exemples ci-dessus, et publier une v1.0
qui est exactement le même que l'actuel. Nous l'ajouterons ensuite au
Faraday gem spec pour la rétrocompatibilité.

À partir de là, vous êtes libre de le modifier/refactoriser à votre guise et
faire tous les changements de rupture que vous voulez
N'hésitez pas à me dire si vous êtes intéressé ou non ! Je suis également heureux d'aider
avec la première migration car je prévois de faire ce travail de toute façon

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/lostisland/faraday/issues/953#issuecomment-752938926 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAACYZYOKFNQGJM5GXZQJMLSXRR73ANCNFSM4HAAQSKQ
.

@grosser Génial ! Merci de crier si vous avez besoin d'aide !
@julik s'il vous plaît voir mon commentaire ci-dessus pour @grosser , Patron 😄 ?

Salut les amis, bonne année 2021 ! Je vais bien m'approprier l'adaptateur Patron, le problème que j'ai rencontré lors de sa configuration était que j'ai trouvé l'utilisation de mocks dans les tests partagés très difficile à gérer (également étant donné que webmock corrige Patron à quelques endroits, sans ce qui est vraiment demandé). Lors de l'extraction, je suis tombé sur le fait que je devrais alors également devenir co-mainteneur des remplacements Webmock Patron - c'est une chose, et qu'au lieu de tester si la chose qui doit fonctionner fonctionne réellement, je testerais si cela fonctionne avec Webmock. C'est un peu personnel, mais un sujet relativement difficile pour 2020 pour moi a été de devoir convaincre les gens de choses, et j'ai épuisé mon budget « convaincant » pour cette année-là. Et j'ai fait un découvert important, et c'est devenu un peu un risque pour mon bien-être 😄 Je peux aller de A à B d'une manière très sûre et efficace, mais la quantité de va-et-vient que je peux gérer le long de cela chemin est bien plus bas qu'avant. Cela a aussi à voir avec le fait que je fais partie d'une organisation qui connaît une croissance rapide. Je ne suis pas en mesure d'exiger que des concessions soient faites pour cela – ce sont mes problèmes personnels après tout. Mais je dois budgétiser mon implication dans les choses.

Donc: si nous pouvons revoir cette décision (devoir utiliser webmock au lieu de requêtes réelles, ce qui est à propos des adaptateurs), je vais bien m'approprier l'intégration du client en gros.

@julik comprend tout à fait votre point de vue ! Je me souviens que nous avions déjà discuté dans le passé de la principale raison de l'introduction de Webmock, et avoir affaire à 8 adaptateurs différents en faisait certainement partie !

Nous avons rendu les tests disponibles en externe afin que la migration des adaptateurs groupés vers les adaptateurs externes soit aussi fluide et facile que possible, et puisque Faraday v1.0 regroupera toujours les adaptateurs (mais inclus sous forme de gems, plutôt que de fichiers dans le dossier lib), il est alors logique de les utiliser tels quels lors de l'extraction du repo dans une nouvelle gemme.

MAIS C'EST ÇA ! Une fois que la version 1.0 de la gem de l'adaptateur a été créée et ajoutée à Faraday pour une compatibilité descendante, comme nous l'avons fait pour l'adaptateur Net::HTTP , c'est là que vous pouvez démarrer un chemin v2.0 pour la gem de l'adaptateur et décider Que dois-je faire avec ça.
Cela, bien sûr, inclut la réécriture de tests avec le framework de votre choix et l'utilisation de vrais appels, si vous le souhaitez.
Une fois que la gemme est dans la soi-disant "terre d'utilisateurs", nous n'avons absolument plus le droit de prendre la décision et toutes les décisions devraient appartenir à la communauté et aux propriétaires de gemmes.

Et je vais vous en dire plus, nous discutons déjà en interne de la création d'une sorte de suite de "tests d'intégration" avec des demandes réelles. Les principales caractéristiques de cette suite seraient (toutes encore en discussion) :

• Gemified/Emballé de sorte qu'il puisse être utilisé "plug-and-play" avec n'importe quel adaptateur
• Fait de vraies demandes
• Prise en charge des conteneurs Docker (pour aider avec des choses comme une API fictive et des serveurs proxy)
• Test de performance
• Prise en charge des fibres/concurrence
• Rapport de vérification des fonctionnalités (teste les fonctionnalités de base "Faraday" et produit un rapport pour l'adaptateur pour montrer celles qui sont prises en charge par l'adaptateur, utile pour les utilisateurs qui en recherchent un nouveau)
• Ouvert pour en savoir plus... !

@technoweenie a même commencé à travailler dessus : https://github.com/technoweenie/faraday-live

Donc, si vous avez aussi envie d'aider, comme je me souviens que vous aviez des idées sympas sur la façon dont cela pourrait fonctionner, nous serions également heureux de recevoir des contributions et de l'aide sur ce front 😃

Je suis également heureux d'aider là où je peux (Merci @olleolleolle de m'avoir montré ça) :)

J'ai vu https://github.com/lostisland/faraday/projects/3 - Pour ce qui est de les diviser en gemmes, est-il prévu de créer une organisation faraday sur GitHub pour stocker toutes les gemmes individuelles ?

@iMacTia , un cc pour vous

@MikeRogers0 lostisland, cette organisation, héberge faraday-http , un adaptateur gemified. Peut-être que plus d'adaptateurs vivent dans cette organisation ?

Impressionnant! J'ai totalement masqué hier soir que @lostisland était un compte d'organisation :) Je pense que les mettre dans l'organisation est ma préférence.

La semaine prochaine, j'examinerai ce qui a été modifié pour déplacer l'adaptateur Net::HTTP dans une gemme, puis dupliquer pour Net::HTTP::Persistent :) Pour aider à accélérer les choses, je commencerai dans mon compte personnel, une fois on dirait qu'il a pris forme, je vais mettre un lien et nous pouvons le transférer.

Merci @MikeRogers0 , c'est merveilleux à entendre, toute aide supplémentaire est très appréciée.
@grosser connaît également très bien l'adaptateur Net::HTTP::Persistent qui y a contribué dans le passé, alors n'hésitez pas à le tenir au courant.

En ce qui concerne l'emplacement des adaptateurs, personnellement, je ne me sens pas très à l'aise avec l'endroit où ils devraient vivre.
Il est parfaitement logique pour moi qu'ils vivent sous un compte personnel, si cette personne est également le principal responsable.
Alors si ça vous satisfait, je n'ai rien contre laisser l'adaptateur sous votre compte 😄

@MikeRogers0 @julik @grosser J'ai créé un nouveau https://github.com/lostisland/faraday-adapter-template

Veuillez considérer cela comme un WIP et n'hésitez pas à nous faire part de vos commentaires pour l'améliorer !

@iMacTia Ce

J'ai configuré https://github.com/MikeRogers0/faraday-net_http_persistent en fonction de celui-ci - je l'ai configuré pour être transféré à @lostisland - Voulez-vous le

Travail fantastique @MikeRogers0 🎉, et très rapide aussi !
Je vérifiais le fonctionnement du transfert de référentiel et c'est un peu plus compliqué lorsque l'on passe d'un utilisateur à une organisation, donc si vous êtes toujours prêt à le transférer dans `lostisland, pourriez-vous s'il vous plaît me le transférer d'abord afin que je le transfère en moi ? Je vous ajouterai ensuite vous et @grosser en tant que mainteneurs à ce dépôt 👍

Aussi, heureux d'entendre que le référentiel de modèles a été utile! Si vous avez des commentaires (quelque chose de pas clair, tout ce que vous vouliez y figurer, des fautes de frappe, etc...) veuillez me le faire savoir ou n'hésitez pas à ouvrir un PR contre cela 😄

Les prochaines étapes seraient de publier une première version de la gemme dans Rubygems, de retirer l'adaptateur Net::HTTP::Persistent de Faraday et d'y brancher votre nouvelle gemme.
Je peux m'occuper de la libération, à vous de voir si vous voulez faire le RP d'échange contre Faraday ou non ( ici le RP sur la façon dont nous l'avons fait pour Net::HTTP )

@iMacTia - Génial, le transfert a commencé :)

Aussi, heureux d'entendre que le référentiel de modèles a été utile! Si vous avez des retours

J'ai ajouté une action GitHub et réécrit le fichier Readme. J'ai communiqué les principaux changements que j'ai apportés qui, je pense, pourraient être utiles :) J'ai également remplacé Rubocop par StandardRB, ce que j'aimerais encourager.

Les prochaines étapes seraient de publier une première version de la gemme dans Rubygems, de retirer l'adaptateur Net::HTTP::Persistent de Faraday et d'y brancher votre nouvelle gemme.

Impressionnant! Je vais travailler sur un PR

@MikeRogers0 @grosser repo transféré et vous devriez tous les deux avoir reçu une invitation 👍
https://github.com/lostisland/faraday-net_http_persistent

@MikeRogers0 merci pour le retour 🙏 !

@MikeRogers0 faraday-net_http_persistent est maintenant disponible sur Rubygems 🎉
https://rubygems.org/gems/faraday-net_http_persistent