GoSqlGo 首个正式版发布,在前端写 SQL 和业务逻辑

yong9981
 yong9981
发布于 2019年01月08日
收藏 16

GoSqlGo简介 | Description

GoSqlGo是一个运行于后端的服务端工具,它的最大特点就是在开发期动态编译客户端Java代码,所有SQL和Java代码都可以在前端Html页面完成,业务开发可以不再依赖后端程序员了。 

更新内容: 

GoSqlGo1.0.0版为首个正式发行版,相比与上一个试验版,1.0.0版本完成了打包工具的开发,并已发布到Maven中央库。利用打包工具,html/Javascript中的SQL和Java代码,在布署阶段将会被抽取为类似$qry('CJKDn23r9','A',0)这样的根据ID来调用的语句,从而实现安全性。

关于GoSqlGo的打包工具使用和更多介绍,请详见码云项目主页 (https://gitee.com/drinkjava2/gosqlgo)

附:GoSqlGo前端使用示例

前端程序员可以直接在Javascript里写SQL和Java代码,例如以下为一个HTML片段,实测通过,完整文件位于这里
这是一个转账业务的演示,它把所有的业务逻辑都写在html里面,不再需要和后端程序员沟通了:

<!DOCTYPE html>
<html>
<head>
<script src="/js/jquery-1.11.3.min.js"></script>
<script src="/js/jquery-ajax-ext.js"></script>
<script src="/js/gosqlgo.js"></script>
</head>
<body>
    <h1>Transaction Demo</h1>
    <div id="msgid" class="msg"></div>
    <section>
        <header>Account A</header>
        <div id="A" class="amount">
            <script>
                document.write($qry('select amount from account where id=? and amount>=?', 'A',0));
            </script>
        </div>
    </section>
    <section>
        <header>Account B</header>
        <div id="B" class="amount">
            <script>
                document.write($qry('select amount from account where id=? and amount>=?', 'B',0));
            </script>
        </div>
    </section>
    <script>
      function transfer(from, to, money){
         var rst = $java(`TX
                        int money=Integer.parseInt($3);
                        if(money<=0)
                          throw new SecurityException("Money<=0, IP:"+ getRequest().getRemoteAddr());
                        Account a=new Account().setId($1).load();
                        if(a.getAmount()<money)
                           return "No enough balance!";
                        Account b=new Account().setId($2).load();
                        a.setAmount(a.getAmount()-money).update();
                        b.setAmount(b.getAmount()+money).update();
                        return "Transfer Success!|"+a.getAmount()+"|"+b.getAmount();
                        `,    from,to,money
                    );   
          if(rst.startsWith("Transfer Success!")) {
              var words=rst.split('|');
               $("#msgid").text(words[0]);
               $("#"+from).text(words[1]);
               $("#"+to).text(words[2]);
               $("#msgid").css("background", "#dfb");
          }
          else { $("#msgid").text(rst);
                 $("#msgid").css("background", "#ffbeb8");
          }
        }
    </script>
    <section>
        <header>Transfer</header>
        <form onsubmit="return false" action="##" method="post">
            <input name="amount" value="100" class="amount">
            <button name="btnA2B" value="true" onclick="transfer('A','B',100)">From
                account A to account B</button>
            <button name="btnB2A" value="true" onclick="transfer('B','A',100)">From
                account B to account A</button>
        </form>
    </section>
</body>
</html>

在布署阶段,可以用new DeployTool().goServ() 命令将上述html中的SQL和Java代码转移到服务端。已抽取出的Java类还可以用goFront()方法逆向操作,再将代码塞回到html中去。 

作者其它开源项目 | Other Projects

版权 | License

Apache 2.0

关注我 | About Me

Github
码云

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:GoSqlGo 首个正式版发布,在前端写 SQL 和业务逻辑
加载中

精彩评论

左华栋
左华栋

引用来自“程序人生2015”的评论

如何保证安全性,任何人都可以删库吧,代码如何重用😬

引用来自“左华栋”的评论

prisma.io 了解下? 比这个靠谱多了

引用来自“yong9981”的评论

想了一下,须要重用的代码可以布置到服务端后用SERV 注明,其它页面引用它的ID即可。

引用来自“yong9981”的评论

prisma.io主要使用Javascript语言,就这一条就可以否决了。服务端还是Java更可靠、强大一些。

引用来自“左华栋”的评论

前端就是 js 啊,不喜欢可以用 ts 。
什么? java ? 这个不需要后端了。

引用来自“yong9981”的评论

这个是将操作数据库(包括将来的Redis,NoSql等其它类型的数据库)挪到前端(html页面里)了,再考虑到分库分表、分布式事务、容错、缓存这些功能将来都有可能在前端搞定,还是用Java语言靠谱些。前端连Javascript都能学会,学点Java也不算个事。
前后端有各自专注的东西。
如果把后端那套逻辑和思维拿过来的话:
谷歌很早之前就做过尝试了,比如 GWT ,目前这个项目已死,新项目是 Dart 。
当然,kotlin 也可以生成js 来写前端。但都不温不火的。
如果你和我们一样喜欢 AOP 思想,那你可以选择 angular ,生态也十分健全。
如果你只是想用前端去写后端,那选择 prisma.io 没错。
前端未来 是 Typescript 和 Dart 争天下了。
左华栋
左华栋

引用来自“程序人生2015”的评论

如何保证安全性,任何人都可以删库吧,代码如何重用😬
prisma.io 了解下? 比这个靠谱多了

最新评论(30

yong9981
yong9981

引用来自“程序人生2015”的评论

如何保证安全性,任何人都可以删库吧,代码如何重用😬

引用来自“左华栋”的评论

prisma.io 了解下? 比这个靠谱多了

引用来自“yong9981”的评论

想了一下,须要重用的代码可以布置到服务端后用SERV 注明,其它页面引用它的ID即可。

引用来自“yong9981”的评论

prisma.io主要使用Javascript语言,就这一条就可以否决了。服务端还是Java更可靠、强大一些。

引用来自“左华栋”的评论

前端就是 js 啊,不喜欢可以用 ts 。
什么? java ? 这个不需要后端了。

引用来自“yong9981”的评论

这个是将操作数据库(包括将来的Redis,NoSql等其它类型的数据库)挪到前端(html页面里)了,再考虑到分库分表、分布式事务、容错、缓存这些功能将来都有可能在前端搞定,还是用Java语言靠谱些。前端连Javascript都能学会,学点Java也不算个事。

引用来自“左华栋”的评论

前后端有各自专注的东西。
如果把后端那套逻辑和思维拿过来的话:
谷歌很早之前就做过尝试了,比如 GWT ,目前这个项目已死,新项目是 Dart 。
当然,kotlin 也可以生成js 来写前端。但都不温不火的。
如果你和我们一样喜欢 AOP 思想,那你可以选择 angular ,生态也十分健全。
如果你只是想用前端去写后端,那选择 prisma.io 没错。
前端未来 是 Typescript 和 Dart 争天下了。

引用来自“yong9981”的评论

个人认为:任何想在后端运行弱语言编写复杂业务逻辑(Node.js)、任何想用Java操纵界面的(GWT、JSP)尝试,都是不可行的,服务端只能用Java, 前端只能用Javascript。

引用来自“yong9981”的评论

再谈一下对prisma.io 这类基于GraphQL API的工具的看法
1)GraphQL客户端在一个查询请求中,声明需要的数据结构和字段。这和大前端的开发方式是不一样的,后者不需要声明需要哪些数据,因为后者即是消费者,也是生产者,自已声明自已生产出来的数据格式应该是怎么样的,这属于脱裤子放屁多此一举。
2)GraphQL是个数据接口标准而已,ORM层象是个想象中的玩具,实际不见得好使(对于Java界来说,DAO工具也没有哪个说是完美的)。它不做输入验证、业务逻辑这些事,还是需要第三方语言来实现。而GoSqlGo只是一个简单的远程Ajax原生Java调用而已,没有什么复杂的技术,可以干任何输入验证、业务逻辑、用任意DAO工具存取数据库。

引用来自“左华栋”的评论

graphql 恰恰是前端推起来替代restful 的。

引用来自“yong9981”的评论

哪是因为以前前端不懂后端的苦。提出一个数据接口和具体实现它完全是两回事。当前后端分离开发的时候,前端当然需要通过接口的形式来指挥后端干活。但是当前端本身就是实现者的时候,就会发现自已定接口,自已去实现是多此一举了。

引用来自“左华栋”的评论

graphql 既方便了前端,也方便了后端,后端不用再考虑把业务抽象成 CURD 。
你的出发点和理解都是错的。
具体可以看看 apollo-graphql 。
java 也有类似的包。

引用来自“yong9981”的评论

这是我总结的GraphQL和GoSqlGo的对比,看说的对不:
GraphQL需要定义数据结构,GoSqlGo不需要,返回什么数据大前端程序员自已知道。
GraphQL解决Rest请求多次的问题, GoSqlGo用普通的post就可以了
GraphQL返回图结构数据, GoSqlGo可以用任意ORM工具返回对象树, 也可以直接调用SQL返回MapList结构。
GraphQL隐藏SQL, GoSqlGo即可使用ORM工具,也可以使用原生SQL。
GraphQL不能处理复杂逻辑,业务逻辑还是要交给后端语言。GoSqlGo直接调用Java,可以处理任意后台逻辑
GraphQL很容易把资源全部暴露,需要复杂的权限限制。GoSqlGo的Java方法可以手工校验所有输入,安全性高。
GraphQL使用脚本语法,连Javascript都不是。GoSqlGo使用Java语言。

引用来自“左华栋”的评论

先入为主,偏见太多了~
你要连数据库一起纳入对比的话,可以看 prisma.io 。
GraphQL 就是处理复杂逻辑的。
GraphQL 不暴露全部资源。
GraphQL 跟是不是java 是不是 js 没关系,它就是它自己,SQL 也不是js 也不是java。

引用来自“yong9981”的评论

等我再研究一下prisma.io,作为一个ORM工具的作者,我得把它支不支持SQL功能先找出来再谈别的。
找到了,好吧,Javascript也有很不错的DAO工具了,喜欢JS那就接着用JS吧。不过老实说,服务端用JS的唯一理由可能就是对JS语言的偏爱了。同理,GoSqlGo是调用Java,后端工具真的是不要太少,如果有对Java语言偏好的也大可以试一试。
另外,GoSqlGo并不光是一个工具,它还是一种思路,即在开发期将服务端源码写在html里,在布署期再单独用打包工具抽取出来,这种做法适用于任何语言,包括node.js,只是不知道前端是否已经这么干过。
yong9981
yong9981

引用来自“程序人生2015”的评论

如何保证安全性,任何人都可以删库吧,代码如何重用😬

引用来自“左华栋”的评论

prisma.io 了解下? 比这个靠谱多了

引用来自“yong9981”的评论

想了一下,须要重用的代码可以布置到服务端后用SERV 注明,其它页面引用它的ID即可。

引用来自“yong9981”的评论

prisma.io主要使用Javascript语言,就这一条就可以否决了。服务端还是Java更可靠、强大一些。

引用来自“左华栋”的评论

前端就是 js 啊,不喜欢可以用 ts 。
什么? java ? 这个不需要后端了。

引用来自“yong9981”的评论

这个是将操作数据库(包括将来的Redis,NoSql等其它类型的数据库)挪到前端(html页面里)了,再考虑到分库分表、分布式事务、容错、缓存这些功能将来都有可能在前端搞定,还是用Java语言靠谱些。前端连Javascript都能学会,学点Java也不算个事。

引用来自“左华栋”的评论

前后端有各自专注的东西。
如果把后端那套逻辑和思维拿过来的话:
谷歌很早之前就做过尝试了,比如 GWT ,目前这个项目已死,新项目是 Dart 。
当然,kotlin 也可以生成js 来写前端。但都不温不火的。
如果你和我们一样喜欢 AOP 思想,那你可以选择 angular ,生态也十分健全。
如果你只是想用前端去写后端,那选择 prisma.io 没错。
前端未来 是 Typescript 和 Dart 争天下了。

引用来自“yong9981”的评论

个人认为:任何想在后端运行弱语言编写复杂业务逻辑(Node.js)、任何想用Java操纵界面的(GWT、JSP)尝试,都是不可行的,服务端只能用Java, 前端只能用Javascript。

引用来自“yong9981”的评论

再谈一下对prisma.io 这类基于GraphQL API的工具的看法
1)GraphQL客户端在一个查询请求中,声明需要的数据结构和字段。这和大前端的开发方式是不一样的,后者不需要声明需要哪些数据,因为后者即是消费者,也是生产者,自已声明自已生产出来的数据格式应该是怎么样的,这属于脱裤子放屁多此一举。
2)GraphQL是个数据接口标准而已,ORM层象是个想象中的玩具,实际不见得好使(对于Java界来说,DAO工具也没有哪个说是完美的)。它不做输入验证、业务逻辑这些事,还是需要第三方语言来实现。而GoSqlGo只是一个简单的远程Ajax原生Java调用而已,没有什么复杂的技术,可以干任何输入验证、业务逻辑、用任意DAO工具存取数据库。

引用来自“左华栋”的评论

graphql 恰恰是前端推起来替代restful 的。

引用来自“yong9981”的评论

哪是因为以前前端不懂后端的苦。提出一个数据接口和具体实现它完全是两回事。当前后端分离开发的时候,前端当然需要通过接口的形式来指挥后端干活。但是当前端本身就是实现者的时候,就会发现自已定接口,自已去实现是多此一举了。

引用来自“左华栋”的评论

graphql 既方便了前端,也方便了后端,后端不用再考虑把业务抽象成 CURD 。
你的出发点和理解都是错的。
具体可以看看 apollo-graphql 。
java 也有类似的包。

引用来自“yong9981”的评论

这是我总结的GraphQL和GoSqlGo的对比,看说的对不:
GraphQL需要定义数据结构,GoSqlGo不需要,返回什么数据大前端程序员自已知道。
GraphQL解决Rest请求多次的问题, GoSqlGo用普通的post就可以了
GraphQL返回图结构数据, GoSqlGo可以用任意ORM工具返回对象树, 也可以直接调用SQL返回MapList结构。
GraphQL隐藏SQL, GoSqlGo即可使用ORM工具,也可以使用原生SQL。
GraphQL不能处理复杂逻辑,业务逻辑还是要交给后端语言。GoSqlGo直接调用Java,可以处理任意后台逻辑
GraphQL很容易把资源全部暴露,需要复杂的权限限制。GoSqlGo的Java方法可以手工校验所有输入,安全性高。
GraphQL使用脚本语法,连Javascript都不是。GoSqlGo使用Java语言。

引用来自“左华栋”的评论

先入为主,偏见太多了~
你要连数据库一起纳入对比的话,可以看 prisma.io 。
GraphQL 就是处理复杂逻辑的。
GraphQL 不暴露全部资源。
GraphQL 跟是不是java 是不是 js 没关系,它就是它自己,SQL 也不是js 也不是java。
等我再研究一下prisma.io,作为一个ORM工具的作者,我得把它支不支持SQL功能先找出来再谈别的。
左华栋
左华栋

引用来自“程序人生2015”的评论

如何保证安全性,任何人都可以删库吧,代码如何重用😬

引用来自“左华栋”的评论

prisma.io 了解下? 比这个靠谱多了

引用来自“yong9981”的评论

想了一下,须要重用的代码可以布置到服务端后用SERV 注明,其它页面引用它的ID即可。

引用来自“yong9981”的评论

prisma.io主要使用Javascript语言,就这一条就可以否决了。服务端还是Java更可靠、强大一些。

引用来自“左华栋”的评论

前端就是 js 啊,不喜欢可以用 ts 。
什么? java ? 这个不需要后端了。

引用来自“yong9981”的评论

这个是将操作数据库(包括将来的Redis,NoSql等其它类型的数据库)挪到前端(html页面里)了,再考虑到分库分表、分布式事务、容错、缓存这些功能将来都有可能在前端搞定,还是用Java语言靠谱些。前端连Javascript都能学会,学点Java也不算个事。

引用来自“左华栋”的评论

前后端有各自专注的东西。
如果把后端那套逻辑和思维拿过来的话:
谷歌很早之前就做过尝试了,比如 GWT ,目前这个项目已死,新项目是 Dart 。
当然,kotlin 也可以生成js 来写前端。但都不温不火的。
如果你和我们一样喜欢 AOP 思想,那你可以选择 angular ,生态也十分健全。
如果你只是想用前端去写后端,那选择 prisma.io 没错。
前端未来 是 Typescript 和 Dart 争天下了。

引用来自“yong9981”的评论

个人认为:任何想在后端运行弱语言编写复杂业务逻辑(Node.js)、任何想用Java操纵界面的(GWT、JSP)尝试,都是不可行的,服务端只能用Java, 前端只能用Javascript。

引用来自“yong9981”的评论

再谈一下对prisma.io 这类基于GraphQL API的工具的看法
1)GraphQL客户端在一个查询请求中,声明需要的数据结构和字段。这和大前端的开发方式是不一样的,后者不需要声明需要哪些数据,因为后者即是消费者,也是生产者,自已声明自已生产出来的数据格式应该是怎么样的,这属于脱裤子放屁多此一举。
2)GraphQL是个数据接口标准而已,ORM层象是个想象中的玩具,实际不见得好使(对于Java界来说,DAO工具也没有哪个说是完美的)。它不做输入验证、业务逻辑这些事,还是需要第三方语言来实现。而GoSqlGo只是一个简单的远程Ajax原生Java调用而已,没有什么复杂的技术,可以干任何输入验证、业务逻辑、用任意DAO工具存取数据库。

引用来自“左华栋”的评论

graphql 恰恰是前端推起来替代restful 的。

引用来自“yong9981”的评论

哪是因为以前前端不懂后端的苦。提出一个数据接口和具体实现它完全是两回事。当前后端分离开发的时候,前端当然需要通过接口的形式来指挥后端干活。但是当前端本身就是实现者的时候,就会发现自已定接口,自已去实现是多此一举了。

引用来自“左华栋”的评论

graphql 既方便了前端,也方便了后端,后端不用再考虑把业务抽象成 CURD 。
你的出发点和理解都是错的。
具体可以看看 apollo-graphql 。
java 也有类似的包。

引用来自“yong9981”的评论

这是我总结的GraphQL和GoSqlGo的对比,看说的对不:
GraphQL需要定义数据结构,GoSqlGo不需要,返回什么数据大前端程序员自已知道。
GraphQL解决Rest请求多次的问题, GoSqlGo用普通的post就可以了
GraphQL返回图结构数据, GoSqlGo可以用任意ORM工具返回对象树, 也可以直接调用SQL返回MapList结构。
GraphQL隐藏SQL, GoSqlGo即可使用ORM工具,也可以使用原生SQL。
GraphQL不能处理复杂逻辑,业务逻辑还是要交给后端语言。GoSqlGo直接调用Java,可以处理任意后台逻辑
GraphQL很容易把资源全部暴露,需要复杂的权限限制。GoSqlGo的Java方法可以手工校验所有输入,安全性高。
GraphQL使用脚本语法,连Javascript都不是。GoSqlGo使用Java语言。
先入为主,偏见太多了~
你要连数据库一起纳入对比的话,可以看 prisma.io 。
GraphQL 就是处理复杂逻辑的。
GraphQL 不暴露全部资源。
GraphQL 跟是不是java 是不是 js 没关系,它就是它自己,SQL 也不是js 也不是java。
yong9981
yong9981

引用来自“程序人生2015”的评论

如何保证安全性,任何人都可以删库吧,代码如何重用😬

引用来自“左华栋”的评论

prisma.io 了解下? 比这个靠谱多了

引用来自“yong9981”的评论

想了一下,须要重用的代码可以布置到服务端后用SERV 注明,其它页面引用它的ID即可。

引用来自“yong9981”的评论

prisma.io主要使用Javascript语言,就这一条就可以否决了。服务端还是Java更可靠、强大一些。

引用来自“左华栋”的评论

前端就是 js 啊,不喜欢可以用 ts 。
什么? java ? 这个不需要后端了。

引用来自“yong9981”的评论

这个是将操作数据库(包括将来的Redis,NoSql等其它类型的数据库)挪到前端(html页面里)了,再考虑到分库分表、分布式事务、容错、缓存这些功能将来都有可能在前端搞定,还是用Java语言靠谱些。前端连Javascript都能学会,学点Java也不算个事。

引用来自“左华栋”的评论

前后端有各自专注的东西。
如果把后端那套逻辑和思维拿过来的话:
谷歌很早之前就做过尝试了,比如 GWT ,目前这个项目已死,新项目是 Dart 。
当然,kotlin 也可以生成js 来写前端。但都不温不火的。
如果你和我们一样喜欢 AOP 思想,那你可以选择 angular ,生态也十分健全。
如果你只是想用前端去写后端,那选择 prisma.io 没错。
前端未来 是 Typescript 和 Dart 争天下了。

引用来自“yong9981”的评论

个人认为:任何想在后端运行弱语言编写复杂业务逻辑(Node.js)、任何想用Java操纵界面的(GWT、JSP)尝试,都是不可行的,服务端只能用Java, 前端只能用Javascript。

引用来自“yong9981”的评论

再谈一下对prisma.io 这类基于GraphQL API的工具的看法
1)GraphQL客户端在一个查询请求中,声明需要的数据结构和字段。这和大前端的开发方式是不一样的,后者不需要声明需要哪些数据,因为后者即是消费者,也是生产者,自已声明自已生产出来的数据格式应该是怎么样的,这属于脱裤子放屁多此一举。
2)GraphQL是个数据接口标准而已,ORM层象是个想象中的玩具,实际不见得好使(对于Java界来说,DAO工具也没有哪个说是完美的)。它不做输入验证、业务逻辑这些事,还是需要第三方语言来实现。而GoSqlGo只是一个简单的远程Ajax原生Java调用而已,没有什么复杂的技术,可以干任何输入验证、业务逻辑、用任意DAO工具存取数据库。

引用来自“左华栋”的评论

graphql 恰恰是前端推起来替代restful 的。

引用来自“yong9981”的评论

哪是因为以前前端不懂后端的苦。提出一个数据接口和具体实现它完全是两回事。当前后端分离开发的时候,前端当然需要通过接口的形式来指挥后端干活。但是当前端本身就是实现者的时候,就会发现自已定接口,自已去实现是多此一举了。

引用来自“左华栋”的评论

graphql 既方便了前端,也方便了后端,后端不用再考虑把业务抽象成 CURD 。
你的出发点和理解都是错的。
具体可以看看 apollo-graphql 。
java 也有类似的包。
这是我总结的GraphQL和GoSqlGo的对比,看说的对不:
GraphQL需要定义数据结构,GoSqlGo不需要,返回什么数据大前端程序员自已知道。
GraphQL解决Rest请求多次的问题, GoSqlGo用普通的post就可以了
GraphQL返回图结构数据, GoSqlGo可以用任意ORM工具返回对象树, 也可以直接调用SQL返回MapList结构。
GraphQL隐藏SQL, GoSqlGo即可使用ORM工具,也可以使用原生SQL。
GraphQL不能处理复杂逻辑,业务逻辑还是要交给后端语言。GoSqlGo直接调用Java,可以处理任意后台逻辑
GraphQL很容易把资源全部暴露,需要复杂的权限限制。GoSqlGo的Java方法可以手工校验所有输入,安全性高。
GraphQL使用脚本语法,连Javascript都不是。GoSqlGo使用Java语言。
左华栋
左华栋

引用来自“程序人生2015”的评论

如何保证安全性,任何人都可以删库吧,代码如何重用😬

引用来自“左华栋”的评论

prisma.io 了解下? 比这个靠谱多了

引用来自“yong9981”的评论

想了一下,须要重用的代码可以布置到服务端后用SERV 注明,其它页面引用它的ID即可。

引用来自“yong9981”的评论

prisma.io主要使用Javascript语言,就这一条就可以否决了。服务端还是Java更可靠、强大一些。

引用来自“左华栋”的评论

前端就是 js 啊,不喜欢可以用 ts 。
什么? java ? 这个不需要后端了。

引用来自“yong9981”的评论

这个是将操作数据库(包括将来的Redis,NoSql等其它类型的数据库)挪到前端(html页面里)了,再考虑到分库分表、分布式事务、容错、缓存这些功能将来都有可能在前端搞定,还是用Java语言靠谱些。前端连Javascript都能学会,学点Java也不算个事。

引用来自“左华栋”的评论

前后端有各自专注的东西。
如果把后端那套逻辑和思维拿过来的话:
谷歌很早之前就做过尝试了,比如 GWT ,目前这个项目已死,新项目是 Dart 。
当然,kotlin 也可以生成js 来写前端。但都不温不火的。
如果你和我们一样喜欢 AOP 思想,那你可以选择 angular ,生态也十分健全。
如果你只是想用前端去写后端,那选择 prisma.io 没错。
前端未来 是 Typescript 和 Dart 争天下了。

引用来自“yong9981”的评论

个人认为:任何想在后端运行弱语言编写复杂业务逻辑(Node.js)、任何想用Java操纵界面的(GWT、JSP)尝试,都是不可行的,服务端只能用Java, 前端只能用Javascript。

引用来自“yong9981”的评论

再谈一下对prisma.io 这类基于GraphQL API的工具的看法
1)GraphQL客户端在一个查询请求中,声明需要的数据结构和字段。这和大前端的开发方式是不一样的,后者不需要声明需要哪些数据,因为后者即是消费者,也是生产者,自已声明自已生产出来的数据格式应该是怎么样的,这属于脱裤子放屁多此一举。
2)GraphQL是个数据接口标准而已,ORM层象是个想象中的玩具,实际不见得好使(对于Java界来说,DAO工具也没有哪个说是完美的)。它不做输入验证、业务逻辑这些事,还是需要第三方语言来实现。而GoSqlGo只是一个简单的远程Ajax原生Java调用而已,没有什么复杂的技术,可以干任何输入验证、业务逻辑、用任意DAO工具存取数据库。

引用来自“左华栋”的评论

graphql 恰恰是前端推起来替代restful 的。

引用来自“yong9981”的评论

哪是因为以前前端不懂后端的苦。提出一个数据接口和具体实现它完全是两回事。当前后端分离开发的时候,前端当然需要通过接口的形式来指挥后端干活。但是当前端本身就是实现者的时候,就会发现自已定接口,自已去实现是多此一举了。
graphql 既方便了前端,也方便了后端,后端不用再考虑把业务抽象成 CURD 。
你的出发点和理解都是错的。
具体可以看看 apollo-graphql 。
java 也有类似的包。
yong9981
yong9981

引用来自“程序人生2015”的评论

如何保证安全性,任何人都可以删库吧,代码如何重用😬

引用来自“左华栋”的评论

prisma.io 了解下? 比这个靠谱多了

引用来自“yong9981”的评论

想了一下,须要重用的代码可以布置到服务端后用SERV 注明,其它页面引用它的ID即可。

引用来自“yong9981”的评论

prisma.io主要使用Javascript语言,就这一条就可以否决了。服务端还是Java更可靠、强大一些。

引用来自“左华栋”的评论

前端就是 js 啊,不喜欢可以用 ts 。
什么? java ? 这个不需要后端了。

引用来自“yong9981”的评论

这个是将操作数据库(包括将来的Redis,NoSql等其它类型的数据库)挪到前端(html页面里)了,再考虑到分库分表、分布式事务、容错、缓存这些功能将来都有可能在前端搞定,还是用Java语言靠谱些。前端连Javascript都能学会,学点Java也不算个事。

引用来自“左华栋”的评论

前后端有各自专注的东西。
如果把后端那套逻辑和思维拿过来的话:
谷歌很早之前就做过尝试了,比如 GWT ,目前这个项目已死,新项目是 Dart 。
当然,kotlin 也可以生成js 来写前端。但都不温不火的。
如果你和我们一样喜欢 AOP 思想,那你可以选择 angular ,生态也十分健全。
如果你只是想用前端去写后端,那选择 prisma.io 没错。
前端未来 是 Typescript 和 Dart 争天下了。

引用来自“yong9981”的评论

个人认为:任何想在后端运行弱语言编写复杂业务逻辑(Node.js)、任何想用Java操纵界面的(GWT、JSP)尝试,都是不可行的,服务端只能用Java, 前端只能用Javascript。

引用来自“yong9981”的评论

再谈一下对prisma.io 这类基于GraphQL API的工具的看法
1)GraphQL客户端在一个查询请求中,声明需要的数据结构和字段。这和大前端的开发方式是不一样的,后者不需要声明需要哪些数据,因为后者即是消费者,也是生产者,自已声明自已生产出来的数据格式应该是怎么样的,这属于脱裤子放屁多此一举。
2)GraphQL是个数据接口标准而已,ORM层象是个想象中的玩具,实际不见得好使(对于Java界来说,DAO工具也没有哪个说是完美的)。它不做输入验证、业务逻辑这些事,还是需要第三方语言来实现。而GoSqlGo只是一个简单的远程Ajax原生Java调用而已,没有什么复杂的技术,可以干任何输入验证、业务逻辑、用任意DAO工具存取数据库。

引用来自“左华栋”的评论

graphql 恰恰是前端推起来替代restful 的。
哪是因为以前前端不懂后端的苦。提出一个数据接口和具体实现它完全是两回事。当前后端分离开发的时候,前端当然需要通过接口的形式来指挥后端干活。但是当前端本身就是实现者的时候,就会发现自已定接口,自已去实现是多此一举了。
左华栋
左华栋

引用来自“程序人生2015”的评论

如何保证安全性,任何人都可以删库吧,代码如何重用😬

引用来自“左华栋”的评论

prisma.io 了解下? 比这个靠谱多了

引用来自“yong9981”的评论

想了一下,须要重用的代码可以布置到服务端后用SERV 注明,其它页面引用它的ID即可。

引用来自“yong9981”的评论

prisma.io主要使用Javascript语言,就这一条就可以否决了。服务端还是Java更可靠、强大一些。

引用来自“左华栋”的评论

前端就是 js 啊,不喜欢可以用 ts 。
什么? java ? 这个不需要后端了。

引用来自“yong9981”的评论

这个是将操作数据库(包括将来的Redis,NoSql等其它类型的数据库)挪到前端(html页面里)了,再考虑到分库分表、分布式事务、容错、缓存这些功能将来都有可能在前端搞定,还是用Java语言靠谱些。前端连Javascript都能学会,学点Java也不算个事。

引用来自“左华栋”的评论

前后端有各自专注的东西。
如果把后端那套逻辑和思维拿过来的话:
谷歌很早之前就做过尝试了,比如 GWT ,目前这个项目已死,新项目是 Dart 。
当然,kotlin 也可以生成js 来写前端。但都不温不火的。
如果你和我们一样喜欢 AOP 思想,那你可以选择 angular ,生态也十分健全。
如果你只是想用前端去写后端,那选择 prisma.io 没错。
前端未来 是 Typescript 和 Dart 争天下了。

引用来自“yong9981”的评论

个人认为:任何想在后端运行弱语言编写复杂业务逻辑(Node.js)、任何想用Java操纵界面的(GWT、JSP)尝试,都是不可行的,服务端只能用Java, 前端只能用Javascript。
这些话太偏见了。
我建议你倒是可以看看 nest.js 这个框架,再来谈。
左华栋
左华栋

引用来自“程序人生2015”的评论

如何保证安全性,任何人都可以删库吧,代码如何重用😬

引用来自“左华栋”的评论

prisma.io 了解下? 比这个靠谱多了

引用来自“yong9981”的评论

想了一下,须要重用的代码可以布置到服务端后用SERV 注明,其它页面引用它的ID即可。

引用来自“yong9981”的评论

prisma.io主要使用Javascript语言,就这一条就可以否决了。服务端还是Java更可靠、强大一些。

引用来自“左华栋”的评论

前端就是 js 啊,不喜欢可以用 ts 。
什么? java ? 这个不需要后端了。

引用来自“yong9981”的评论

这个是将操作数据库(包括将来的Redis,NoSql等其它类型的数据库)挪到前端(html页面里)了,再考虑到分库分表、分布式事务、容错、缓存这些功能将来都有可能在前端搞定,还是用Java语言靠谱些。前端连Javascript都能学会,学点Java也不算个事。

引用来自“左华栋”的评论

前后端有各自专注的东西。
如果把后端那套逻辑和思维拿过来的话:
谷歌很早之前就做过尝试了,比如 GWT ,目前这个项目已死,新项目是 Dart 。
当然,kotlin 也可以生成js 来写前端。但都不温不火的。
如果你和我们一样喜欢 AOP 思想,那你可以选择 angular ,生态也十分健全。
如果你只是想用前端去写后端,那选择 prisma.io 没错。
前端未来 是 Typescript 和 Dart 争天下了。

引用来自“yong9981”的评论

个人认为:任何想在后端运行弱语言编写复杂业务逻辑(Node.js)、任何想用Java操纵界面的(GWT、JSP)尝试,都是不可行的,服务端只能用Java, 前端只能用Javascript。

引用来自“yong9981”的评论

再谈一下对prisma.io 这类基于GraphQL API的工具的看法
1)GraphQL客户端在一个查询请求中,声明需要的数据结构和字段。这和大前端的开发方式是不一样的,后者不需要声明需要哪些数据,因为后者即是消费者,也是生产者,自已声明自已生产出来的数据格式应该是怎么样的,这属于脱裤子放屁多此一举。
2)GraphQL是个数据接口标准而已,ORM层象是个想象中的玩具,实际不见得好使(对于Java界来说,DAO工具也没有哪个说是完美的)。它不做输入验证、业务逻辑这些事,还是需要第三方语言来实现。而GoSqlGo只是一个简单的远程Ajax原生Java调用而已,没有什么复杂的技术,可以干任何输入验证、业务逻辑、用任意DAO工具存取数据库。
graphql 恰恰是前端推起来替代restful 的。
面码
面码

引用来自“程序人生2015”的评论

如何保证安全性,任何人都可以删库吧,代码如何重用😬

引用来自“左华栋”的评论

prisma.io 了解下? 比这个靠谱多了

引用来自“yong9981”的评论

想了一下,须要重用的代码可以布置到服务端后用SERV 注明,其它页面引用它的ID即可。

引用来自“yong9981”的评论

prisma.io主要使用Javascript语言,就这一条就可以否决了。服务端还是Java更可靠、强大一些。

引用来自“左华栋”的评论

前端就是 js 啊,不喜欢可以用 ts 。
什么? java ? 这个不需要后端了。

引用来自“yong9981”的评论

这个是将操作数据库(包括将来的Redis,NoSql等其它类型的数据库)挪到前端(html页面里)了,再考虑到分库分表、分布式事务、容错、缓存这些功能将来都有可能在前端搞定,还是用Java语言靠谱些。前端连Javascript都能学会,学点Java也不算个事。

引用来自“左华栋”的评论

前后端有各自专注的东西。
如果把后端那套逻辑和思维拿过来的话:
谷歌很早之前就做过尝试了,比如 GWT ,目前这个项目已死,新项目是 Dart 。
当然,kotlin 也可以生成js 来写前端。但都不温不火的。
如果你和我们一样喜欢 AOP 思想,那你可以选择 angular ,生态也十分健全。
如果你只是想用前端去写后端,那选择 prisma.io 没错。
前端未来 是 Typescript 和 Dart 争天下了。
有的需求就不用后端啊,大哥
yong9981
yong9981

引用来自“程序人生2015”的评论

如何保证安全性,任何人都可以删库吧,代码如何重用😬

引用来自“左华栋”的评论

prisma.io 了解下? 比这个靠谱多了

引用来自“yong9981”的评论

想了一下,须要重用的代码可以布置到服务端后用SERV 注明,其它页面引用它的ID即可。

引用来自“yong9981”的评论

prisma.io主要使用Javascript语言,就这一条就可以否决了。服务端还是Java更可靠、强大一些。

引用来自“左华栋”的评论

前端就是 js 啊,不喜欢可以用 ts 。
什么? java ? 这个不需要后端了。

引用来自“yong9981”的评论

这个是将操作数据库(包括将来的Redis,NoSql等其它类型的数据库)挪到前端(html页面里)了,再考虑到分库分表、分布式事务、容错、缓存这些功能将来都有可能在前端搞定,还是用Java语言靠谱些。前端连Javascript都能学会,学点Java也不算个事。

引用来自“左华栋”的评论

前后端有各自专注的东西。
如果把后端那套逻辑和思维拿过来的话:
谷歌很早之前就做过尝试了,比如 GWT ,目前这个项目已死,新项目是 Dart 。
当然,kotlin 也可以生成js 来写前端。但都不温不火的。
如果你和我们一样喜欢 AOP 思想,那你可以选择 angular ,生态也十分健全。
如果你只是想用前端去写后端,那选择 prisma.io 没错。
前端未来 是 Typescript 和 Dart 争天下了。

引用来自“yong9981”的评论

个人认为:任何想在后端运行弱语言编写复杂业务逻辑(Node.js)、任何想用Java操纵界面的(GWT、JSP)尝试,都是不可行的,服务端只能用Java, 前端只能用Javascript。
再谈一下对prisma.io 这类基于GraphQL API的工具的看法
1)GraphQL客户端在一个查询请求中,声明需要的数据结构和字段。这和大前端的开发方式是不一样的,后者不需要声明需要哪些数据,因为后者即是消费者,也是生产者,自已声明自已生产出来的数据格式应该是怎么样的,这属于脱裤子放屁多此一举。
2)GraphQL是个数据接口标准而已,ORM层象是个想象中的玩具,实际不见得好使(对于Java界来说,DAO工具也没有哪个说是完美的)。它不做输入验证、业务逻辑这些事,还是需要第三方语言来实现。而GoSqlGo只是一个简单的远程Ajax原生Java调用而已,没有什么复杂的技术,可以干任何输入验证、业务逻辑、用任意DAO工具存取数据库。
返回顶部
顶部