refactor: refactor http middleware

[devhaozi]

📑 Description

Closes goravel/goravel#655

✅ Checks

• Added test cases for my code

[Copilot]

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

session/middleware/start_session_test.go:26

• Ensure that converting 'next' using http.ConvertHandler is necessary in the test context; verify that this conversion produces the expected Goravel http.Handler instance to maintain middleware chain integrity.

StartSession()(http.ConvertHandler(next)).ServeHTTP(NewTestContext(r.Context(), next, w, r))

[codecov]

Codecov Report

Attention: Patch coverage is 62.50000% with 42 lines in your changes missing coverage. Please review.

Project coverage is 70.38%. Comparing base (b493bc4) to head (130062e).
Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
http/middleware/throttle.go	0.00%	24 Missing ⚠️
session/middleware/start_session.go	66.66%	10 Missing and 4 partials ⚠️
http/limit/limit.go	0.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #996      +/-   ##
==========================================
+ Coverage   70.18%   70.38%   +0.19%     
==========================================
  Files         168      171       +3     
  Lines       11428    11488      +60     
==========================================
+ Hits         8021     8086      +65     
+ Misses       3056     3051       -5     
  Partials      351      351              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[devhaozi]

接goravel/goravel#655 (comment)

因为之前忘了哪个版本开始，应该是v1.12或者v1.13，控制台中返回响应都需要return ctx.Response().XXX()，然后路由驱动那边的包装函数会调用一下Render()以实际返回响应，这就导致在中间件里面如果没有对下一级调用Render()，就拿不到响应。

[hwbrzzl]

接goravel/goravel#655 (comment)

因为之前忘了哪个版本开始，应该是v1.12或者v1.13，控制台中返回响应都需要return ctx.Response().XXX()，然后路由驱动那边的包装函数会调用一下Render()以实际返回响应，这就导致在中间件里面如果没有对下一级调用Render()，就拿不到响应。

可否在这个PR的具体代码上添加评论？我们可以针对具体代码进行讨论。

[devhaozi]

Abort相关的方法和Next都去掉了，现在在中间件中想中断请求直接返回Response不返回next.ServeHTTP就行了。

另外ServeHTTP这个名字是 go 标准库的，感觉不怎么好听，有必要换一个吗？

[devhaozi]

fiber 驱动的适配在 goravel/fiber#166 完成，通过全部测试，gin 我近期应该没空处理了，等其他人来吧。

[hwbrzzl]

Thanks, checking, and FYI: PR can be merged when all drivers are ready to avoid break merging.

[hwbrzzl]

Awesome PR 👍 I think the essence of this PR is to implement the middleware logic by ourselves. There are a lot of break changes, I need more time to check it and will provide feedback later.

[hwbrzzl]

One question: If we just want to remove the Render function, is it necessary to refactor the middleware feature entirely? Are there any benefits?

[devhaozi]

One question: If we just want to remove the Render function, is it necessary to refactor the middleware feature entirely? Are there any benefits?

使用 next 控制中间件更接近 Laravel，见 https://laravel.com/docs/12.x/middleware#main-content
同时可以解决之前遗留的一些历史问题，比如中间件中不好修改响应。

[hwbrzzl]

One question: If we just want to remove the Render function, is it necessary to refactor the middleware feature entirely? Are there any benefits?

使用 next 控制中间件更接近 Laravel，见 https://laravel.com/docs/12.x/middleware#main-content 同时可以解决之前遗留的一些历史问题，比如中间件中不好修改响应。

目前的实现的确更优雅一些。抛开 Render 方法的修改，目前其他的逻辑好像对于在中间件中修改响应没有促进作用？同样需要去操作 gin 或 fiber 的 ctx。

[devhaozi]

目前的实现的确更优雅一些。抛开 Render 方法的修改，目前其他的逻辑好像对于在中间件中修改响应没有促进作用？同样需要去操作 gin 或 fiber 的 ctx。

包括中断请求，修改过的实现也更加优雅

[devhaozi]

目前的实现的确更优雅一些。抛开 Render 方法的修改，目前其他的逻辑好像对于在中间件中修改响应没有促进作用？同样需要去操作 gin 或 fiber 的 ctx。

包括中断请求，修改过的实现也更加优雅

另外如果想和 Laravel 更接近的话可以改成这样，感觉如何？

[devhaozi]

另外如果想和 Laravel 更接近的话可以改成这样，感觉如何？

好像不太行，这样的话链不起来

[hwbrzzl]

抛开 Render 方法的修改，目前其他的逻辑好像对于在中间件中修改响应没有促进作用？同样需要去操作 gin 或 fiber 的 ctx。

单从这个功能来看，修改前后是否有优化呢？目前我的主要想法是：

1. 本次修改后能否达成我们的原始诉求：中间件中能够方便操作 response；
2. 本次修改的 break-changes 太多，用户升级很麻烦，如何能够优化用户升级过程；
3. 本次修改实现的最终效果是框架自己实现 middleware 逻辑，弃用 gin/fiber 自带的 middleware，洋葱模型是一个不错的方案。但如果想实现 1.2 两点，其可以不是我们唯一的选择，如果有其他更适合我们的方案的话；

[devhaozi]

单从这个功能来看，修改前后是否有优化呢？目前我的主要想法是：

1. 本次修改后能否达成我们的原始诉求：中间件中能够方便操作 response；
2. 本次修改的 break-changes 太多，用户升级很麻烦，如何能够优化用户升级过程；
3. 本次修改实现的最终效果是框架自己实现 middleware 逻辑，弃用 gin/fiber 自带的 middleware，洋葱模型是一个不错的方案。但如果想实现 1.2 两点，其可以不是我们唯一的选择，如果有其他更适合我们的方案的话；

这个PR更多算是对逻辑的优化，不需要那么多的Abort，也更接近laravel的实现。

目前看想在gin或者fiber里面直接实现像laravel那种修改不太可能或者说很麻烦，laravel是把响应留到洋葱的最后才发送给客户端，但是gin，fiber这些都是一调用对应的方法就发送了，但是如果盲目全部加一个Writer缓存起来的话，又会丢失SSE，Stream之类的特殊功能，比较头大。

升级过程我认为不算麻烦，一个项目中间件应该不会超过20个，升级一个预计用时不到1分钟。

@almas1992 有木有其他建议？

[almas1992]

单从这个功能来看，修改前后是否有优化呢？目前我的主要想法是：

1. 本次修改后能否达成我们的原始诉求：中间件中能够方便操作 response；
2. 本次修改的 break-changes 太多，用户升级很麻烦，如何能够优化用户升级过程；
3. 本次修改实现的最终效果是框架自己实现 middleware 逻辑，弃用 gin/fiber 自带的 middleware，洋葱模型是一个不错的方案。但如果想实现 1.2 两点，其可以不是我们唯一的选择，如果有其他更适合我们的方案的话；

这个PR更多算是对逻辑的优化，不需要那么多的Abort，也更接近laravel的实现。

目前看想在gin或者fiber里面直接实现像laravel那种修改不太可能或者说很麻烦，laravel是把响应留到洋葱的最后才发送给客户端，但是gin，fiber这些都是一调用对应的方法就发送了，但是如果盲目全部加一个Writer缓存起来的话，又会丢失SSE，Stream之类的特殊功能，比较头大。

升级过程我认为不算麻烦，一个项目中间件应该不会超过20个，升级一个预计用时不到1分钟。

@almas1992 有木有其他建议？

type Response = error 虽然在一定程度上避免了升级后需要调整所有 controller 函数的成本，但总觉得这种做法有些别扭。不过考虑到当前基于 Gin 和 Fiber 的框架结构，确实没有太理想的方式去优雅实现类似 Laravel 的响应处理逻辑，受限比较大。

如果未来有计划脱离 Gin/Fiber，自行实现框架的路由系统，建议将这类逻辑的重构放到自研路由层中处理，可能会更自然，也更容易扩展。

[devhaozi]

短期内很难完美处理，暂时先关闭了

[hwbrzzl]

Thanks, 虽然暂时关闭，但提供了很好的思路，未来优化时候再打开。 👍