Faraday: Faradaysche Wunschliste

• Machen Sie net-http-persistent weniger hackig, indem Sie ein Verbindungsobjekt in der Nähe halten, damit wir keinen globalen Cache benötigen
• Machen Sie net-http-persistent, verwenden Sie das Gem nicht ... 90% davon verwalten net-http, was wir bereits tun, also brauchen wir nur die rescue + reopen Logik, die aus ein paar Zeilen Code besteht und würde die Kopplungs-/Übersetzungslogik für das Gem entfernen, siehe https://github.com/drbrain/net-http-persistent/pull/100
• erlauben die Verwendung von net-http-pipeline

Danke, das sind tolle Vorschläge!

Machen Sie net-http-persistent weniger hackig, indem Sie ein Verbindungsobjekt in der Nähe halten, damit wir keinen globalen Cache benötigen

Ah ja, ein weiterer Grund, warum Faradays Implementierung der Rack-Semantik für die Adapter- und Middleware-Klassen gehen muss. Wenn der aktuelle Adapter eine langlebige Faraday::Connection#adapter Eigenschaft war, könnte der net-http Adapter das Verbindungsobjekt behalten. Ich habe gerade "Revisit adapter/middleware internal API (drop Rack adapter semantics)" zur Wunschliste hinzugefügt, um dies zu unterstützen.

machen net-http-persistent das Gem nicht verwenden

Ich bin an Bord. Danke für den Hinweis auf die PR.

erlauben die Verwendung von net-http-pipeline

Faraday unterstützt parallele Anfragen, aber ich bin mir nicht sicher, ob wir net-http-pipeline könnten, um sie für net-http zu implementieren. Ich habe "Revisit Pipelining or parallel Requests (net-http-pipeline, typhoeus)" zur Wunschliste hinzugefügt.

Für Pipeline: Ich habe mich entschieden, das in meinen Projekten nicht zu verwenden, weil es bedeutet
Umschreiben des Großteils der Handlerlogik, also niedrige Prio für mich

Am Freitag, 31. Mai 2019 um 10:31 Uhr risk risk olson [email protected]
schrieb:

Danke, das sind tolle Vorschläge!

Machen Sie net-http-persistent weniger hackig, indem Sie ein Verbindungsobjekt in der Nähe halten
Wir brauchen also keinen globalen Cache

Ah ja, ein weiterer Grund, warum Faradays Implementierung der Rack-Semantik für
die Adapter- und Middleware-Klassen müssen weg. Wenn der aktuelle Adapter
eine langlebige Faraday::Connection#adapter-Eigenschaft, der net-http-Adapter
könnte das Verbindungsobjekt festhalten. Ich habe gerade "Revisit" hinzugefügt
Adapter-/Middleware-interne API (Drop-Rack-Adapter-Semantik)" auf die
Wunschliste, dies zu unterstützen.

machen net-http-persistent das Gem nicht verwenden

Ich bin an Bord. Danke für den Hinweis auf die PR.

erlauben die Verwendung von net-http-pipeline

Faraday unterstützt parallele Anfragen, aber ich bin mir nicht sofort sicher, ob wir
könnte net-http-pipeline verwenden, um sie für net-http zu implementieren. Ich habe hinzugefügt
"Revisit Pipelining oder parallele Anfragen (net-http-pipeline, typhoeus)" zu
die Wunschliste.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/lostisland/faraday/issues/953?email_source=notifications&email_token=AAACYZ5IS7IRWR45K7IFKL3PYFOILA5CNFSM4HAAQSK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKT4WSI
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAACYZ6EKR7M4ARR47IAI23PYFOILANCNFSM4HAAQSKQ
.

@grosser Sie haben vielleicht gehört, dass wir jetzt Adapter und Middleware aus Faraday herausschieben.
Wir haben bereits viel Arbeit geleistet, um dies so einfach wie möglich zu machen, einschließlich des Exports von Tests und der Bereitstellung einiger Beispiele ( faraday-net_http faraday -http )

Angesichts Ihrer bisherigen Beiträge habe ich mich gefragt, ob Sie die Verantwortung für net_http_persistent übernehmen möchten.
Alles, was Sie tun müssen, ist, es in ein separates Repository zu isolieren (dies kann unter Ihrem Benutzer sein!) Wir fügen es dann zur Abwärtskompatibilität zur Faraday-Edelsteinspezifikation hinzu. Der Plan ist dann, diese Abhängigkeiten für Faraday v2.0 zu löschen

Von dort aus können Sie es nach Herzenslust ändern / umgestalten und alle gewünschten Änderungen vornehmen 😄
Lass es mich wissen, ob du Interesse hast oder nicht 🙌! Ich helfe auch gerne bei der ersten Migration, da ich diese Arbeit sowieso vorhabe

klingt einfach, ich werde es versuchen

Am Do, 31. Dez. 2020 um 04:03 schrieb Matt [email protected] :

@grosser https://github.com/grosser Sie haben vielleicht gehört, dass wir jetzt dabei sind
den Prozess des Pushens von Adaptern und Middleware aus Faraday.
Wir haben schon viel daran gearbeitet, dies so einfach wie möglich zu machen,
einschließlich des Exports von Tests und Bereitstellung einiger Beispiele (faraday-net_http
faraday-http)

Angesichts Ihrer bisherigen Beiträge habe ich mich gefragt, ob Sie gerne teilnehmen möchten
Besitz von net_http_persistent?
Alles, was Sie tun müssen, ist, es in ein separates Repo zu isolieren (dies kann sein:
unter Ihrem Benutzer!), wie wir es für die obigen Beispiele getan haben, und veröffentlichen eine v1.0
das ist genau das gleiche wie das aktuelle. Wir fügen es dann dem hinzu
Faraday-Edelstein-Spezifikation für Abwärtskompatibilität.

Von dort aus können Sie es nach Herzenslust ändern / umgestalten und
Nehmen Sie alle wichtigen Änderungen vor, die Sie wollen 😄
Lass es mich wissen, ob du Interesse hast oder nicht 🙌! Ich helfe auch gerne
mit der ersten Migration, da ich die Arbeit sowieso vorhabe

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/lostisland/faraday/issues/953#issuecomment-752938926 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAACYZYOKFNQGJM5GXZQJMLSXRR73ANCNFSM4HAAQSKQ
.

@grosser Super ! Bitte rufen Sie an, wenn Sie Hilfe benötigen!
@julik bitte sehen Sie meinen Kommentar oben für @grosser , möchten Sie etwas Ähnliches für den Patron Adapter tun 😄?

Hey Leute, frohes 2021! Es geht mir gut, den Patron-Adapter zu übernehmen. Das Problem, auf das ich bei der Einrichtung gestoßen bin, war jedoch, dass die Verwendung von Mocks in den gemeinsamen Tests sehr schwierig zu verwalten war (auch angesichts der Tatsache, dass Webmock Patron an einigen Stellen patcht, ohne das ist wirklich angesagt). Bei der Extraktion stolperte ich über die Tatsache, dass ich dann auch Mitbetreuer der Patron-Webmock-Overrides werden müsste - das ist eine Sache, und anstatt zu testen, ob das Ding, das funktionieren muss, tatsächlich funktioniert, würde ich testen, ob es funktioniert mit Webmock. Das ist ein bisschen persönlich, aber ein relativ schwieriges Thema für 2020 war für mich, die Leute von Dingen zu überzeugen, und ich habe mein "überzeugendes" Budget für dieses Jahr aufgebraucht. Und bin stark in Überziehung geraten, und es wurde tatsächlich ein bisschen zu einem Risiko für mein Wohlbefinden 😄 Ich komme sehr sicher und effektiv von A nach B, aber das Hin und Her kann ich damit bewältigen Pfad ist viel niedriger als früher. Das hat auch damit zu tun, dass ich Teil einer schnell wachsenden Organisation bin. Dafür kann ich keine Zugeständnisse verlangen – es sind schließlich meine persönlichen Anliegen. Aber ich muss mein Engagement für die Dinge budgetieren.

Also: Wenn wir diese Entscheidung überdenken können (wobei Webmock anstelle von tatsächlichen Anfragen verwendet werden muss, worum es bei den Adaptern geht), kann ich die Benutzerintegration im Großen und Ganzen übernehmen.

@julik versteh voll und ganz deinen Punkt! Ich erinnere mich, dass wir bereits in der Vergangenheit den Hauptgrund für die Einführung von Webmock diskutiert haben, und der Umgang mit 8 verschiedenen Adaptern war definitiv einer davon!

Wir haben Tests extern verfügbar gemacht, damit die Migration von gebündelten zu externen Adaptern so reibungslos und einfach wie möglich verläuft, und da Faraday v1.0 weiterhin Adapter bündelt (aber als Gems und nicht als Dateien im Ordner lib enthalten), dann ist es sinnvoll, sie so zu verwenden, wie sie sind, wenn das Repo in einen neuen Edelstein extrahiert wird.

ABER DAS IST ES! Sobald die v1.0 des Adapter-Gems erstellt und aus Gründen der Abwärtskompatibilität zu Faraday hinzugefügt wurde, wie wir es beim Net::HTTP Adapter getan haben, können Sie dort einen v2.0-Pfad für das Adapter-Gem starten und entscheiden was damit zu tun ist.
Dazu gehört natürlich das Umschreiben von Tests mit jedem beliebigen Framework und die Verwendung von echten Aufrufen, wenn Sie möchten.
Sobald sich der Edelstein im sogenannten "Benutzerland" befindet, haben wir absolut kein Recht mehr, das Sagen zu haben und alle Entscheidungen sollten bei der Community und den Edelsteinbesitzern liegen.

Und ich sage Ihnen noch mehr, wir diskutieren bereits intern darüber, eine Art "Integrationstest"-Suite zu erstellen, wobei konkrete Anfragen gestellt werden. Die Hauptmerkmale dieser Suite wären (alle noch zur Diskussion):

• Gemifiziert/verpackt, so dass es "Plug-and-Play" mit jedem Adapter verwendet werden kann
• Stellt echte Anfragen
• Unterstützung für Docker-Container (um bei Dingen wie einer Mock-API und Proxy-Servern zu helfen)
• Leistungstest
• Unterstützung von Fasern/Gleichzeitigkeit
• Funktionsprüfungsbericht (Tests gegen "Faraday"-Basisfunktionen und erstellt einen Bericht für den Adapter, um zu zeigen, welche vom Adapter unterstützt werden, nützlich für Benutzer, die nach einem neuen suchen)
• Offen für mehr... !

@technoweenie hat sogar angefangen daran zu arbeiten: https://github.com/technoweenie/faraday-live

Also, wenn ihr auch Lust habt, dabei zu helfen, da ich mich erinnere, dass ihr einige coole Ideen hattet, wie das funktionieren könnte, würden wir uns auch über Inputs und Hilfe an dieser Front freuen 😃

Ich helfe auch gerne, wo ich kann (Danke @olleolleolle, dass du

Ich habe https://github.com/lostisland/faraday/projects/3 gesehen - Gibt es Pläne, diese in Gems aufzuteilen, auf GitHub eine Faraday-Organisation zu erstellen, um alle einzelnen Gems zu speichern?

@iMacTia , ein cc für dich

@MikeRogers0 lostisland, diese Organisation, -http , einen gemified-Adapter. Vielleicht leben einfach mehr der Adapter in dieser Organisation?

Fantastisch! Ich habe letzte Nacht völlig ausgeblendet, dass @lostisland ein Organisationskonto war :) Ich denke, es ist meine Präferenz, sie in die Organisation zu integrieren.

Nächste Woche werde ich mir ansehen, was geändert wurde, um den Net::HTTP Adapter in ein Juwel zu verschieben und dann für Net::HTTP::Persistent zu duplizieren :) Um die Dinge zu beschleunigen, fange ich einmal in meinem persönlichen Konto an es sieht so aus, als hätte es Gestalt angenommen. Ich werde einen Link erstellen und wir können ihn übertragen.

Danke @MikeRogers0 , das ist wunderbar zu hören, jede zusätzliche Hilfe wird sehr geschätzt.
@grosser kennt sich auch sehr gut mit dem Net::HTTP::Persistent Adapter aus, da er in der Vergangenheit dazu beigetragen hat, also halten Sie ihn bitte auf dem Laufenden.

Was den Standort der Adapter angeht, habe ich persönlich keine großen Meinungen darüber, wo sie leben sollten.
Es macht für mich absolut Sinn, dass sie unter einem persönlichen Konto einer Person leben, wenn diese Person auch der Hauptverwalter ist.
Also wenn du damit zufrieden bist, habe ich nichts dagegen den Adapter unter deinem Account zu belassen 😄

@MikeRogers0 @julik @grosser Ich habe ein neues Vorlagen- https://github.com/lostisland/faraday-adapter-template

Bitte betrachten Sie dies sehr als WIP und fühlen Sie sich frei, Feedback zu geben, um es zu verbessern!

@iMacTia Dieses Vorlagen-

Ich habe https://github.com/MikeRogers0/faraday-net_http_persistent darauf basierend eingerichtet - ich habe es so eingerichtet, dass es an @lostisland übertragen wird - Möchten Sie es betrachten und sicherstellen, dass ich nichts Offensichtliches übersehen habe? :)

Fantastische Arbeit @MikeRogers0 🎉, und noch dazu richtig schnell!
Ich habe überprüft, wie der Repository-Transfer funktioniert und es ist etwas komplizierter, wenn man von Benutzer zu Organisation wechselt in mir? Ich werde dich und @grosser dann als Betreuer zu diesem Repo hinzufügen 👍

Ich freue mich auch zu hören, dass das Vorlagen-Repository hilfreich war! Wenn Sie Feedback haben (etwas Unklares, alles, was Sie sich wünschen, Tippfehler usw.)

Die nächsten Schritte wären, eine erste Version des Gems in Rubygems freizugeben, den Net::HTTP::Persistent Adapter von Faraday zu entfernen und dort dein neues Gem einzustecken.
Ich kann mich um die Veröffentlichung kümmern, es bleibt dir überlassen, ob du die PR gegen Faraday tauschen willst oder nicht ( hier die PR, wie wir es für Net::HTTP )

@iMacTia -

Ich freue mich auch zu hören, dass das Vorlagen-Repository hilfreich war! Wenn Sie Feedback haben

Ich habe eine GitHub-Aktion hinzugefügt und die Readme neu geschrieben. Ich habe die wichtigsten Änderungen, die ich vorgenommen habe, veröffentlicht, die meiner Meinung nach nützlich sein könnten :) Ich habe auch Rubocop gegen StandardRB ausgetauscht, was ich ermutigen möchte.

Die nächsten Schritte wären, eine erste Version des Gems in Rubygems freizugeben, den Net::HTTP::Persistent-Adapter von Faraday zu entfernen und dein neues Gem dort einzustecken.

Fantastisch! Ich werde an einer PR arbeiten

@MikeRogers0 @grosser Repo übertragen und ihr
https://github.com/lostisland/faraday-net_http_persistent

@MikeRogers0 danke für das Feedback 🙏!

@MikeRogers0 faraday-net_http_persistent ist jetzt auf Rubygems verfügbar 🎉
https://rubygems.org/gems/faraday-net_http_persistent