Bun или Node.js: 81% бржи JSON не значи бржи цео API

У HTTP мерењу Webcoderspeed-а Bun је на истом node:http коду обрадио 81% више захтева за велики JSON одговор и 55% више за SHA-256 руту него Node.js, док је кратка текстуална рута била практично изједначена. Предност се односи на пропусност тих рута у условима теста, а не на брзину сваког API-ја који користи Bun.

За продукциони API избор зависи од тога где захтев троши време. Bun има најјачи аргумент када сервис често прави велике одговоре или обавља посао који оптерећује процесор; добитак је мање извесан када преовлађује чекање базе. Уз брзину треба проверити и зависности, телеметрију и могућност повратка на Node.js.

Исти HTTP код открива три различита исхода

Кључна предност HTTP поређења јесте што се мења извршно окружење, а не серверски програм. Текстуална рута враћа кратак одговор, JSON рута прави и серијализује низ објеката, а рута за хеширање обавља процесорски посао пре слања резултата. То су различити трошкови унутар истог обрасца захтева и одговора.

Резултат текстуалне руте тражи посебан опрез: распони поновљених мерења се преклапају, па разлика у средњим вредностима није убедљив добитак. Код JSON и хеш руте предност је јаснија, али тест не обухвата базу, TLS, компресију, више процеса и све зависности које може имати продукциони сервис. Зато је број захтева у секунди користан тек када је познат посао који сваки захтев обавља.

Краткотрајни послови имају другу рачуницу

У засебном мерењу Нилаја Кабарије Bun се покретао око 1,7 пута брже, директно извршавао TypeScript око три пута брже и завршавао исти скуп тестова око пет пута брже од Node.js 24; Node.js је био бржи у тестираној нумеричкој петљи. HTTP резултат није ушао у његов закључак јер је локална мрежа тестне машине ограничавала све испробане сервере.

Време покретања непосредно је важно за једнократне скрипте, командне алате и послове који често отварају нов процес. Дуготрајан API сервер тај трошак обично плаћа при покретању, а не при сваком захтеву. Бржи извршилац тестова може убрзати развој, али не показује како ће се понашати рута која чека упит, позива спољни сервис или обрађује велики одговор.

Када JSON и процесор одређују капацитет

Ако је процесор заузет прављењем и серијализацијом одговора, промена извршног окружења може повећати број захтева које иста инстанца обради. Величина и структура JSON-а су битне: мала порука и велики низ објеката не оптерећују сервер на исти начин. Ни резултат хеш руте не треба пренети на произвољну пословну логику, јер различити рачунски послови могу другачије користити могућности извршног окружења.

За овај профил одлуку носи мерење стварних рута са истим кодом, подацима, бројем процеса и ресурсима. Поред пропусности треба пратити кашњење најспоријих одговора, заузеће процесора и меморију током дужег оптерећења. Прелазак са node:http на Bun.serve може бити засебан избор, али би истовремена промена серверског API-ја помешала утицај нове имплементације са утицајем самог извршног окружења.

Када захтев углавном чека базу

У сервису ограниченом базом бржи JavaScript део скраћује само онај део захтева који се извршава у апликацији. Ако, у условном примеру, захтев проведе 40 милисекунди чекајући базу и 10 милисекунди обрађујући резултат, преполовљена обрада спушта укупно време са 50 на 45 милисекунди. То је користан добитак, али далеко мањи од убрзања самог дела обраде.

Ту је важно раздвојити време упита од чекања слободне везе, рада апликације и слања одговора. Спор упит, неодговарајући индекс или премали скуп веза могу задржати уско грло и после замене извршног окружења. За API чије руте претежно чекају податке, Node.js остаје разумна полазна тачка док мерење стварног сервиса не покаже простор за добитак у обради.

Компатибилност мора да обухвати и надзор

Bun-ова документација о компатибилности описује преостале разлике у Node.js API-јима: код node:diagnostics_channel недостају поједини уграђени канали, а код node:perf_hooks неки догађаји се не емитују. Подршка за AsyncLocalStorage постоји, али се контекст не преноси кроз све врсте радничких догађаја. То су конкретни разлози да се провери и праћење захтева, чак и када функционални одговори изгледају исправно.

Провера миграције почиње од стварног стабла зависности, укључујући посредне пакете. Посебну пажњу заслужују изворни додаци, драјвер базе, пакети који користе унутрашње Node.js API-је и алати за телеметрију. Могућност да се пакет учита не гарантује исто понашање при грешци, прекиду везе, затварању процеса или већем оптерећењу.

Зато интеграциони тестови треба да прођу кроз важне руте и позадинске послове са истим драјверима и сервисима које користи продукција. Упоредите статусе и тела одговора, обраду изузетака и затварање веза; затим проверите да ли трагови, метрике и аларми и даље повезују догађаје са правим захтевом. Губитак те видљивости може бити пресудан и када је мерена пропусност боља.

Подршка и контролисан повратак

Распоред издања Node.js пројекта препоручује Active LTS или Maintenance LTS гране за продукционе апликације и означава Node.js 24 као LTS. Тај јасан циклус одржавања даје полазну основу за постојећи сервис. Bun има смисла у продукцији када добитак на важним рутама оправдава проверу зависности и додатни оперативни посао.

Пробна миграција треба да остави две упоредиве варијанте исте апликације и једноставан пут назад. Редослед провере је следећи:

1. Покрените исти скуп функционалних и интеграционих тестова под оба извршна окружења, укључујући путање са изворним додацима и ретко коришћеним зависностима.
2. Оптеретите важне руте истим захтевима и подацима; пратите кашњење, грешке, процесор и меморију, а не само укупан број обрађених захтева.
3. Потврдите да трагови, метрике, логови и аларми остају употребљиви, па ограничен део саобраћаја усмерите на Bun.
4. Задржите претходну Node.js конфигурацију и поступак враћања спремним ако се појаве функционалне грешке, губитак телеметрије или погоршање кашњења.

Када Bun у таквој проби доследно побољшава руте које одређују капацитет сервиса и зависности раде исправно, миграција има јасан разлог. Када се добитак задржава само у издвојеном тесту, предност има решавање уског грла које се види у стварном захтеву.

Прочитајте и:

• PostgreSQL или MySQL: бржи benchmark не доноси одлуку без истог нивоа изолације
• Upwork или Fiverr у Србији: провизија није цео трошак зараде
• Дуг контекст или RAG: више токена не значи увек бољи одговор