关于对现有项目中的小小看法

写在前面的话:

4G网络的情况下,使用爱你城APP加载内容时间长。简单分析了一下主要的原因是由于接口响应时间导致。目前公司使用的接口开发技术是GraphQL,它最大的优点是大大提高团队的开发效率。我一直认为任何技术都有利有弊,能正确认识一门技术的缺点并尽量规避它,才算真正掌握一门技术。GraphQL的的缺点是容易导致N+1的问题,关于什么是N+1问题,请在本站内搜索。本文只是以GraphQL优化做为一个引子,目的是引出下文。欢迎大家讨论。

关于GraphQL

由于公司代码涉及隐私,我贴几段与实际业务关联不大的代码:

image.png

上图是ArticlesQuery.php查询返回ArticlesType的代码片段。ArticlesQuery.php作用是查询文章列表,由于文章与评论是一对多的关系。在没有做任何优化的处理的情况下,默认执行的SQL语句次数与comment成正比。如果需要查询更多数据或层级关系比较多,SQL请求次数将会成倍增加。又回到了N+1的问题。查阅了GraphQL文档后总结出下面的解决方案:

image.png

另外,Laravel操作数据库有好几种方式,最常用的就是Model操作与DB。如果在这里使用DB也是一个很好的选择,因为SQL语句直接高效。但是同样也带来了另外一个问题就是如果接近原生的SQL语句一旦变多了,后面代码维护起来困难。综上所述根据具体的情况灵活使用,如果逻辑变动不大可以考虑使用DB直接操作数据库。

关于代码结构

痛点:随着系统功能的不断加入,多人维护加上平时小需求的快速开发,有一些代码冗余。这样的状况下影响开发效率,并对系统稳定性造成一定的影响。解决方案是将散落的代码统一维护,一方面进一步提高代码的质量,另一方面由于核心功能的相对稳定性(测试用例其实只是一个辅助工具),修改发布的次数相对来说会减少,这也与敏捷软件开发的方式相符。

现阶段的主要问题是ApiController,Controller,GraphQL三个地方的逻辑冗余比较大。假设公司新招入一个员工,如果对项目的整体结构不是很熟悉,改动了Controller却忘记改动GraphQL中类似的逻辑,数据不一致就产生了。现在我们采用的方式是将公用的逻辑提取到Model中去处理,同时以Laravel自带的事件监听机制为辅。案例如下:

Controller中代码如下:

image.png

GraphQL API中代码如下:

image.png

Model抽取如下:

image.png

上面初步解决了代码冗余的问题。网站经常出现数据不一致的问题,在此处通过事件监听的机制,类似数据库触发器,维护冗余数据,中间表的关系。 但是还存在几个问题:1.代码的耦合性较强,Controller中出现了new关键字。解决方式是通过依赖注入。 2.共用逻辑提取后,导致Model类过长。可以考虑增加一个中间层(服务层),服务层主要负责业务逻辑的处理,Model只存模型关系。它们之间通过依赖注入容器维护关系。

关于缓存

网站的缓存存放在文件缓存中。其中首页置顶,头像缓存。这两个缓存命中率特别高,由于是文件缓存。一定程度上减少了数据库的压力,但是设计了文件I/O。对首页响应的时间造成一定的影响。如果数据量大,频繁的文件I/O,将会严重影响网站的响应速度。公司现阶段,性能不是首要的考虑的因素,开发效率才是最重要。做个记录在这方面以后优化网站。

分享几个简单的函数

1.optional函数的使用

有时候你会遇到下面的报错:

image.png

由于存在某个对象为空,所以我们调用方法或获取属性会出现上面的错误

比如我们想要获取评论所属文章的标题,可能会像下面一样访问:

image.png

但是如果comment对应的article为空,就会出现上面提到的错误了。如果像下面一样使用

image.png

就不会报错了,而是显示一个空字符串。

2.select函数:

假设系统表某一个表中有LongText或Text类型的字段,他们的特点都是占用的空间比较大。有时候API查询根本使用不上该字段,我们可以通过select来精确获取我们需要的字段,减少网络带宽。

日记本

如果觉得我的文章对您有用,请随意赞赏。您的支持将鼓励我继续创作!

赞赏支持
被以下专题收入,发现更多相似内容