移动端前后端分离想法咨询可行性

如果服务器能集成asp.net功能就真是好消息。

今天 有机会和陈总当面了解了一下，他们希望能够使用后端框架，我觉得 asp .net 可能真的可以集成呢，我下去在调查一下

感谢meteor的回复。

活字格目前的架构下，实现一套内部管理系统，基本够用。不过活字格团队应该也很清楚架构上的各种欠缺，从需求板块中我们经常可以看到一些比较专业的人提交的一些需求。所以能理解活字格团队的压力山大，任重道远。

回到用活字格的初衷重新整理一下思路。问题回归到为什么要用活字格自己开发系统上了。

原因从现状说起，信息化建设经历了这么多年的发展，企业从没有软件系统到有软件系统，从只有同一套系统到为了满足各种需求而引入了多套系统。这些系统大部分都是从各种各样的软件厂商那里购买来的标准产品，部分厂商可能会提供一些定制开发的服务，但是大部分厂商都是没办法做到根据企业的特点实现量身定做的。这就导致了购买的系统无法与实际业务配套影响效率，多套系统间的信息孤岛的问题。另外中国的互联网发展很快，现在的业务开展已经必须打通线上线下完整业务流程，不能再线上业务一套系统跑，线下业务一套独立系统跑，需要线上线下打通的完整业务流程的系统，提高效率减少不必要的人员投入。

一些有能力的公司已通过自己搭建团队自己研发系统来解决这些问题，针对大企业能够承担得起这样的投入。
但是还有很多像我们这样的中小型企业无法承担这样的投入。所以我们需要一套快捷低代码的开发平台，通过少量的人力投入可以实现系统的一体化开发。

无疑活字格是看到了这个趋势所以拆会有活字格这个产品，从2016年活字格刚发布一直都在关注活字格，直到最后选择用活字格。其实更多的是看到活字格各个版本的进步和对活字格的团队的认可。心里是清楚活字格现在还不是万能的，但是活字格给了我们实现的机会。

用活字格，已经开发了几套小系统外加一套比较大的系统正准备正式上线。所以领导们对开发更大型的系统也有了信心，需求也逐渐往更大的方向扩充。但是作为技术人员面临的就是更大需求和现有技术上的不匹配，遇到的各种各样的难点需要想办法克服和实现。

业务上的需要实现2C的功能且将响应的速度也作为项目能否成功的一个重要指标，而在没有现成解决方案的情况下只能想各种办法找人讨论看看能不能讨论出可行的方案。

很多时候提出需求时已经是基于自己团队内部讨论后认为能走通的方向提出，因为自己的不专业所以提出的需求到底是否是正确的并没有把握，更多的是想将想法提出来，更多人参与讨论，有更专业的人可以继续沿着这个思路研究，最终否定或认可这个思路其实都是一个帮助。


现在不行，不表示以后也不行，更希望我们可以依托在活字格上一起走得更远一点。
压力山大，任重道远中。

说的也没毛病哈，看来我们需要仔细斟酌一下

个人感觉，这个需求有些脱离了活字格的当前产品定位。
活字格的目前定位，就是实现UI端的快速实现（低代码），以及将业务逻辑在页面端的设计中实现，（例如用公式，命令，单元格插件等方式）。所以，严格上说，活字格并不是往前后端分离的方向去走，而是融合。
这个问题讨论下去有些大，就是趋势到底是前后端分离好，还是融合好？这个也许永远争论不出答案。
所以我的意见是，看具体情况
虽然这是明显的一句废话，但是从道理上看，活字格本身是追求快速开发，低代码开发，当页面只是需要简单的数据库表格的交互系统（其实大部分所谓系统都是这样），就没有太大的必要去追求极致设计的开发框架，引用数据接口，对活字格已有的体系再进行颠覆性工作。当然，这需要活字格官方的工作是渗透到各个UI端，比如手机端，微信端，平板端等等。。。然后用同样一套快速开发的体系来实现UI，以及各种命令和单元格组件。
当然，总会遇到一些API是复杂的，由活字格难以实现（用代码以api服务形式提供更佳），或者说一些通用服务希望多处可调用的。我目前的实践是构架个api网关，然后各个服务代码以webAPI的项目形式出现，注册入api网关。然后利用活字格的js注入优势，将api的调用用javascript封装使其更易于调用，并且集成了token机制用作api的权限之用（主要是调用权限）。 这里的api网关本身也是活字格来做的，当然，后端的服务时用了c#。当然这个权限，并非作者所说的表格权限部分，
充分理解并赞同作者的初衷，希望活字格的后端部分能更加封装以便API化，这样可自带集成表内权限部分。但是我存疑的地方在于，这可能会使得业务开发更加复杂化，而非简单化。因为如果仅仅是已经配置好的表格数据权限用来调用，最简单的方式是直接使用活字格的UI，而如果希望自己提供API，则希望这个机制由自己来建立是比较好，因为如果我提供的这个api本身访问数据都存在权限的问题，那这个api的后期调试是否会陷入麻烦的境地？
以上个人拙见，不对之处望多加提醒。

我把这个转移到需求里面先哈~