inhere commented 5 years ago

swoft 2.0 开发意见收集

鉴于1.0的规划过于庞大，一些组件其实很少人使用，开发团队感觉维护困难。

决定开发2.0:

全协程化: swoole 4.3+, php 7.1+
重心调整：核心团队首先专注基础框架和核心组件的开发维护
其他组件的重心放低，鼓励社区和感兴趣的人开发维护
有更充足的时间编写单元测试和相关文档

这里做一些意见收集

那些是你认为的核心组件？
在使用中有哪些不足或者没有你希望的效果？
对一些核心功能，希望怎么改进？或有什么建议？

去除的功能：

auto reload 极大的增加了框架启动逻辑复杂度
defer(getResult) 很少人使用
框架核心，不再提供服务注册和发现这一套（待定）。
不再提供redis 前缀支持
不再提供定时任务(分布式任务系统扩展)
不再提供session支持

需改进的功能：

注解扫描将会重构
改进和简化组件的注册
验证将会重构，简化使用 (@jqcool )
路由将会改进: 支持命名路由
关于开发时自动重启：提供一个 swoft-cli 它来监控项目变动，发送重启信号
数据库ORM大体会和laravel使用一样
rpc 协议支持适配器，默认提供 jsonrpc 适配器,用户可以根据接口实现自己需要的协议 (@herojhc )
config 支持常用的配置格式(yaml json)
bean的注册和收集将会做一些调整
- 增加支持别名
- 数组方式配置支持添加bean选项（支持别名，作用域设置）
提供测试辅助工具库更方便编写单元测试
异常处理优化

新增的功能：

进程池的封装
迁移脚本

inhere commented 5 years ago

2.0 目标

全协程，核心化，易扩展，简洁易用。
支持swoole 4.3+, php 7.1+(推荐7.2)
> 90% 的单元测试覆盖率
更丰富的demo和文档说明(😄 需要各位的支持啊)

核心组件

swoft的基础核心，后续的扩展都是基于它们的稳定和扩展性

注解
AOP
事件
Log
Console/Command
TCP/UDP server(后面几个的基础，只是基于swoole的做一点简单封装)
HTTP server(路由，中间件)
WebSocket server
RPC server
Database/ORM（将会尽量参考laravel的使用方式）

第二阶梯组件

第二阶梯的功能组件，主要是为了增强swoft的易用性和应用性，提供更完善的功能支持

View
Pool
Task
cronTab 定时任务
服务注册发现
Cache
Redis
Queue 队列
MongoDB 支持

周边工具

swoft-cli 独立的工具
- 创建新的骨架项目
- 各种类文件生成
- 监控项目文件并重启server
- 组件搜索
- 更多 ...
devtool 专注应用运行信息收集
- 注册的路由
- 注册的组件
- 应用配置信息
- 更多 ...
提供测试辅助工具库更方便编写单元测试

参与贡献

后面 swoft 组织里还是会有很多的项目。

核心功能，开发组的主要精力会放在它们的维护更新，打好基础
第二阶段的组件，有很大的用户需要使用。我们也会开发和维护，但不作为核心组件，算是功能组件
另一些由感兴趣和需要的人维护 😄 鼓励和欢迎各位贡献和加入

关注2.0进度

https://github.com/swoft-cloud/swoft-component/blob/2.0/CHANGELOG.md

dusong0717 commented 5 years ago

mongodb 驱动支持，消息队列支持：kafka、rabbitmq、beanstalk等另外demo希望更加完善一些，便于上手开发降低学习成本。

inhere commented 5 years ago

mongodb 驱动支持，消息队列支持：kafka、rabbitmq、beanstalk等另外demo希望更加完善一些，便于上手开发降低学习成本。

mongodb 后面也会支持
消息队列也将在第二阶段做

jqcool commented 5 years ago

建议完善中间件，可参考下laravel的，路由可设定参数，中间件可获取优化验证机制，现有的验证感觉好鸡肋，开发效率相当的低

deepziyu commented 5 years ago

土壤原因，我觉得成为 spring-cloud 那样的生态是不现实的，倒是能做成 sf 那样， sf 体现了自己对php-fpm 的理解，所写出的组件成了很多现代框架的一砖一瓦。我觉得 swoft 对 swoole-cli 的理解是最深的，应能能做出这样的贡献。

luguohua0394 commented 5 years ago

希望整合laravel的orm系统

stelin commented 5 years ago

@deepziyu 是的，我们也意识到这个问题，所以重构2.0

jqcool commented 5 years ago

土壤原因，我觉得成为 spring-cloud 那样的生态是不现实的，

这个很有道理，php的特性就是方便快捷，spring-cloud的生态不适phper，适合java转型的

inhere commented 5 years ago

建议完善中间件，可参考下laravel的，路由可设定参数，中间件可获取优化验证机制，现有的验证感觉好鸡肋，开发效率相当的低

这个是支持的 路由可设定参数，中间件可获取
验证之前做的很匆忙，这次会重新调整

stelin commented 5 years ago

@191834552 我们计划也是兼容laravel的orm使用方式，但是有点小改动，整体使用一样。

deepziyu commented 5 years ago

希望整合laravel的orm系统

接上面的论述，我觉得这些整合这个，整个那个不应当是重点，不应当耗费开发组的精力

stelin commented 5 years ago

@deepziyu 不是整合，我们ORM使用方式，大体会和laravel一样

no-serve-people commented 5 years ago

很有道理，就是orm这个核心组件参照laravel。还是很强大的，比yii2的都强大

herojhc commented 5 years ago

希望把RPC server 完善下，尤其是错误处理。

yemaozi999 commented 5 years ago

demo希望更加完善一些，便于上手开发降低学习成本。

manaphp commented 5 years ago

manaphp的ORM更强大，使用Query与Model兼容mongodb与sql

chenjing0521 commented 5 years ago

希望文档能完善一些最好把你们自己写的测试demo发一套代码出来

inhere commented 5 years ago

希望文档能完善一些最好把你们自己写的测试demo发一套代码出来

@chenjing0521

现在 swoft 项目就是一个完整的demo 我们的测试也是用的它，还有些功能测试代码就在各个组件的 test 目录下

jqhph commented 5 years ago

服务注册和发现希望能继续支持并完善。php微服务化还不成熟，大多数phper对rpc也不熟悉，如果仅仅只提供rpc的server和client的通讯功能，那想使用rpc就会困难很多了。rpc通讯很多框架早就提供了，这一块并不是难点，如果swoft能提供一套稳定完善的rpc微服务解决方案，那才是优势所在。

另外希望增加以下rpc service的exception handler支持。

jqhph commented 5 years ago

易扩展和简洁易用在1.0就做得不是很好，我觉得最主要是体现在bean容器，orm和扩展swoft组件上，希望2.0能着重优化下。 swoft bean容器是在服务启动之时就注入好的，但是这么做就有个坑爹的地方了：如果我是需要在服务启动之时做一些操作，就会发现有些bean容器里面的对象（包括官方的和自定义的）用不了！！而且通过数组方式注册服务到bean容器的时候是强制使用单例的！而且注册服务到bean容器不能像laravel那样在注册之时带一些逻辑。还有就是custom.component这个功能有问题，配置了注解文件的命名空间也不一定能扫描到