Faraday: Lista de deseos de Faraday

• hacer que net-http-persistent sea menos pirateado manteniendo un objeto de conexión alrededor para que no necesitemos un caché global
• hacer que net-http-persistent no use la gema ... el 90% está administrando net-http, lo que ya hacemos, por lo que lo único que necesitamos es la lógica rescue + reopen , que son unas pocas líneas de código y eliminaría la lógica de acoplamiento / traducción para la gema, consulte https://github.com/drbrain/net-http-persistent/pull/100
• permitir el uso de net-http-pipeline

¡Gracias, esas son excelentes sugerencias!

hacer que net-http-persistent sea menos pirateado manteniendo un objeto de conexión alrededor para que no necesitemos un caché global

Ah, sí, otra razón por la que la implementación de la semántica de Rack de Faraday para las clases de adaptador y middleware debe desaparecer. Si el adaptador actual era una propiedad Faraday::Connection#adapter larga duración, el adaptador net-http podría retener el objeto de conexión. Acabo de agregar "Revisar la API interna del adaptador / middleware (eliminar la semántica del adaptador de Rack)" a la lista de deseos para admitir esto.

hacer que net-http-persistent no use la gema

Estoy a bordo. Gracias por el puntero al PR.

permitir el uso de net-http-pipeline

Faraday admite solicitudes paralelas, pero no estoy seguro de si podríamos usar net-http-pipeline para implementarlas por net-http . Agregué "Revisar la canalización o las solicitudes paralelas (net-http-pipeline, typhoeus)" a la lista de deseos.

Para canalización: decidí no usar eso en mis proyectos porque significa
reescribiendo la mayor parte de la lógica del controlador, tan poco prio para mí

El viernes 31 de mayo de 2019 a las 10:31 a. M. Riesgo peligro olson [email protected]
escribió:

¡Gracias, esas son excelentes sugerencias!

hacer que net-http-persistent sea menos pirateado manteniendo un objeto de conexión alrededor
entonces no necesitamos un caché global

Ah, sí, otra razón por la que la implementación de Faraday de la semántica de Rack para
las clases de adaptador y middleware deben desaparecer. Si el adaptador de corriente fue
una propiedad de adaptador Faraday :: Connection # de larga duración, el adaptador net-http
podría aferrarse al objeto de conexión. Acabo de agregar "Revisitar
API interna del adaptador / middleware (semántica del adaptador de rack de caída) "al
lista de deseos para apoyar esto.

hacer que net-http-persistent no use la gema

Estoy a bordo. Gracias por el puntero al PR.

permitir el uso de net-http-pipeline

Faraday admite solicitudes paralelas, pero no estoy seguro de si
podría usar net-http-pipeline para implementarlos para net-http. he añadido
"Revisar la canalización o las solicitudes paralelas (net-http-pipeline, typhoeus)" para
la lista de deseos.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/lostisland/faraday/issues/953?email_source=notifications&email_token=AAACYZ5IS7IRWR45K7IFKL3PYFOILA5CNFSM4HAAQSK2YY3PNVWWK3TUL52HS4DFVREXG63JSODMVNW77 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAACYZ6EKR7M4ARR47IAI23PYFOILANCNFSM4HAAQSKQ
.

@grosser, es posible que haya escuchado que ahora estamos en el proceso de sacar adaptadores y middleware de Faraday.
Ya hemos trabajado mucho para que esto sea lo más fácil posible, incluida la exportación de pruebas y algunos ejemplos ( faraday-net_http faraday -http )

Me preguntaba, dadas sus contribuciones pasadas, si le gustaría tomar posesión de net_http_persistent.
Todo lo que necesita hacer es aislarlo en un repositorio separado (¡esto puede estar debajo de su usuario!) Como hicimos para los ejemplos anteriores, y lanzar una v1.0 que es exactamente la misma que la actual. Luego, lo agregaremos a la especificación de gemas de Faraday para compatibilidad con versiones anteriores. Entonces, el plan es eliminar estas dependencias para Faraday v2.0

A partir de ahí, eres libre de cambiarlo / refactorizarlo a tu gusto y hacer todos los cambios importantes que quieras 😄
¡Por favor, avíseme si está interesado o no 🙌! También me complace ayudar con la primera migración, ya que planeo hacer ese trabajo de todos modos.

suena fácil, lo intentaré

El jueves, 31 de diciembre de 2020 a las 4:03 a.m., Matt [email protected] escribió:

@grosser https://github.com/grosser es posible que haya escuchado que ahora estamos en
el proceso de empujar adaptadores y middleware fuera de Faraday.
Ya hemos trabajado mucho para que esto sea lo más fácil posible,
incluida la exportación de pruebas y algunos ejemplos (faraday-net_http
faraday-http)

Me preguntaba, dadas sus contribuciones pasadas, si le gustaría tomar
propiedad de net_http_persistent?
Todo lo que necesita hacer es aislarlo en un repositorio separado (esto puede ser
debajo de su usuario!) como hicimos para los ejemplos anteriores, y lanzamos una versión 1.0
que es exactamente igual que el actual. Luego lo agregaremos al
Especificaciones de la gema de Faraday para compatibilidad con versiones anteriores.

A partir de ahí, eres libre de cambiarlo / refactorizarlo a tu gusto y
haciendo todos los cambios importantes que quieras 😄
¡Por favor, avíseme si está interesado o no 🙌! También estoy feliz de ayudar
con la primera migración, ya que planeo hacer ese trabajo de todos modos

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/lostisland/faraday/issues/953#issuecomment-752938926 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAACYZYOKFNQGJM5GXZQJMLSXRR73ANCNFSM4HAAQSKQ
.

@grosser ¡Impresionante! ¡Grita si necesitas ayuda!
@julik, por favor vea mi comentario arriba para @grosser , ¿le gustaría hacer algo similar para el Patron adapter 😄?

Hola amigos, ¡feliz 2021! Estoy bien tomar posesión del adaptador Patron, aunque el problema que encontré al configurarlo fue que encontré el uso de simulacros en las pruebas compartidas muy difícil de administrar (también dado que webmock parchea Patron en algunos lugares, sin que realmente se pide). Al hacer la extracción, me topé con el hecho de que también tendría que convertirme en co-mantenedor de las anulaciones de la webmock de Patron; eso es una cosa, y que en lugar de probar si lo que debe funcionar realmente funciona, estaría probando si funciona con Webmock. Esto es un poco personal, pero un tema relativamente difícil para 2020 para mí ha sido tener que convencer a la gente de las cosas, y agoté mi presupuesto "convincente" para ese año. Y entré en un gran sobregiro, y en realidad se convirtió en un riesgo para mi bienestar 😄 Puedo ir de A a B de una manera muy segura y efectiva, pero la cantidad de ida y vuelta que puedo manejar a lo largo de ese El camino es mucho más bajo de lo que solía ser. Esto también tiene que ver con el hecho de que formo parte de una organización que está experimentando un rápido crecimiento. No estoy en condiciones de exigir que se hagan concesiones al respecto; después de todo, son mis problemas personales. Pero tengo que presupuestar mi participación en las cosas.

Entonces: si podemos revisar esa decisión (tener que usar webmock en lugar de solicitudes reales, que es de lo que se tratan los adaptadores), estoy bien tomando posesión de la integración de usuarios al por mayor.

@julik ¡entiende totalmente tu punto! Recuerdo que ya discutimos en el pasado la razón principal para presentar Webmock, ¡y tener que lidiar con 8 adaptadores diferentes fue definitivamente una de esas!

Hemos puesto las pruebas a disposición externamente para que la migración de adaptadores empaquetados a externos sea lo más fluida y sencilla posible, y dado que Faraday v1.0 seguirá empaquetando adaptadores (pero incluidos como gemas, en lugar de archivos en la carpeta lib), entonces tiene sentido usarlos como están al extraer el repositorio en una nueva gema.

¡PERO ESO ES TODO! Una vez que se ha creado la v1.0 de la gema del adaptador y se ha agregado a Faraday para compatibilidad con versiones anteriores, como hicimos para el adaptador Net::HTTP , ahí es donde puede iniciar una ruta v2.0 para la gema del adaptador y decidir Qué hacer con ello.
Eso, por supuesto, incluye la reescritura de pruebas con el marco que desee y el uso de llamadas reales, si lo desea.
Una vez que la gema está en la llamada "tierra de los usuarios", ya no tenemos absolutamente ningún derecho a tomar las decisiones y todas las decisiones deben depender de la comunidad y de los propietarios de las gemas.

Y les diré más, ya estamos discutiendo internamente sobre la creación de algún tipo de conjunto de "pruebas de integración" con solicitudes reales que se realizan. Las principales características de esta suite serían (todas aún en discusión):

• Gemificado / empaquetado para que se pueda usar "plug-and-play" con cualquier adaptador
• Realiza solicitudes reales
• Soporte para contenedores docker (para ayudar con cosas como una API simulada y servidores proxy)
• Pruebas de rendimiento
• Soporte de fibras / simultaneidad
• Informe de verificación de características (prueba con las características base de "Faraday" y produce un informe para el adaptador para mostrar cuáles son compatibles con el adaptador, útil para los usuarios que buscan uno nuevo)
• ¡Abierto para más ...!

@technoweenie incluso ha comenzado a trabajar en eso: https://github.com/technoweenie/faraday-live

Entonces, si también te apetece ayudar con eso, como recuerdo que tuviste algunas ideas interesantes sobre cómo podría funcionar, también agradeceríamos aportaciones y ayuda en ese frente 😃

También estoy feliz de ayudar donde pueda (Gracias @olleolleolle por mostrarme esto) :)

Vi https://github.com/lostisland/faraday/projects/3 - En términos de dividirlos en gemas, ¿hay planes para crear una organización faraday en GitHub para almacenar todas las gemas individuales?

@iMacTia , un cc para ti

@ MikeRogers0 lostisland, esta organización, es el hogar de faraday-http , un adaptador gemificado. ¿Quizás más de los adaptadores solo viven en esta organización?

¡Impresionante! Anoche cerré totalmente que

La semana que viene revisaré lo que se cambió para mover el adaptador Net::HTTP a una gema, luego lo duplicaré por Net::HTTP::Persistent :) Para ayudar a acelerar las cosas, comenzaré en mi cuenta personal, una vez parece que ha tomado forma. Pondré un enlace y podemos transferirlo.

Gracias @ MikeRogers0 , es maravilloso escucharlo, cualquier ayuda adicional es muy apreciada.
@grosser también está bastante bien informado sobre el adaptador Net::HTTP::Persistent habiendo contribuido a él en el pasado, así que no dude en mantenerlo informado.

En cuanto a la ubicación de los adaptadores, personalmente no me siento muy seguro de dónde deberían vivir.
Para mí tiene mucho sentido que vivan bajo una cuenta personal, si esa persona también es el mantenedor principal.
Entonces, si está satisfecho con eso, no tengo nada en contra de dejar el adaptador en su cuenta 😄

@ MikeRogers0 @julik @grosser He creado una nueva plantilla de repositorio para facilitar la creación de un nuevo adaptador: https://github.com/lostisland/faraday-adapter-template

¡Considérelo muy parecido a un WIP y no dude en enviarnos sus comentarios para mejorarlo!

@iMacTia ¡ Esa plantilla de repositorio fue muy útil!

Configuré https://github.com/MikeRogers0/faraday-net_http_persistent basándome en él. Lo configuré para transferirlo a @lostisland . ¿Quieres vistazo y asegurarte de que no me he perdido nada obvio? :)

¡Un trabajo fantástico @ MikeRogers0 🎉, y muy rápido también!
Estaba comprobando cómo funciona la transferencia del repositorio y es un poco más complicado cuando se pasa de un usuario a otro, así que si todavía está dispuesto a transferir eso a `Lostisland, ¿podría transferirme primero a mí para luego transferirlo? ¿En mi mismo? Luego te agregaré a ti y a

Además, me alegra saber que el repositorio de plantillas fue útil. Si tiene algún comentario (algo que no está claro, algo que deseaba que estuviera allí, errores tipográficos, etc.), hágamelo saber o siéntase libre de abrir un PR en su contra 😄

Los siguientes pasos serían lanzar una primera versión de la gema en Rubygems, quitar el adaptador Net::HTTP::Persistent de Faraday y conectar su nueva gema allí.
Puedo encargarme de la liberación, depende de usted si quiere hacer el intercambio de relaciones públicas contra Faraday o no ( aquí las relaciones públicas sobre cómo lo hicimos por Net::HTTP )

@iMacTia - Impresionante, se inició la transferencia :)

Además, me alegra saber que el repositorio de plantillas fue útil. Si tiene algún comentario

Agregué una acción de GitHub y reescribí el archivo Léame. Publiqué los principales cambios que hice y creo que podrían ser útiles :) También cambié Rubocop por StandardRB, lo cual me gustaría alentar.

Los siguientes pasos serían lanzar una primera versión de la gema en Rubygems, eliminar el adaptador Net :: HTTP :: Persistent de Faraday y conectar su nueva gema allí.

¡Impresionante! Me pondré a trabajar en un PR 🎉

@ MikeRogers0 @grosser repo transferido y ambos deberían haber recibido una invitación 👍
https://github.com/lostisland/faraday-net_http_persistent

@ MikeRogers0 ¡ Gracias por los comentarios 🙏!

@ MikeRogers0 faraday-net_http_persistent ya está disponible en Rubygems 🎉
https://rubygems.org/gems/faraday-net_http_persistent