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

• 資深大佬 : tangkaichuan

  那可能就前端细分了

• 資深大佬 : just1

  小程序云开发？

• 資深大佬 : imdong

  先解决了安全问题再说。

• 資深大佬 : wszgrcy

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

• 資深大佬 : devwolf

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

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

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

• 資深大佬 : yixiang

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

• 資深大佬 : anguiao

  全干工程师

• 資深大佬 : bitmin

  全干不累吗?

• 資深大佬 : superrichman

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

• 資深大佬 : putaozhenhaochi

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

• 資深大佬 : mebtte

  你说的是单机游戏吗?

• 資深大佬 : Jooooooooo

  那不就是后端吗

  少纠结定义问题

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

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

• 資深大佬 : sadfQED2

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

• 資深大佬 : pushback

  当时后端也是这么想的

• 資深大佬 : weakish

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

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

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

• 資深大佬 : weakish

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

• 資深大佬 : EminemW

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

• 資深大佬 : limuyan44

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

• 資深大佬 : SuperManNoPain

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

• 資深大佬 : PiersSoCool

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

• 資深大佬 : imn1

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

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

• 資深大佬 : jackiecao

  后端还能输出前端代码让前端映射呢….
  为什么有后端和前端之分，是因为社会分工不同

• 主 資深大佬 : SystemLight

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

• 主 資深大佬 : SystemLight

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

• 資深大佬 : terax

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

• 資深大佬 : imn1

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

• 資深大佬 : kenshinhu

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

• 資深大佬 : hjiang

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

• 資深大佬 : suzic

  拒绝，太累

• 資深大佬 : charlie21

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

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

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

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

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

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

• 資深大佬 : pecopeco

  serverless→云开发

• 資深大佬 : wellsc

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

• 資深大佬 : cmdOptionKana

  我就问数据库放在哪里？

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

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

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

• 資深大佬 : justin2018

  全干(栈)工程师

• 資深大佬 : mwVYYA6

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

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

  写呀，写呀，写呀……

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

• 資深大佬 : weixiangzhe

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

• 資深大佬 : cmdOptionKana

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

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

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

• 資深大佬 : crclz

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

• 資深大佬 : mrchi

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

• 資深大佬 : xuanbg

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

• 資深大佬 : liveoppo

  类似 Prisma ?

• 資深大佬 : WingOnSummit

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

• 資深大佬 : yeqizhang

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

• 資深大佬 : liuy1994g

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

• 資深大佬 : Shook

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

• 資深大佬 : laminux29

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

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

• 資深大佬 : wangyzj

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

• 資深大佬 : sugarsalt

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

• 資深大佬 : Erroad

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

• 資深大佬 : dartabe

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

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

• 資深大佬 : streamrx

  你可以看看 meteor 这个框架

• 資深大佬 : geebos

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

• 資深大佬 : est

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

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

• 資深大佬 : wmwmajie

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

• 資深大佬 : darknoll

  electron 分前后端吗

• 資深大佬 : murmur

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

• 資深大佬 : cs419

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

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

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