暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

后端Leader放话:“你们前端算个P?”,我直接怒了……

jinchanchanwaji 2025-03-13
15

 

 “你们前端算什么?不就是切图仔?”。当后端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

  

「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论