Skip to content

Instantly share code, notes, and snippets.

@abearxiong
Created May 9, 2022 17:06
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save abearxiong/532f5e5721691a190d97e8f7f442158f to your computer and use it in GitHub Desktop.
Save abearxiong/532f5e5721691a190d97e8f7f442158f to your computer and use it in GitHub Desktop.
关于前端工程化,开发提效的思考?

问题:随着项目变大,开发可能变得越来越复杂,例如运行或打包速度,有什么好的优化经历过好的方法?

想法

当前

未来一定是可视化编程的方向,前端变得无论多复杂,理应都应该是属于前端,意思就是仅仅只是展示页面的功能。
那么变大的过程,就属于开发的代码足够多,自然会有运行和打包速度的问题,那么直接解决方法就是分组件,分模块。

无论是开发代码还是运行代码,都应该是按需加载,缓存加载,空闲时间加载。

因为按需加载,接触webpack比较多,所以研究了下webpack的feduration,动态加载,微应用开发,应该能解决问题。

但是对于以后,我有其他的思考方向。

未来

回到可视化编程的方向,我认为低代码和无代码是未来趋势,项目变大,应该是有很多可视化的模块组合成了更多的功能,
并放大,核心不在开发代码,自然不会有打包速度问题。

但是当前的低代码和无代码架构核心大都核心点都是处于老的一套行为模式迁移过来的,很像很老前的Dreamweaver, 是以网站设计软件上云了,然后保存对应的json配置,得到最终的结果,在渲染的过程当中得到具体的内容。

这一套体系包含的模块太属于定制化了。

无代码应该是一套体系的架构模式,有一套基建的模式,他应该分为三个基建模块

  • 一个是前端的展示的模块
  • 二是连通后端的中间函数模块
  • 三是数据层的取用模块

每一个模块都有很多囊括的内容。但是这三者有原则,三者都可以单独存在,用另一个名字说,可视化面板,无服务器云函数,
数据中台。但是当前我并没有看到一款产品可以揉和这一切合并起来。每一个模块都具有很大的扩展性,这无代码的架构需要
打通他们当中所有的隔阂,并实际是面向所有人。

目标是开发一次,组合n次,形成无数个页面。

对于后台的模块,我研究过tcb和serverless,但是整个模式架构都是to b的模式的。但是可视化应该是to c的。

无绝对无代码应该是to c的一个生态,可以每一个普通人可以开发,高级的人可以做成to b的应用。

然后我的最终结论是,无代码的架构体系应该是大的生态环境,包含前端开发,组合,后端应用,数据处理,触发应用,升级。

当前的所有的相关产品,感觉方向不一致或者就是做的不够好。

前端的模块-架构

前端的模块,是执行某一个文档。在执行前最终目的是生成一个文档,对于可视化来说,新的方向。

  • 第一种是提前生成(开发打包部署),webpack federation微应用模块动态加载模式。
  • 第二种是json转对应的可视化内容,运行时候编译,【其中也有json直接编译出结果导出运行】。

第一种就是对当前前端开发模式的优化,这个federation框架的作用是就是微模块,可以跑不同的前端框架的代码。
他问题在于,他的所有开发模式是本地开发,然后部署后运行。

第二种是处于一个发展过程,汇编-->高级语言-->自然语言。未来自然语言是一定可以运行程序的。当前是属于高级语言,
可视化就是制定了一个前端开发规范,这个规范在特定的框架的运行环境下渲染出了一个页面。

在这个编辑页面的过程当中,可视化的方式,拖动,编辑,选择都是一个生成json的手段,已经是人为定义好的一个规则了。

前端的开发编译模式-架构

需要有编译的原因,无论如何开发和扩展,组件和应用是一定不够用的,把对应的模式转化成对应的script代码。

可视化是否做的好,就是整个框架包含的组件是否丰富,在我看来每一个组件都是一个应用,他应当是在服务器当中进行开发的,
deno期望的和浏览器一致,pyscript期望的浏览器跑py,最终要在浏览器上面跑的,都应该是js,那么一样的,无论前端当中, 什么样的架构体系,json或者其他语言也好,在浏览器上面开发,并最终转化为js代码就好。

我使用过babel和ts,这些是能够跑在浏览器上面的,如果去掉文件模块,或者设定虚拟文件模块,是否webpack就可以跑在浏览器当中来呢?

然后呢,整个应用可以独立存在并导出?编译的代码可以独立存在,是否就不需要react,vue了,整个开端的开发体系就升级了。实现方法需要更深入。

前端的数据连通性

无论是展示的数据还是访问的资源地址script代码,css代码,整体而言,都应该是整个体系的资源。用户生成的资源,用户使用软件(代码资源)。

可视化的关联性

可视化应用模块,它包含了很多需要考虑和补全的内容。

  • 组件之间的关系,数据传递的处理;
  • 对于前后端的数据的获取,可视化应用的在什么时候获取数据刷新问题,怎么去获取;
  • 组件应用的分享
  • 资源
  • 交互
  • 表单,表格,数据可视化,图表
  • 等等

把整个应用看着page,包含了很多app模块,其中的组件看作app,每一个app如何在浏览器上面单独开发,配置项处理,
共享应用问题,发布部署问题,app和app之间通信问题,怎么处理app之间数据公用问题,数据请求合并问题。

组件的开发也有很多需要思考,怎么通过浏览器开发组件,怎么共享组件,组件对应的文档和对应的接口数据规范,等等。

前后台隔阂处理

渲染
前端在访问单个页面的时候得到他需要获取的所有的资源地图,怎么访问函数【动态资源】,对应的组件的资源代码的地址【固定资源】。

动态资源比如个人用户信息,固定资源比如浏览器的渲染的源码,页面展示动态的资源。

前端需要有一个库,专门处理数据的请求,配置了页面后,可以通过配置项,用库调用到数据,类似tcb。

【资源加载库,判断这个url需要的那些资源,并在合适的时候加载】

后台开发 ??? 需要思考后台怎么可视化,如何部署,资源怎么关联,然后把固定的资源关联到后台,需要思考数据的存储问题和权限问题。

======

以上是关于可视化的思考,关于整个无服务生态的构想。

有很多要处理的问题,我仅仅是关于前端有一定的思考和实现方案,但是对于怎么把后端可视化起来,就需要更多的方向。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment