我想开始收集我们想要在法拉第改变什么的愿望清单。 这里还没有具体的东西。
lib/faraday/params_encoders/[nested, flat]
?Faraday::Utils
Faraday::Connection
=> Faraday::Client
#response
属性一致 [#1284]Faraday::Connection
和Faraday::RackBuilder
关系use
/ adapter
/etc 委托Faraday::RackBuilder#handlers
=> Faraday::Connection#handlers
lib/faraday/middleware/*
rescue + reopen
逻辑,它是几行代码和将删除 gem 的耦合/翻译逻辑,请参阅https://github.com/drbrain/net-http-persistent/pull/100谢谢,这些都是很好的建议!
通过保留连接对象来减少 net-http-persistent 的麻烦,这样我们就不需要全局缓存
是的,法拉第为适配器和中间件类实现 Rack 语义的另一个原因需要去。 如果当前适配器是长期存在的Faraday::Connection#adapter
属性,则net-http
适配器可以保留连接对象。 我刚刚在愿望清单中添加了“重新访问适配器/中间件内部 API(丢弃机架适配器语义)”以支持这一点。
使 net-http-persistent 不使用 gem
我在船上。 感谢您指向 PR 的指针。
允许使用 net-http-pipeline
Faraday 确实支持并行请求,但我不确定我们是否可以使用net-http-pipeline
为net-http
实现它们。 我在愿望清单中添加了“重新访问流水线或并行请求(net-http-pipeline,typhoeus)”。
对于管道:我决定不在我的项目中使用它,因为这意味着
重写大部分处理程序逻辑,对我来说太低了
2019 年 5 月 31 日星期五上午 10:31 风险危险 olson [email protected]
写道:
谢谢,这些都是很好的建议!
通过保持连接对象来减少 net-http-persistent
所以我们不需要全局缓存是的,法拉第实现 Rack 语义的另一个原因是
适配器和中间件类需要去。 如果当前的适配器是
一个长期存在的 Faraday::Connection#adapter 属性,net-http 适配器
可以保持连接对象。 我刚刚添加了“重新访问
适配器/中间件内部 API(删除机架适配器语义)”到
支持这一点的愿望清单。使 net-http-persistent 不使用 gem
我在船上。 感谢您指向 PR 的指针。
允许使用 net-http-pipeline
Faraday 确实支持并行请求,但我不确定我们是否可以
可以使用 net-http-pipeline 为 net-http 实现它们。 我已经添加
“重新访问流水线或并行请求(net-http-pipeline,typhoeus)”到
心愿单。—
您收到此消息是因为您发表了评论。
直接回复本邮件,在GitHub上查看
https://github.com/lostisland/faraday/issues/953?email_source=notifications&email_token=AAACYZ5IS7IRWR45K7IFKL3PYFOILA5CNFSM4HAAQSK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWV4EOI#issuecomment-497795641 ,
或静音线程
https://github.com/notifications/unsubscribe-auth/AAACYZ6EKR7M4ARR47IAI23PYFOILANCNFSM4HAAQSKQ
.
@grosser您可能听说过我们现在正在将适配器和中间件推出 Faraday。
我们已经做了很多工作来使这尽可能简单,包括导出测试并提供一些示例( faraday-net_http faraday -http )
我想知道,鉴于您过去的贡献,您是否想拥有 net_http_persistent 的所有权?
您需要做的就是将它隔离到一个单独的存储库中(这可以在您的用户之下!),就像我们在上面的示例中所做的那样,并发布一个与当前版本完全相同的 v1.0。 然后,我们会将其添加到 Faraday gem 规范中以实现向后兼容性。 然后计划是为 Faraday v2.0 删除这些依赖项
从那里,您可以自由地更改/重构它以满足您的内心需求,并进行您想要的所有重大更改 😄
请让我知道您是否有兴趣🙌! 我也很乐意帮助进行第一次迁移,因为无论如何我都打算做这项工作
听起来很简单,我会试试
2020 年 12 月 31 日星期四上午 4:03,Matt [email protected]写道:
@grosser https://github.com/grosser你可能听说过我们现在在
将适配器和中间件推出法拉第的过程。
我们已经做了很多工作来使这尽可能简单,
包括导出测试并提供一些示例(faraday-net_http
法拉第-http)我想知道,鉴于您过去的贡献,您是否愿意接受
net_http_persistent 的所有权?
您需要做的就是将它隔离到一个单独的存储库中(这可以是
在您的用户下!)就像我们在上面的例子中所做的那样,并发布一个 v1.0
这与当前的完全相同。 然后我们将它添加到
Faraday gem 规范向后兼容。从那里,您可以自由地更改/重构它以满足您的内心需求,并且
做出你想要的所有重大改变😄
请让我知道您是否有兴趣🙌! 我也很乐意帮忙
第一次迁移,因为我无论如何都打算做这项工作—
你收到这个是因为你被提到了。
直接回复本邮件,在GitHub上查看
https://github.com/lostisland/faraday/issues/953#issuecomment-752938926 ,
或取消订阅
https://github.com/notifications/unsubscribe-auth/AAACYZYOKFNQGJM5GXZQJMLSXRR73ANCNFSM4HAAQSKQ
.
@grosser 太棒了! 如果您需要任何帮助,请大声喊叫!
@julik请看我上面对 @grosser 的评论,你想为Patron
适配器做一些类似的事情吗?
嘿伙计们,2021 年快乐! 我很好地拥有 Patron 适配器,但我在设置它时遇到的问题是我发现在共享测试中使用模拟非常难以管理(也考虑到 webmock 在几个地方修补了 Patron,没有这确实被要求)。 在进行提取时,我偶然发现了这样一个事实,即我还必须成为 Patron webmock 覆盖的共同维护者 - 这是一回事,而不是测试需要工作的东西是否真的有效,我将测试是否它适用于 Webmock。 这有点个人化,但对我来说 2020 年的一个相对困难的主题是必须说服人们相信事情,并且我用完了那一年的“令人信服”的预算。 并且严重透支,这实际上对我的健康构成了一些风险😄我可以以非常安全有效的方式从 A 到 B,但是我可以处理的来回数量路径比以前低得多。 这也与我是一个经历快速增长的组织的一部分有关。 我不能要求为此做出让步——毕竟这是我的个人问题。 但我必须预算我参与的事情。
所以:如果我们可以重新考虑那个决定(必须使用 webmock 而不是实际请求,这就是适配器的内容)我很好地获得了赞助人集成的所有权。
@julik完全明白你的意思! 我记得我们过去已经讨论过引入 Webmock 的主要原因,不得不处理 8 个不同的适配器绝对是其中之一!
我们已经在外部提供了测试,以便从捆绑到外部适配器的迁移尽可能顺利和容易,而且由于 Faraday v1.0 仍将捆绑适配器(但作为 gems 包含,而不是 lib 文件夹中的文件),那么在将 repo 提取到新 gem 时按原样使用它们是有意义的。
但就是这样! 一旦创建了适配器 gem 的 v1.0 并将其添加到 Faraday 以实现向后兼容性,就像我们为Net::HTTP
适配器所做的那样,您就可以在此处启动适配器 gem 的 v2.0 路径并决定怎么办。
当然,这包括使用您喜欢的任何框架重写测试并使用实际调用,如果您愿意的话。
一旦宝石进入所谓的“用户土地”,我们绝对没有权利再做主,所有的决定都应该由社区和宝石所有者决定。
我会告诉你更多,我们已经在内部讨论关于创建某种“集成测试”套件和实际请求。 该套件的主要功能将是(所有仍在讨论中):
@technoweenie甚至已经开始研究: https :
所以,如果你也想帮忙解决这个问题,我记得你有一些关于如何运作的很酷的想法,我们也欢迎在这方面提供意见和帮助😃
我也很乐意提供帮助(谢谢@olleolleolle向我展示这个):)
我看到了https://github.com/lostisland/faraday/projects/3 - 就将这些拆分为 gem 而言,是否有计划在 GitHub 上创建一个法拉第组织来存储所有单独的 gem?
@iMacTia ,给你一个抄送
@MikeRogers0 lostisland,这个组织,是 faraday -http的所在地,一个 gemified 适配器。 也许更多的适配器只存在于这个组织中?
惊人的! 昨晚我完全不知道@lostisland是一个组织帐户:) 我认为将它们放在组织中是我的偏好。
下周我将查看更改以将Net::HTTP
适配器移动到 gem 中,然后复制Net::HTTP::Persistent
:) 为帮助加快处理速度,我将在我的个人帐户中开始,一次看起来它已经成型了,我会放一个链接,我们可以转移它。
谢谢@MikeRogers0 ,很高兴听到,非常感谢任何额外的帮助。
@grosser对Net::HTTP::Persistent
适配器也非常了解过去曾为此做出贡献,因此请随时让他了解情况。
至于适配器的位置,我个人对它们应该住在哪里没有强烈的感觉。
如果那个人也是主要的维护者,那么让他们生活在一个人的个人帐户下对我来说是非常有意义的。
因此,如果您对此感到满意,我不反对将适配器留在您的帐户下 😄
@MikeRogers0 @julik @grosser我创建了一个新的模板存储库,以便更轻松地创建新的适配器: https :
请将此视为 WIP,并随时提供任何反馈以改进它!
@iMacTia那个模板
我基于它设置了 https://github.com/MikeRogers0/faraday-net_http_persistent - 我确实将它设置为转移到@lostisland - 你想关注它并确保我没有遗漏任何明显的东西吗? :)
很棒的工作
我正在检查存储库转移是如何工作的,从用户到组织时它有点复杂,所以如果你仍然愿意将它转移到'lostisland,你能不能先把它转移给我,然后我会转移它在我自己? 然后我会将您和@grosser添加为该 repo 的维护者👍
另外,很高兴听到模板回购很有帮助! 如果您有任何反馈(任何不清楚的地方,您希望在其中的任何内容,错别字等...)请告诉我或随时针对它打开公关😄
接下来的步骤是将 gem 的第一个版本发布到 Rubygems,从 Faraday 中移除Net::HTTP::Persistent
适配器并将您的新 gem 插入那里。
我可以负责发布,取决于你是否想对法拉第做交换公关(这里是关于我们如何为Net::HTTP
做到这一点的公关)
@iMacTia -
另外,很高兴听到模板回购很有帮助! 如果您有任何反馈
我确实添加了一个 GitHub Action 并重写了自述文件。 我公关了我所做的我认为可能有用
接下来的步骤是将 gem 的第一个版本发布到 Rubygems 中,从 Faraday 中删除 Net::HTTP::Persistent 适配器并将您的新 gem 插入那里。
惊人的! 我会开始做 PR 🎉
@MikeRogers0 @grosser repo 转移了,你们应该都收到了邀请👍
https://github.com/lostisland/faraday-net_http_persistent
@MikeRogers0感谢您的反馈🙏!
@MikeRogers0 faraday-net_http_persistent
现已在 Rubygems 上可用 🎉
https://rubygems.org/gems/faraday-net_http_persistent
最有用的评论
惊人的! 昨晚我完全不知道@lostisland是一个组织帐户:) 我认为将它们放在组织中是我的偏好。
下周我将查看更改以将
Net::HTTP
适配器移动到 gem 中,然后复制Net::HTTP::Persistent
:) 为帮助加快处理速度,我将在我的个人帐户中开始,一次看起来它已经成型了,我会放一个链接,我们可以转移它。