【6.0.6】关于活字格连接redis问题，redis有哪些odbc驱动可用？

为什么重新评估 活字格+redis 而不是继续投入到纯代码上?
原因是 纯代码开发真的慢,人员要求也高,而且前端,后端技术栈还分开,需要更多的投入,而且有经验的人才不好找成本高.
想探索更低成本的开发模式,更快的开发效率,同时满足高性能开发要求.

现在活字格 已经基本补齐了前后端分离开发模式的相关能力能够满足前后端分离的开发需求,也开放了用户表,前端上也支持流式布局,前端框架也相应优化了速度,整体看下来我需要的都有了.

还缺的是高性能解决方案,我们用传统的代码开发思维想看看能不能直接引入redis来解决,同时我们开发的系统接下来要进行微服务化的重构,以便更好的配合公司业务变动需求.

这里涉及到整个架构的设计,是用纯代码,还是用低代码来作为这个微服务的核心,怎样才是人员,资金投入最少效率最高的.

活字格用了几年了,从最开始的4.0时代没有模块化,到5.0开始做模块化,到6.0服务器端的前后端分离,程序开发的设计方式也慢慢的从单体非异步的程序设计,慢慢的变成多模块异步调取的设计方式,最后再用纯代码的时候也引入了任务队列的设计方式.

为什么每次有新的功能后我会冒出一些新的想法,这主要是我也是一边做一边在学习的过程导致,很多时候我也很困惑希望能有比我高一维度的人能更早的告诉我你应该这样做才对,但是很不巧我没有遇到,所以需求才会这样一点点的蹦出来,需要先上了这个山头才看到下一座山.

有时候我在想,活字格可以组织一些聊天会,让一些资深的用户,坐一起聊天讨论一下,畅想一下自己想要做的东西,不一定是100%的解决方案,但是可以讨论方向,沟通想法,头脑风暴一下说不准能在沟通的过程相互都有收获.

收到 谢谢,我先研究

感谢您对活字格的支持。
后面有问题，欢迎继续发帖交流

开源的没有找到,只找到一个收费的odbc驱动,安装上 验证可以正常连接redis库也能操作
https://redislabs.com/redis-ente ... bc-jdbc-connectors/

感谢支持~