假设前端可以直接操作数据库并且解决了安全问题，还有必要需要后端工程师么？

那可能就前端细分了

小程序云开发？

先解决了安全问题再说。

前端 ui 工程师，前端 crud 工程师

肯定有使用场合限制的吧，能调数据库的后端现在不也没有因为能调数据库而实现大一统嘛。

和#1 说的一样也会细分吧，就好像，好像 UI 和前端的区别？

虽然帖主说的技术栈我都不认识，但是我还是挺期待“前端可以直接操作数据库”的

传统的服务端渲染了解一下？

全干工程师

全干不累吗?

嗨，不就是两份工作合到一起要你干嘛。

社会分工才有了前端工程师

你说的是单机游戏吗?

那不就是后端吗

少纠结定义问题

那我问你, 后端工程师要是能写前端页面是不是就不需要前端了?

另外你操作数据库就不可避免的涉及建模, 性能等等问题, 这不就是后端的工作内容吗?

es 不就可以前端调用嘛，你直接拿 es 做数据库呀

当时后端也是这么想的

不需要。Sqlite 和 LevelDB 不就是前端（客户端）直接操作数据库么？这种场景下确实不需要后端工程师。

如果你把 Excel 也看成数据库的话，那不仅后端工程师不需要了，前端工程师也不需要了。

所以这个问题可以推广为「假设用户可以直接操作数据库并且解决了安全问题，还有必要需要前后端工程师么？」

而且从权限上说，用户和前端工程师没区别，前端可以直接操作数据库基本等价于用户可以直接操作数据库。

时代倒退了吗，这么多年把前后端分离，现在还要走回去？

当然可以啊，如何解决安全问题呢，只需要引入后端。

用户学习 sql 连前端都不用了, 直接连数据库开干他不香么

前端就是后端分出去的，若真要说，那是前端没了，不是后端没了

你这个实际上只是前后端在相同机器，如果在不同机器，那叫做“前端开发人员”同时也做后端的工作

不可能在客户端操作服务端的，sql 语句通过网络传送？

@SuperManNoPain 说实话也不是不行，装个 PHPmyadmin 让用户自己玩去，哈哈。

@imn1 sql 语句通过网络传送，就是因为不能安全传输，所以才假设可以安全传输的基础上，问是否可以。

firebase 了解一下。简单项目确实可以做到不需要“后端”介入，（因为 firebase 帮你做了）。但是一旦复杂之后就会力不从心了

@SystemLight #24
sql 只是一个浅显的小问题，更多是资源调度问题，例如队列满了、线程消耗等等，这些不是客户端可控的事情，服务器端编程，数据传递、展现只是一个部分

后端代码写多了便成了后端工程师

LeanCloud( https://leancloud.cn ) 的数据存储服务解决的就是让前端直接存取数据，不用自己写 API 的问题，用 ACL 来解决安全问题。但是一方面 ACL 需要仔细设计来实现想要的权限管理，另一方面，有的时候你完成一件事需要访问多次数据库，如果都从前端发起就会在互联网上有多个 round-trip，延迟大，还是需要自己写个后端 API endpoint 来一次把事情做完，一次返回结果。所以还是需要后端（对 LeanCloud 来说就是另一个叫云引擎的配套服务）。

拒绝，太累

这位同学的意思是，因为引入了后端 所以引入了安全问题，现在没有后端了，所以也没有了安全问题（比如 用了 firebase 则不需要你去处理安全问题）

抛开安全问题不谈：缓存的问题，肯定是一个要解决的问题；数据库 IO 瓶颈的问题 肯定是一个要解决的问题（解决办法是队列，那么 队列的问题 肯定是一个要解决的问题）；实时通信 肯定是一个要解决的问题；负载平衡 肯定是一个要解决的问题

总之 能带来的更有粒度的控制的，都可能发生一个个需要解决的问题 ... 如果你放弃这块的粒度控制，你就不用去面对这个问题，最后 你也就不需要引入后端了

最后可以参考 no code 方案，连前端工程师都不需要了

v2ex.com/t/692949?p=1#r_9293489 无代码开发的，目前正在创业中，好处很明显：提升生产力，让老板减少成本，扩大效益；缺点是 粒度控制不行，只能做一些没有任何复杂逻辑的东西
v2ex.com/t/729158 低代码，会不会“干掉”开发者？

所谓的低代码或者无代码开发，它并不是空穴来风。大厂也在做这个
https://zhuanlan.zhihu.com/p/60194187
参考 Microsoft Flow，软件工程师都不需要了但只能完成非常有限的工作

serverless→云开发

后端不只是 crud，还有分布式，负载均衡，熔断限流等一大坨东西要考虑的

我就问数据库放在哪里？

如果数据库也放在客户端，那就不是 web，而是单机应用。如果数据库放在后端，这不就需要后端吗？

因此会出现 firebase / severless 服务，但这只不过是将后端外包、转移而已，后端还是真实存在的呀。

所谓的云也一样，外包了很多后端业务出去，但云平台难道不就属于后端的范畴？

全干(栈)工程师

@cmdOptionKana 只是全干工程师的活,变成了前端+学习使用 firebase

用 firebase 自己不用维护数据库服务了，也不用担心后端不配合改接口，几乎不用担心服务器掉线问题，剩下的时间可以用来开发应用。

写呀，写呀，写呀……





开发完功能后，发现国内并不能使用 firestoreUェ*U

不可能 前端就没有安全一说，任何。前端都可能被篡改

@mwVYYA6 小项目学 firebase 和学个后端小框架差别不大，现在后端框架如果只是简单用用，学习成本极低。

大项目谁都不会乐意自己的后端被死死绑定，迁移难度大。

最大的问题是，firebase 只是把后端外包了，后端依然有，只是在别人手里捏着。

安全问题已经解决了，微软的 blazor，小程序的云函数。但是本质上只是前后端耦合加强，并且前后端放在同一个项目里面罢了。该懂的东西还是要懂。

@EminemW 天下大事，分久必合，合久必分：）

时间也不长，就十年前吧。客户端直连数据库的桌面应用不要太多。

类似 Prisma ?

@EminemW 还记得前端图片调用方式的历史不？

那前端就要干设计数据库表，写概要设计写详细设计，对接第三方接口，出接口给第三方干，优化性能提高查询速度，还可能兼职部分运维工作，还得解决测试测出来的接口问题等活……面试的时候还问问这些爽不爽？
前端那就累了……

哈哈哈，然后前端有分成两批人，一批专注写页面，一批专注操作数据库

可是以前不就是这样吗，jsp 啥的。

题主这句话 [假设前端可以直接操作数据库并且解决了安全问题] ，本身就是矛盾的：

1.数据库属于后端。
2.前端直接操作数据库注定不安全。

前端圈 又 再次 更 乱了只能说

天下大势，分久必合，合久必分？

那就会消灭很多前端，前后端分离后很多前端名正言顺地说自己不懂业务、不懂数据建模、不懂部署、甚至不懂 http，只管从接口拿数据塞数据

貌似有个开源的 parse 评价很高

但是数据库设计和优化貌似也是需要技术和经验的

你可以看看 meteor 这个框架

前端不可能解决安全问题的，核心业务逻辑不可能跑在用户的机器上。不管怎么样都需要后端，rpc 也需要后端服务支持，最多是看后端用什么语言而已。

这个差不多 20 年前 c/s 架构就是 LZ 所描述的那样：

1. 客户端直连 SQL 服务器
2. 每个用户分配一个 db 帐号。有不同的表的读 /写 /改权限
3. 业务逻辑跑在 db 通过存储过程、view 、触发器实现，也就是差不多对应 serverless scripts, 一些简单的字段映射，和 定时任务 hook 都支持了

兄弟，你对后端是不是有什么误解？
你真以后后端就只是像大家自嘲似的说做个增删改查就完事了？

electron 分前后端吗

这不是以前客户端年代的设计么

与数据库进行远程通信 本身就是后端行为

起初 用 jsp 动态渲染页面，然后是模板引擎，然后是前后端分离
这不过是分工细化，流水线化
砍掉后端开发人员的环节， 保留远程数据库 不过是责任转移

bs 、cs 架构的服务 server 就是后端
真正的砍掉后端 应该是 没有后端
不使用远程数据库、远程中间件等等
也就是这个服务是一个本地服务 非 bs cs 架构

这不就是以前的 PHP/JSP 一把梭工程师么

笑，这不就是 N 年钱的 PHP 工程师吗？
5 年以前，前端从后端剥离出来，现在又要重新回归融合进后端吗？还是后端融合进前端。

区分前后端的本质是分摊工作，现在 Node 也可以操作数据库啊，但是还不是新划分出一个中台的岗位。