​
“你们前端算什么？不就是切图仔？”。当后端Leader甩出这句话时，作为前端开发者，我已经在项目中见过无数技术上的争论，但这一次的冲突，真的是让我彻底爆发了。

我先是一愣，紧接着，我直接怒喷了：“你问我前端算什么东西？现在我就告诉你！后端做不了的我前端做，后端做得了的我前端更要做，先斩后奏，CTO特许，这就是前端！ ”

整个会议室静默了几秒，大家的目光都集中在我身上。是的，我当时情绪激动，但实话说，这场冲突背后我真是一点错没有。

😤【事件背景】

需求：
一切都源自我们这个项目的需求——实时消息通知。我们需要实现一个用户可以实时接收设备消息的功能，设备发送的最新信息，用户不需要刷新页面，就能看到新的消息。

前端观点：
作为前端开发者，我自然知道，SSE是最适合的技术。它可以通过一个持久连接推送数据，实时性高，不用频繁请求，节省带宽和服务器资源，尤其适合我们这种需要实时获取信息的场景。
我早早地提出了使用SSE的建议，认为这是最符合需求的技术方案，既能保证用户体验，又不会给服务器带来过大的负担。

后端观点：
后端一听就开始摆出技术顾虑：“SSE不稳定，长连接会带来巨大的服务器压力，万一用户掉线了，怎么恢复？轮询反而更简单、更稳定，服务器也能更容易控制。”
后端的另一个舔狗，似乎觉得前端的需求不过是“小打小闹”，直接说：“你们前端不就是做点页面展示，搞得这么复杂干嘛？们前端总想着搞些花里胡哨的东西。”

后端语录：

“轮询怎么了？微信早期也是轮询！”

“页面加载3秒很慢吗？我们接口200ms返回已经很快了啊！”

“你们整天搞虚拟滚动，不如让用户少发点消息！”

“这个数据为什么没缓存？你们前端不会用localStorage吗？”

无奈妥协：
这种话听得我简直气炸了。可是领导要求尽快上线，我也懒得理他们，再和产品商量了之后，临时采用了每秒轮询一次的做法，尽快上了线。

线上问题：
上线第二天，刚到公司，后端Leader就发来一张服务器告警截图，说请求量爆炸，让我查原因。我一看就知道：轮询导致服务器压力变得越来越大，响应时间也在逐步增加。更糟糕的是，客户端的界面也因此变得越来越卡顿。

爆发冲突：
这时候很讨厌的那个后端舔狗还在旁边一边吃包子一边补刀：“你们前端怎么请求这么频繁，连个请求控制都不会做吗，服务器都快炸了，真服了”。这一句话，直接让我彻底失控了。
我直接说：“你们不是坚持轮询吗？现在又嫌请求频繁，就你们事多，干啥啥不行，吃啥啥不剩！”
后端Leader听到后，直接说：“你们前端算什么东西，不就是切图仔”
这时候我再也不忍了，直接怒喷：“你问我前端算什么东西？现在我就告诉你！后端做不了的我前端做，后端做得了的我前端更要做，先斩后奏，CTO特许，这就是前端！够不够清楚？ ”
眼见事态失控，CTO走了进来说：前端要的实时性是产品生命线，后端的稳定性是商业底线，都闭嘴，先解决问题。

<顺便给看新机会的吆喝一声>

技术大厂，待遇之类的给的还可以，就是偶尔有加班（放心，加班有加班费）
前、后端/测试，多地有空位，感兴趣的可以试试 ~

😓【折中方案】

在一番拉扯过后，我们终于达成了妥协。我坚持要提高用户体验，要求尽量减少轮询的频率并结合一些缓存策略来降低服务器负担；后端则表示愿意优化服务器的性能，准备对SSE进行适当的技术调研，看看是否可以在未来的迭代中支持更高效的长连接。

最终，我们决定：在当前的架构下，采用轮询解决问题，同时为未来的系统升级保留SSE的支持。

😕【技术升级】

两个月后，后端和我一起完成了升级SSE的改造，解决了技术债务。

前端实现（使用 EventSource）
`// 创建 EventSource 实例，连接到后端的 SSE 流
const eventSource = new EventSource(‘http://localhost:8080/sse');

// 处理接收到的消息
eventSource.onmessage = function(event) {
const data = JSON.parse(event.data);
console.log(‘Received message:’, data);
// 在这里处理数据，如更新UI等
updateUI(data);
};

// 监听特定的事件类型
eventSource.addEventListener(‘customEvent’, function(event) {
const data = JSON.parse(event.data);
console.log(‘Received custom event:’, data);
// 对 customEvent 做特定处理
handleCustomEvent(data);
});

// 错误处理
eventSource.onerror = function(event) {
console.error(‘SSE connection error:’, event);
// 可以尝试重连，或做其他处理
};

// 连接关闭
eventSource.onclose = function() {
console.log(‘SSE connection closed’);
};

// 更新UI的函数
function updateUI(data) {
// 假设有一个 DOM 元素显示消息
const messageContainer = document.getElementById(‘messages’);
const messageElement = document.createElement(‘div’);
messageElement.textContent = Message: ${data.message};
messageContainer.appendChild(messageElement);
}

// 特定事件的处理函数
function handleCustomEvent(data) {
// 自定义事件的处理逻辑
console.log(‘Handling custom event:’, data);
}`

后端实现（使用 Java 和 Spring Boot）
`import org.springframework.http.MediaType;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.servlet.mvc.method.annotation.SseEmitter;

import java.io.IOException;
import java.util.concurrent.TimeUnit;

@RestController
public class SseController {

// SSE 端点，向客户端推送消息
@GetMapping(value = "/sse", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public SseEmitter stream() {
    SseEmitter emitter = new SseEmitter();

    // 启动一个后台线程来推送数据
    new Thread(() -> {
        try {
            for (int i = 0; i < 5; i++) {
                // 模拟服务器端发送的数据
                String message = "Message " + (i + 1);
                emitter.send(message);  // 发送消息
                TimeUnit.SECONDS.sleep(1);  // 每秒发送一次
            }

            // 发送自定义事件
            emitter.send(SseEmitter.event().name("customEvent").data("Custom event data"));

            emitter.complete(); // 完成
        } catch (IOException | InterruptedException e) {
            emitter.completeWithError(e); // 错误处理
        }
    }).start();

    return emitter;
}

}`

😕【总结】

前后端思维差异
看似只是一个关于“轮询还是SSE”的争论，背后却折射出了前后端之间深刻的思维差异。前端和后端的工作本质上是对立的：我们前端关注的是用户体验和表现，而后端更关注的是系统性能和稳定性。这种目标的不同导致了我们在技术选型上的分歧。

前端为什么这么生气？
前端开发者习惯了站在用户体验的角度，追求的是尽可能简洁、实时、高效的交互。我们希望用户能够无缝感知到数据的实时变化，而不是等待。

比如，SSE在这类应用中显然比轮询更加符合需求——它能保持连接，实时推送数据，几乎不需要消耗额外的带宽。

后端为何坚持轮询？
后端的思维显然是从稳定性和可控性出发。后端说的也有道理：长连接确实比短连接更容易出问题，尤其是当并发量极高的时候，保持这么多长连接对服务器的压力是巨大的，尤其是在我们当前的架构下。并且，如果连接断开，再恢复，可能会造成消息丢失或同步不及时。
所以，后端选择轮询，从其角度来看，是一种更容易控制和可预见的方案。

🤪【后记】

这些语录不是子弹，而是前后端大战的残骸。当我们把这些对话裱进相框挂在工位，终有一天会笑着回忆：
「当年他骂我菜，我笑他土，如今我们合力搞垮了三个测试环境，这才是真正的战友情！」

（温馨提示：
阅读完毕请深呼吸三次，默念「世界如此美好，我却如此暴躁」，毕竟明天还要联调新接口呢：）

——转载自作者：VeryCool

​