Golang Go语言中前后端分离趋势下为何很多开源项目仍是前后端一起？是我理解有误吗？
Golang Go语言中前后端分离趋势下为何很多开源项目仍是前后端一起？是我理解有误吗？
下面是我在学习的两个项目，好像都是前后端一起的 https://github.com/hezhizheng/repo-image-hosting https://github.com/cloudreve/Cloudreve
更多关于Golang Go语言中前后端分离趋势下为何很多开源项目仍是前后端一起？是我理解有误吗？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
一个三十多⭐️的项目说明不了什么
更多关于Golang Go语言中前后端分离趋势下为何很多开源项目仍是前后端一起？是我理解有误吗？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
前后端分离我不清楚你说的是哪种，我猜一下：
1.前后端相同的语言开发栈，用后端框架渲染。简单需求时，无需用高射炮打蚊子
2.前后端不同的语言开发栈，打包在一起分发，一键执行。给用户带来部署上的便利
好多开源项目 X
换个语言写的 CRUD 业务代码 O
我也不是很明白题主说的这两个项目用 golang 有什么意义，
而且 github 上的个人维护的中文项目好像不太值得你花时间的样子。
上面说的搜索引擎的…本身 spa 就不利于 seo…想要一个好的效果, 那就 ssr 呀, 而且大部分情况下, 都是搜出主站主页, 把这个页面做 ssr 就好了
第一个不清楚，第二个选用 Golang 的原因是基于以下需求：
1.跨平台交叉编译方便；
2.编译后产生的 binary 无其他链接库依赖，能做到 click-to-run ；
3.异步编程方便，Cloudreve 会有大量的任务需要异步处理；
4.有成熟且简洁的 web 框架。
最终选择了 Golang ，当然你可以说这只是一个 preference 的问题。
另外 Cloudreve 的前后端分离不是那么彻底，比如：前端资源嵌入后端的 binary ；对于 index.html 的请求还是会经后端类似“模板渲染”的处理，但这些妥协其实都是为了能做到 click-to-run.
首先 所有框架 都可以输出 json 和 html ，如果你需要前后分离，返回 json 即可；如果不需要输出 html 即可；不用特别纠结，我们就用代 UI 的框架作为接口层，没啥问题。
前后端分离跟在不在一起没影响，不是非的分两个仓库才是分离。
我还见过有些 go 为了部署方便会把前端也给一起打包二进制去，但是这跟分离不分离也没关系。分离是从开发和数据获取渲染的角度分而不是部署的时候分开
你用模板引擎，做 server 端渲染，返回 html 就不是；
你只写 api ，例如用 DRF ，前端用其他框架做的就是
模板引擎还是有生存的空间，并不是所有的 web 都需要做成 SPA 的
在Golang（Go）语言中，前后端分离已成为一种趋势，这种模式下，前端负责展示用户界面和交互逻辑，后端则专注于处理数据和业务逻辑。然而，确实存在一些开源项目仍然采用前后端一起的方式，这可能是由以下原因导致的：
- 项目历史与遗留问题：一些开源项目有着较长的历史，早期可能没有采用前后端分离的技术架构。随着项目的不断发展和维护，尽管技术上可以进行重构以实现前后端分离，但由于各种原因（如兼容性、稳定性、开发成本等），项目团队可能选择保持现有的架构。
- 特定需求与简化部署：对于某些特定类型的项目，如小型应用或原型设计，前后端一体的架构可能更便于快速开发和部署。此外，一些项目可能更注重用户体验或开发效率，而不是技术上的最优解。
- 开发者习惯与团队结构：开发者的个人习惯和团队结构也可能影响项目的架构选择。一些开发者可能更熟悉前后端一体的开发方式，或者团队中的成员可能更擅长某一方面的技术，从而导致项目采用特定的架构。
因此，虽然前后端分离是当前的流行趋势，但并非所有开源项目都必须遵循这一模式。选择何种架构取决于项目的具体需求、历史背景、团队结构等多种因素。
