首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

restapi(4)- rest-mongo : MongoDB数据库前端的httpserver

完成了一套标准的rest风格数据库CRUD操作httpserver后发现有许多不足。主要是为了追求“通用”两个字,想把所有服务接口做的更“范generic”些,结果反而限制了目标数据库的特点,最终产生了一套功能弱小的玩具。比如说吧:标准rest风格getbyId需要所有的数据表都具备id这个字段,有点傻。然后get返回的结果集又没有什么灵活的控制方法如返回数量、字段、排序等。特别对MongoDB这样的在查询操作方面接近关系式数据库的分布式数据库:上篇提到过,它的query能力强大,条件组合灵活,如果不能在网络服务api中体现出来就太可惜了。所以,这篇博文会讨论一套专门针对MongoDB的rest-server。我想达到的目的是:后台数据库是MongoDB,通过httpserver提供对MongoDB的CRUD操作,客户端通过http调用CRUD服务。后台开发对每一个数据库表单使用统一的标准增添一套新的CRUD服务。希望如此能够提高开发效率,减少代码出错机会。

02

restapi(8)- restapi-sql:用户自主的服务

学习函数式编程初衷是看到自己熟悉的oop编程语言和sql数据库在现代商业社会中前景暗淡,准备完全放弃windows技术栈转到分布式大数据技术领域的。但是在现实中理想总是不如人意,本来想在一个规模较小的公司展展拳脚,以为小公司会少点历史包袱,有利于全面技术改造。但现实是:即使是小公司,一旦有个成熟的产品,那么进行全面的技术更新基本上是不可能的了,因为公司要生存,开发人员很难新旧技术之间随时切换。除非有狂热的热情,员工怠慢甚至抵制情绪不容易解决。只能采取逐步切换方式:保留原有产品的后期维护不动,新产品开发用一些新的技术。在我们这里的情况就是:以前一堆c#、sqlserver的东西必须保留,新的功能比如大数据、ai、识别等必须用新的手段如scala、python、dart、akka、kafka、cassandra、mongodb来开发。好了,新旧两个开发平台之间的软件系统对接又变成了一个问题。

01

restapi(0)- 平台数据维护,写在前面

在云计算的推动下,软件系统发展趋于平台化。云平台系统一般都是分布式的集群系统,采用大数据技术。在这方面akka提供了比较完整的开发技术支持。我在上一个系列有关CQRS的博客中按照实际应用的要求对akka的一些开发技术进行了介绍。CQRS模式着重操作流程控制,主要涉及交易数据的管理。那么,作为交易数据产生过程中发挥验证作用的一系列基础数据如用户信息、商品信息、支付类型信息等又应该怎样维护呢?首先基础数据也应该是在平台水平上的,但数据的采集、维护是在系统前端的,比如一些web界面。所以平台基础数据维护系统是一套前后台结合的系统。对于一个开放的平台系统来说,应该能够适应各式各样的前端系统。一般来讲,平台通过定义一套api与前端系统集成是通用的方法。这套api必须遵循行业标准,技术要普及通用,这样才能支持各种异类前端系统功能开发。在这些要求背景下,相对gRPC, GraphQL来说,REST风格的http集成模式能得到更多开发人员的接受。

02

restapi(7)- 谈谈函数式编程的思维模式和习惯

国庆前,参与了一个c# .net 项目,真正重新体验了一把搬砖感觉:在一个多月时间好像不加任何思考,不断敲键盘加代码。我想,这也许是行业内大部分中小型公司程序猿的真实写照:都是坐在电脑前的搬砖工人。不过也不是没有任何收获,在搬砖的过程中我似乎发现了一些现象和造成这些现象背后的原因及OOP思维、习惯模式。和大部分IT公司一样,这间公司在行业里存在了一定时间(不是初创)所以在产品和技术方面有一定的积累,通俗点就是一堆现成的c# .net 代码。然后就是项目截止日期压力。为了按时完成任务的我只能在原有代码基础上不断加功能,根本没有机会去考虑用什么样的代码模式、结构去达到更好的效果。在这个过程中有个有趣的现象引起了我的注意:基本上我只需按照某种流程(多数是业务需求)一个个增加环节就可以实现一项完整功能,当然我是不会计较这些环节对软件其它部分是否产生影响,又或者以后代码维护会不会很麻烦,只要能及时交货就行。想想这种做法恰恰是面向对象编程或所谓行令式编程的特点,即:通过逐行执行命令引导程序的状态改变,最终状态就是运行程序的结果了,或者就是功能的实现了。通过一行行增加代码最终总会到达预期的状态,不是吗。这正是OO编程的思维模式:因为程序状态体现在每行代码上,随时可以检查,验证思路,所以OOP比较容易上手(相对函数式编程而言)。

04

【Tomcat】《How Tomcat Works》英文版GPT翻译(第三章)

As mentioned in Introduction, there are two main modules in Catalina: the connector and the container. In this chapter you will enhance the applications in Chapter 2 by writing a connector that creates better request and response objects. A connector compliant with Servlet 2.3 and 2.4 specifications must create instances of javax.servlet.http.HttpServletRequest and javax.servlet.http.HttpServletResponse to be passed to the invoked servlet's service method. In Chapter 2 the servlet containers could only run servlets that implement javax.servlet.Servlet and passed instances of javax.servlet.ServletRequest and javax.servlet.ServletResponse to the service method. Because the connector does not know the type of the servlet (i.e. whether it implements javax.servlet.Servlet, extends javax.servlet.GenericServlet, or extends javax.servlet.http.HttpServlet), the connector must always provide instances of HttpServletRequest and HttpServletResponse.

01
领券