Faraday: Lista de desejos de Faraday

• tornar net-http-persistent menos hacky, mantendo um objeto de conexão por perto, para que não precisemos de um cache global
• fazer net-http-persistent não usar a gema ... 90% disso está gerenciando net-http, o que já fazemos, então a única coisa que precisamos é a lógica rescue + reopen que é algumas linhas de código e removeria a lógica de acoplamento / tradução para a gema, consulte https://github.com/drbrain/net-http-persistent/pull/100
• permitir o uso de net-http-pipeline

Obrigado, essas são ótimas sugestões!

tornar net-http-persistent menos hacky, mantendo um objeto de conexão por perto, para que não precisemos de um cache global

Ah, sim, outra razão pela qual a implementação de Faraday da semântica de Rack para as classes de adaptador e middleware precisa ser eliminada. Se o adaptador atual era uma propriedade Faraday::Connection#adapter longa duração, o adaptador net-http poderia manter o objeto de conexão. Acabei de adicionar "API interna do adaptador / middleware Revisit (semântica do adaptador de rack)" à lista de desejos para oferecer suporte a isso.

faça net-http-persistent não use a gem

Eu estou a bordo Obrigado pela indicação para o PR.

permitir o uso de net-http-pipeline

Faraday suporta solicitações paralelas, mas não tenho certeza se poderíamos usar net-http-pipeline para implementá-las para net-http . Eu adicionei "Revisit pipelining ou solicitações paralelas (net-http-pipeline, typhoeus)" à lista de desejos.

Para pipeline: decidi não usar isso em meus projetos porque significa
reescrevendo a maior parte da lógica do manipulador, então baixo prio para mim

Na sexta-feira, 31 de maio de 2019 às 10:31 risco perigo olson notificaçõ[email protected]
escreveu:

Obrigado, essas são ótimas sugestões!

tornar net-http-persistent menos hacky, mantendo um objeto de conexão por perto
então não precisamos de um cache global

Ah sim, outra razão pela qual a implementação de Faraday da semântica Rack para
o adaptador e as classes de middleware precisam ir. Se o adaptador atual era
uma propriedade do adaptador Faraday :: Connection # de longa duração, o adaptador net-http
poderia reter o objeto de conexão. Acabei de adicionar "Revisitar
API interna do adaptador / middleware (descarte a semântica do adaptador Rack) "para o
lista de desejos para apoiar isso.

faça net-http-persistent não use a gem

Eu estou a bordo Obrigado pela indicação para o PR.

permitir o uso de net-http-pipeline

Faraday oferece suporte a solicitações paralelas, mas não tenho certeza se nós
poderia usar net-http-pipeline para implementá-los para net-http. eu já adicionei
"Revisitar pipelining ou solicitações paralelas (net-http-pipeline, typhoeus)" para
a lista de desejos.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/lostisland/faraday/issues/953?email_source=notifications&email_token=AAACYZ5IS7IRWR45K7IFKL3PYFOILA5CNFSM4HAAQSK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWV4EOI#issuecomment-497795641 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAACYZ6EKR7M4ARR47IAI23PYFOILANCNFSM4HAAQSKQ
.

@grosser, você deve ter ouvido que estamos agora no processo de enviar adaptadores e middleware para fora do Faraday.
Já fizemos muito trabalho para tornar isso o mais fácil possível, incluindo a exportação de testes e fornecendo alguns exemplos ( faraday-net_http faraday-http )

Eu gostaria de saber, considerando suas contribuições anteriores, se você gostaria de se apropriar de net_http_persistent.
Tudo o que você precisa fazer é isolá-lo em um repositório separado (pode estar sob seu usuário!), Como fizemos para os exemplos acima, e lançar um v1.0 que é exatamente o mesmo que o atual. Em seguida, vamos adicioná-lo à especificação de gem de Faraday para compatibilidade com versões anteriores. O plano é, então, abandonar essas dependências para Faraday v2.0

A partir daí, você está livre para alterar / refatorar como quiser e fazer todas as alterações importantes que desejar 😄
Por favor, deixe-me saber se você está interessado ou não 🙌! Também estou feliz em ajudar com a primeira migração, pois estou planejando fazer esse trabalho de qualquer maneira

parece fácil, vou tentar

Na quinta-feira, 31 de dezembro de 2020 às 4h03, Matt [email protected] escreveu:

@grosser https://github.com/grosser você deve ter ouvido que estamos agora em
o processo de envio de adaptadores e middleware para fora do Faraday.
Já fizemos muito trabalho para tornar isso o mais fácil possível,
incluindo a exportação de testes e fornecendo alguns exemplos (faraday-net_http
faraday-http)

Eu queria saber, dadas suas contribuições anteriores, se você gostaria de tomar
propriedade de net_http_persistent?
Tudo o que você precisa fazer é isolá-lo em um repositório separado (pode ser
sob seu usuário!) como fizemos para os exemplos acima, e lançar um v1.0
que é exatamente igual ao atual. Em seguida, vamos adicioná-lo ao
Faraday gem spec para compatibilidade com versões anteriores.

A partir daí, você está livre para alterar / refatorar como quiser e
fazendo todas as alterações importantes que você deseja 😄
Por favor, deixe-me saber se você está interessado ou não 🙌! Eu também estou feliz em ajudar
com a primeira migração, pois estou planejando fazer esse trabalho de qualquer maneira

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/lostisland/faraday/issues/953#issuecomment-752938926 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAACYZYOKFNQGJM5GXZQJMLSXRR73ANCNFSM4HAAQSKQ
.

@grosser Awesome! Por favor, grite se precisar de ajuda!
@julik por favor, veja meu comentário acima para @grosser , você gostaria de fazer algo semelhante para o adaptador Patron 😄?

Olá pessoal, feliz 2021! Estou bem em assumir a propriedade do adaptador Patron, o problema que encontrei ao configurá-lo foi que achei o uso de simulações nos testes compartilhados muito difícil de gerenciar (também considerando que patron de patron de webmock em alguns lugares, sem que é realmente necessário). Ao fazer a extração, descobri que também teria que me tornar um co-mantenedor das substituições do webmock do Patron - isso é uma coisa, e em vez de testar se o que precisa funcionar realmente funciona, eu testaria se funciona com Webmock. Isso é um pouco pessoal, mas um assunto relativamente difícil para 2020 para mim tem sido ter que convencer as pessoas de algumas coisas, e esgotei meu orçamento "convincente" para aquele ano. E muito cheque especial, e na verdade se tornou um risco para o meu bem-estar 😄 Eu posso ir de A para B de uma maneira muito segura e eficaz, mas a quantidade de idas e vindas que consigo lidar com isso caminho está muito mais baixo do que costumava ser. Isso também tem a ver com o fato de que faço parte de uma organização em rápido crescimento. Não estou em posição de exigir que sejam feitas concessões por isso - afinal, trata-se de problemas pessoais. Mas tenho que fazer um orçamento para meu envolvimento nas coisas.

Portanto: Se pudermos rever essa decisão (ter que usar webmock em vez de solicitações reais, que é o que os adaptadores tratam), estou bem em assumir a integração do usuário no atacado.

@julik entendeu

Disponibilizamos testes externamente para que a migração de adaptadores integrados para adaptadores externos seja o mais suave e fácil possível e, uma vez que o Faraday v1.0 ainda inclui adaptadores (mas incluídos como joias, em vez de arquivos na pasta lib), então, faz sentido usá-los como estão ao extrair o repositório para uma nova gema.

MAS É ISSO! Uma vez que a v1.0 da gem do adaptador foi criada e adicionada ao Faraday para compatibilidade com versões anteriores, como fizemos para o adaptador Net::HTTP , é aí que você pode iniciar um caminho v2.0 para a gem do adaptador e decidir O que fazer com isso.
Isso, é claro, inclui a reescrita de testes com qualquer estrutura de sua preferência e o uso de chamadas reais, se desejar.
Uma vez que a gema está na chamada "terra do usuário", não temos mais o direito de tomar as decisões e todas as decisões devem caber à comunidade e aos proprietários da gema.

E vou lhe contar mais, já estamos discutindo internamente sobre a criação de algum tipo de suíte de "testes de integração" com solicitações reais sendo feitas. Os principais recursos deste pacote seriam (todos ainda em discussão):

• Gemificado / embalado para que possa ser usado "plug-and-play" com qualquer adaptador
• Faz pedidos reais
• Suporte para contêineres docker (para ajudar com coisas como uma API simulada e servidores proxy)
• Teste de performance
• Suporte para fibras / simultaneidade
• Relatório de verificação de recursos (testa os recursos de base "Faraday" e produz um relatório para o adaptador para mostrar quais são suportados pelo adaptador, útil para usuários que estão procurando por um novo)
• Abra para mais ...!

@technoweenie até começou a trabalhar nisso: https://github.com/technoweenie/faraday-live

Então, se você gostaria de ajudar com isso também, como eu me lembro que você teve algumas idéias legais sobre como isso poderia funcionar, nós também gostaríamos de receber sugestões e ajudar nessa frente 😃

Também estou feliz em ajudar onde posso (Obrigado @olleolleolle por me mostrar isso) :)

Eu vi https://github.com/lostisland/faraday/projects/3 - Em termos de dividir isso em joias, há planos de criar uma organização faraday no GitHub para armazenar todas as joias individuais?

@iMacTia , um cc para você

@ MikeRogers0 lostisland , esta organização, é o lar do faraday-http , um adaptador gemificado. Talvez mais adaptadores vivam apenas nesta organização?

Incrível! Eu totalmente em branco ontem à noite que @lostisland era uma conta de organização :) Acho que colocá-los na organização é minha preferência.

Na próxima semana, verificarei o que foi alterado para mover o adaptador Net::HTTP para uma gema e, em seguida, duplicar para Net::HTTP::Persistent :) Para ajudar a agilizar as coisas, começarei na minha conta pessoal, uma vez parece que já tomou forma, colocarei um link e podemos transferi-lo.

Obrigado @ MikeRogers0 , é maravilhoso ouvir isso, qualquer ajuda extra é muito apreciada.
@grosser também conhece bastante o adaptador Net::HTTP::Persistent tendo contribuído para ele no passado, portanto, fique à vontade para mantê-lo informado.

Quanto à localização dos adaptadores, pessoalmente não tenho muita certeza de onde eles deveriam morar.
Para mim, faz todo o sentido que eles vivam sob a conta pessoal de uma pessoa, se essa pessoa também for o mantenedor principal.
Então, se você está feliz com isso, não tenho nada contra deixar o adaptador sob sua conta 😄

@ MikeRogers0 @julik @grosser Eu criei um novo https://github.com/lostisland/faraday-adapter-template

Considere isso como um WIP e sinta-se à vontade para fornecer comentários para melhorá-lo!

@iMacTia Esse

Eu configurei https://github.com/MikeRogers0/faraday-net_http_persistent com base nele - eu configurei para ser transferido para @lostisland - Você quer ver e ter certeza de que não perdi nada óbvio? :)

Trabalho fantástico @ MikeRogers0 🎉, e muito rápido também!
Eu estava verificando como a transferência de repositório funciona e é um pouco mais complicado quando vai de usuário para organização, então se você ainda estiver disposto a transferir isso para `lostisland, poderia por favor transferir para mim primeiro, então eu irei transferi-lo em mim mesmo? Vou então adicionar você e @grosser como mantenedores desse repositório 👍

Além disso, fico feliz em saber que o repositório de modelos foi útil! Se você tiver algum feedback (algo confuso, algo que você gostaria que estivesse lá, erros de digitação, etc ...), me avise ou sinta-se à vontade para abrir um PR contra isso 😄

Os próximos passos seriam lançar uma primeira versão da gema no Rubygems, remover o adaptador Net::HTTP::Persistent de Faraday e conectar sua nova gema lá.
Posso cuidar do lançamento, até você decidir se deseja fazer a troca de PR contra Faraday ou não ( aqui o PR sobre como fizemos isso por Net::HTTP )

@iMacTia - Ótimo, transferência iniciada :)

Além disso, fico feliz em saber que o repositório de modelos foi útil! Se você tiver algum feedback

Eu adicionei uma ação do GitHub e reescrevi o Readme. Eu fiz RP das principais mudanças que eu acho que podem ser úteis :) Eu também troquei o Rubocop por StandardRB, que eu gostaria de encorajar.

Os próximos passos seriam lançar uma primeira versão da gema no Rubygems, remover o adaptador Net :: HTTP :: Persistent de Faraday e conectar sua nova gema lá.

Incrível! Vou trabalhar em um PR 🎉

@ MikeRogers0 @grosser repo transferido e vocês dois deveriam ter recebido um convite 👍
https://github.com/lostisland/faraday-net_http_persistent

@ MikeRogers0 obrigado pelo feedback 🙏!

@ MikeRogers0 faraday-net_http_persistent agora está disponível no Rubygems 🎉
https://rubygems.org/gems/faraday-net_http_persistent