移动端前后端分离想法咨询可行性
本帖最后由 qtcxc 于 2019-12-8 09:53 编辑今天有一个奇怪的想法，我整理发上来，确认一下是否可行。
这个想法的起源是我们遇到的一个老问题，优化c端用户用活字格框架开发，加载慢的问题需要优化。
而优化的思路是，将c端用户 的前后端分离，前端使用传统的移动端开发框架实现放弃活字格的设计器设计移动端界面（轻量化前端）保证前端的界面加载速度。
前端后端分离，前端通过调用后端接口读写数据。
这整个思路是验证过也通过小范围测试已经实现过的是证实可行的。
但是对于我们这里的技术人员配置来说，技术水平较低，无法所有人都在短时间内掌握并高效的做到后端服务器的源码级别编程开发（能开发出来但是因为不专业所以开发出的接口肯定存在非常多的问题）。
所以后端接口开发，目前在考察引入第三方的快速api接口开发框架来提高接口的开发效率。目前考察的有apijson 和PhalApi 。
经过初步研究后发现这些框架实现的无非是作为中间层，链接后端数据库实现增删查看并实现权限校验，封装然后对前端开放。
正好这个时候我想起活字格是开放了JavaScript编程的，而里面提供的api就有数据库表增删查改的功能
而具体数据库表的增删查改 通过设计器中数据表权限控制，就可以做到权限的控制。
所以心里面产生了一个想法就是，是不是不需要引入第三方的东西，直接用JavaScript编程就可以做到。
需要确认一下，这个思路是否有问题，是否能走得通，现在能想到的有以下几个点可能会对这个思路是否走得通产生制约：
1、通过javascript编程+数据库表权限设置来达到api接口读写数据的话，对于登录是否有要求，如果开了允许匿名访问数据库，数据库表权限的设置是否也失效了？
2、客户端通过这样的方法直接读写数据库怎么保障安全性。
3、只用javascript编程+数据库表权限 的话是否可以减少活字格其它的关于前端框架的加载，如只保留实现javascript编程+数据库表权限相关的框架，其它的前端框架都不加载。
上面都是绕路了，是否考虑过提供一种，放弃活字格前端，实现一种安全的对外开放标准的api（或者可以比服务器端编程更便捷的配置的方法生成api接口）的办法，来实现移动端开发时前后端分离。可以让开发者更灵活的选择前端的框架开解决，移动端应用的跨平台跨端（h5，微信公众号，微信小程序，安卓app，iosapp，其它平台小程序）的开发，活字格设计器解决 数据库结构，后端逻辑和api开发的效率，而移动端的开发跟后端分离用更现代化的框架来实现提高开发效率和移动端体验。
本帖最后由 qtcxc 于 2019-12-8 09:50 编辑
感谢meteor的回复。
活字格目前的架构下，实现一套内部管理系统，基本够用。不过活字格团队应该也很清楚架构上的各种欠缺，从需求板块中我们经常可以看到一些比较专业的人提交的一些需求。所以能理解活字格团队的压力山大，任重道远。
回到用活字格的初衷重新整理一下思路。问题回归到为什么要用活字格自己开发系统上了。
原因从现状说起，信息化建设经历了这么多年的发展，企业从没有软件系统到有软件系统，从只有同一套系统到为了满足各种需求而引入了多套系统。这些系统大部分都是从各种各样的软件厂商那里购买来的标准产品，部分厂商可能会提供一些定制开发的服务，但是大部分厂商都是没办法做到根据企业的特点实现量身定做的。这就导致了购买的系统无法与实际业务配套影响效率，多套系统间的信息孤岛的问题。另外中国的互联网发展很快，现在的业务开展已经必须打通线上线下完整业务流程，不能再线上业务一套系统跑，线下业务一套独立系统跑，需要线上线下打通的完整业务流程的系统，提高效率减少不必要的人员投入。
一些有能力的公司已通过自己搭建团队自己研发系统来解决这些问题，针对大企业能够承担得起这样的投入。
但是还有很多像我们这样的中小型企业无法承担这样的投入。所以我们需要一套快捷低代码的开发平台，通过少量的人力投入可以实现系统的一体化开发。
无疑活字格是看到了这个趋势所以拆会有活字格这个产品，从2016年活字格刚发布一直都在关注活字格，直到最后选择用活字格。其实更多的是看到活字格各个版本的进步和对活字格的团队的认可。心里是清楚活字格现在还不是万能的，但是活字格给了我们实现的机会。
用活字格，已经开发了几套小系统外加一套比较大的系统正准备正式上线。所以领导们对开发更大型的系统也有了信心，需求也逐渐往更大的方向扩充。但是作为技术人员面临的就是更大需求和现有技术上的不匹配，遇到的各种各样的难点需要想办法克服和实现。
业务上的需要实现2C的功能且将响应的速度也作为项目能否成功的一个重要指标，而在没有现成解决方案的情况下只能想各种办法找人讨论看看能不能讨论出可行的方案。
很多时候提出需求时已经是基于自己团队内部讨论后认为能走通的方向提出，因为自己的不专业所以提出的需求到底是否是正确的并没有把握，更多的是想将想法提出来，更多人参与讨论，有更专业的人可以继续沿着这个思路研究，最终否定或认可这个思路其实都是一个帮助。
现在不行，不表示以后也不行，更希望我们可以依托在活字格上一起走得更远一点。
压力山大，任重道远中。
谢谢您的反馈~
我稍后详细整理 这个最近我们的开发经理，请假了，我暂时联系不到他是在不好意思:L
他说他11月6号左右回来呢 我把这个转移到需求里面先哈~ 个人感觉，这个需求有些脱离了活字格的当前产品定位。
活字格的目前定位，就是实现UI端的快速实现（低代码），以及将业务逻辑在页面端的设计中实现，（例如用公式，命令，单元格插件等方式）。所以，严格上说，活字格并不是往前后端分离的方向去走，而是融合。
这个问题讨论下去有些大，就是趋势到底是前后端分离好，还是融合好？这个也许永远争论不出答案。
所以我的意见是，看具体情况:lol
虽然这是明显的一句废话，但是从道理上看，活字格本身是追求快速开发，低代码开发，当页面只是需要简单的数据库表格的交互系统（其实大部分所谓系统都是这样），就没有太大的必要去追求极致设计的开发框架，引用数据接口，对活字格已有的体系再进行颠覆性工作。当然，这需要活字格官方的工作是渗透到各个UI端，比如手机端，微信端，平板端等等。。。然后用同样一套快速开发的体系来实现UI，以及各种命令和单元格组件。
当然，总会遇到一些API是复杂的，由活字格难以实现（用代码以api服务形式提供更佳），或者说一些通用服务希望多处可调用的。我目前的实践是构架个api网关，然后各个服务代码以webAPI的项目形式出现，注册入api网关。然后利用活字格的js注入优势，将api的调用用javascript封装使其更易于调用，并且集成了token机制用作api的权限之用（主要是调用权限）。 这里的api网关本身也是活字格来做的，当然，后端的服务时用了c#。当然这个权限，并非作者所说的表格权限部分，
充分理解并赞同作者的初衷，希望活字格的后端部分能更加封装以便API化，这样可自带集成表内权限部分。但是我存疑的地方在于，这可能会使得业务开发更加复杂化，而非简单化。因为如果仅仅是已经配置好的表格数据权限用来调用，最简单的方式是直接使用活字格的UI，而如果希望自己提供API，则希望这个机制由自己来建立是比较好，因为如果我提供的这个api本身访问数据都存在权限的问题，那这个api的后期调试是否会陷入麻烦的境地？
以上个人拙见，不对之处望多加提醒。 说的也没毛病哈，看来我们需要仔细斟酌一下 今天 有机会和陈总当面了解了一下，他们希望能够使用后端框架，我觉得 asp .net 可能真的可以集成呢，我下去在调查一下 如果服务器能集成asp.net功能就真是好消息。 非常的需要这个前后端分离的思路，我的需求也是一样，如果可以把活字格当做一个快速开发的后台及后端云来使用，支持自定义开发的API，同时能够自动生成常用API（如工作流、数据的增删改查、并受相用的权限约束、同时调用API时能够对应的数据更新或传递操作。）那后端及PC后台开发将变的非常简单，而C端用户的APP用原生或基于HTML5的WEBAPP开发并调用活字格自动生成的常用API，那开发效率与应用效果简直上天了。
强烈支持，这是我测试过UCML、金蝶云苍穹、金蝶云星空、teemlink、H3bpm、bex5、快表、宜搭（其中有些我是深度使用了）等产品后，我觉的最重要的需求，移动优先，各平台移动端效果均不理想，但自己开发移动前端很容易只是不方便对接。
另外，活字格的工作流还有待增强，比如，不同审批环节可以设置不同的字段可视权限，审批过程中的可根据权限设置编辑指定的字段。
但总之是一款非常优秀的产品。感谢~ 还在认真学习中。
麻烦版主再跟进一下这个需求。