--- title: "Bun vs. Node.js in Production: A Real-World Performance and Compatibility Breakdown" lang: "en" author: "Mohammad Abu Mattar" canonical: https://mkabumattar.com/post/bun-vs-nodejs-production-performance-comparison --- ![Blog post image for Bun vs. Node.js in Production: A Real-World Performance and Compatibility Breakdown - An honest, benchmark-driven comparison of Bun and Node.js for backend services in 2026. Covers startup time, HTTP throughput, npm compatibility, Docker image size, the memory gotchas nobody warns you about, and when it actually makes sense to migrate.](/_astro/hero.C7RqJDtw_Z1IjBad.webp) [Home](/)›[Blog](/blog)›[All Categories](/blog/categories)›[Backend Development](/blog/categories/backend-development) Blog [Next in Backend DevelopmentCaching Strategies with Redis in Node.js and TypeScript](/blog/post/caching-strategies-with-redis-in-node-js-and-typescript) [Backend Development](/blog/categories/backend-development)[Software Engineering](/blog/categories/software-engineering) # Bun vs. Node.js in Production: A Real-World Performance and Compatibility Breakdown [Mohammad Abu Mattar](/authors/mohammad-abu-mattar)Published: 26 Aug 2026Updated: 29 Aug 202609 Mins read15 Mins listen [Markdown for AI(opens in a new tab)](/post/bun-vs-nodejs-production-performance-comparison/index.md "Open the plain-Markdown version of this page, for pasting into an AI tool") TL;DR An honest, benchmark-driven comparison of Bun and Node.js for backend services in 2026. Covers startup time, HTTP throughput, npm compatibility, Docker image size, the memory gotchas nobody warns you about, and when it actually makes sense to migrate. ### Bun vs. Node.js in Production: A Real-World Performance and Compatibility Breakdown Contents [What makes Bun different from Node.js under the hood?](#what-makes-bun-different-from-nodejs-under-the-hood)[How do the performance benchmarks actually stack up?](#how-do-the-performance-benchmarks-actually-stack-up)[Startup time and serverless cold starts](#startup-time-and-serverless-cold-starts)[HTTP throughput and request handling](#http-throughput-and-request-handling)[Is the npm ecosystem actually compatible?](#is-the-npm-ecosystem-actually-compatible)[Package installation speed](#package-installation-speed)[Can Bun replace your bundler and test runner?](#can-bun-replace-your-bundler-and-test-runner)[What does this mean for Docker image sizes and cold starts?](#what-does-this-mean-for-docker-image-sizes-and-cold-starts)[What are the real-world migration considerations and risks?](#what-are-the-real-world-migration-considerations-and-risks)[When does it make sense to migrate vs. stick with Node.js?](#when-does-it-make-sense-to-migrate-vs-stick-with-nodejs)[Frequently Asked Questions](#frequently-asked-questions)[References](#references) The server-side JavaScript world in 2026 is comfortable with having more than one good option. Node.js has been the reliable workhorse for over a decade: stable, heavily tested, and predictable. Bun changed the conversation around backend performance and developer experience. If you are tired of waiting 45 seconds for a clean install, or fighting cold start latency in your serverless functions, you are probably weighing a migration. So let me break down what using Bun in production actually looks like right now: the benchmarks, the compatibility with the npm ecosystem, and the gotchas you only find once real traffic hits your servers. ## [What makes Bun different from Node.js under the hood?](#what-makes-bun-different-from-nodejs-under-the-hood) The performance differences between Bun and Node.js come straight from their architectures and the languages they are built in. Node.js is written in C++ on top of Google’s V8 engine, the same engine that powers Chrome. V8 is heavily optimized for long-running processes, and its mature Just-In-Time compiler is good at settling computational workloads into fast code over time. Bun took a different path. It is written in Rust and uses Apple’s JavaScriptCore engine, the same one behind Safari. (Bun’s core was originally written in Zig and was rewritten in Rust during 2026, largely for memory safety and a bigger pool of contributors.) JavaScriptCore was designed for fast startup and low baseline memory. Rust gives Bun low-level control over system calls and memory with no garbage collector, and its safety guarantees remove a class of bugs that a lower-level language makes easy to hit. Together that trims the overhead standard library abstractions add to file reads and network I/O. There is also a philosophy difference. Node.js is modular: it gives you the runtime, and you bring your own tooling for package management, testing, and transpilation. Bun is all-in-one. It replaces those separate tools with optimized, built-in equivalents, and it even ships native database clients like `Bun.sql` and `Bun.redis` out of the box. Both run your JS/TS on a browser engine, but the choices differ: Node.js pairs C++ with V8 (tuned for long-running processes) and leans on external tools, while Bun pairs Rust with JavaScriptCore (tuned for fast startup) and bundles the install, test, bundle, and database clients. ## [How do the performance benchmarks actually stack up?](#how-do-the-performance-benchmarks-actually-stack-up) Benchmarks in 2026 show clear lines between where Bun pulls ahead and where Node.js holds its own. ### [Startup time and serverless cold starts](#startup-time-and-serverless-cold-starts) Cold start latency matters most in serverless and CLI tools. Serverless providers bill by execution duration, so faster startup translates directly into lower cost. Node.js 22 usually needs 40ms to 120ms to bootstrap, depending heavily on the size of the dependency tree. When it has to transpile complex TypeScript first, cold starts can push past 250ms. Bun bootstraps in roughly 8ms to 15ms. Because it runs TypeScript natively with no separate compile step, it can process realistic application code in around 18ms. In one real AWS Lambda migration on a high-traffic function, the team watched their average cold start fall from 940ms on Node.js to 290ms on Bun. That 69% latency drop cut their compute bill by about 35%. ### [HTTP throughput and request handling](#http-throughput-and-request-handling) In synthetic benchmarks, Bun’s native HTTP server clearly outperforms the standard Node.js module. Request parsing and response serialization happen in native Rust before any JavaScript runs. Framework & Runtime Requests per Second Average Latency Memory (RSS) **Bun.serve** (Bun native) ~52,400 req/sec 1.9ms 38 MB **Hono** (Bun 1.2) ~48,100 req/sec 2.1ms 42 MB **Fastify 5** (Node.js 22) ~22,800 req/sec 4.4ms 64 MB **Express 5** (Node.js 22) ~11,200 req/sec 8.9ms 71 MB That data reflects a JSON API returning a 200-byte response on an 8 vCPU ARM64 instance. The picture changes once you add realistic database queries and authentication middleware: the throughput gap narrows to a 20% to 30% advantage for Bun in production-grade apps. In other words, once real work is involved, database I/O becomes the bottleneck rather than runtime execution. Here is what the native server looks like. No framework, no dependencies: server.ts ``` 1const server = Bun.serve({2 port: 3000,3 fetch(req) {4 const url = new URL(req.url);5 if (url.pathname === '/health') {6 return new Response('ok');7 }8 return Response.json({message: 'Hello from Bun'});9 },10});11 12console.log(`Listening on http://localhost:${server.port}`); ``` Under the hood, the request never touches JavaScript until it has already been parsed: Bun parses the incoming request in native Rust before your code runs, calls your fetch handler with a standard Request object, then serializes the Response back in native code. Keeping parsing and serialization out of JS is where the raw throughput advantage comes from. ## [Is the npm ecosystem actually compatible?](#is-the-npm-ecosystem-actually-compatible) As of 2026, Bun claims roughly 98% compatibility with the Node.js API and the wider npm ecosystem. Standard frameworks like Next.js, Express, Fastify, and NestJS run out of the box. That last 2% is where enterprise migrations get stuck, though. The gaps sit mostly in specialized core modules and native addons: 1. **Native C++ addons.** Packages that compile C++ bindings for Node.js through `node-gyp` often fail or need a pure-JavaScript fallback. Older versions of `bcrypt` and `sharp`, and some database drivers, land here. 2. **Specific core APIs.** `node:fs` and `node:http` are fully implemented, but edge-case APIs in `node:worker_threads` and `node:inspector` still have known gaps. 3. **Package manager overrides.** Bun still struggles with the complex nested dependency overrides that Yarn Berry and pnpm handle cleanly. To keep dependency trees small, Bun bakes common backend needs into the runtime. Native clients for PostgreSQL, SQLite, S3, and Redis let you drop dozens of third-party packages. A Postgres query looks like this, with no `pg` install: db.ts ``` 1import {sql} from 'bun';2 3const users = await sql`4 SELECT id, email FROM users WHERE active = ${true} LIMIT 105`;6 7console.log(users); ``` Careful here Before you rely on native clients, check that they cover the features you use (connection pooling behavior, prepared statements, listen/notify). “There is a built-in client” is not the same as “it does everything the mature driver does.” ### [Package installation speed](#package-installation-speed) Package installation is where Bun’s advantage is hardest to argue with. Using hard links and optimized system calls, its package manager reshapes CI pipelines. For a heavy monorepo with over 2,300 dependencies, a cold install shows the gap plainly: - **npm:** ~89.4 seconds - **pnpm:** ~21.7 seconds - **Bun:** ~4.1 seconds Bun also moved from a binary lockfile to a text-based `bun.lock`, which fixed a real developer-experience problem: teams can now review dependency changes cleanly in pull requests instead of staring at an opaque blob. Tip You can adopt Bun purely for CI/CD package installation while keeping Node.js as the production runtime. Swapping `npm ci` for `bun install` can cut minutes off deployment pipelines with essentially zero runtime compatibility risk. It is the lowest-risk way to try Bun. ## [Can Bun replace your bundler and test runner?](#can-bun-replace-your-bundler-and-test-runner) The Node.js ecosystem often pushes you into juggling config files for Webpack, Babel, Jest, and TypeScript. Bun collapses that toolchain into one binary. On Node.js you wire together separate tools for installing, testing, bundling, running TypeScript, and talking to databases. Bun ships those as built-in subcommands and native clients, so a new project needs far less configuration to get started. As a test runner, `bun test` is highly compatible with the Jest API: snapshots, mocking, and DOM APIs all work. Because the runner is embedded in the runtime, it is fast. A simple suite that takes Jest 1.2 seconds runs in about 0.08 seconds under Bun. math.test.ts ``` 1import {add} from './math';2import {test, expect} from 'bun:test';3 4test('adds two numbers together', () => {5 const result = add(2, 3);6 expect(result).toBe(5);7}); ``` Whether you migrate your test suite depends on the project. For pure backend TypeScript or Bun-native projects, `bun test` gives you the fastest feedback loop available. For Vite, React, or complex frontend monorepos, Vitest is still the better fit because it plugs directly into the Vite module graph for hot module replacement. ## [What does this mean for Docker image sizes and cold starts?](#what-does-this-mean-for-docker-image-sizes-and-cold-starts) Smaller containers pull faster and start faster. Standard Node.js images often sit around 180MB to 200MB, while the `oven/bun:alpine` and `oven/bun:slim` images typically land between 65MB and 89MB. A repository set up for a clean multi-stage build looks like this: - Directorymy-bun-service/ - Directorysrc/ - index.ts - **Dockerfile** - package.json - **bun.lock** - tsconfig.json The multi-stage build keeps development dependencies and build tools out of the final image: Dockerfile ``` 1# Build stage2FROM oven/bun:1.3-alpine AS build3WORKDIR /app4COPY package.json bun.lock ./5RUN bun install --frozen-lockfile --ignore-scripts6COPY . .7RUN bun run build8 9# Production stage10FROM oven/bun:1.3-alpine AS production11WORKDIR /app12ENV NODE_ENV=production13COPY package.json bun.lock ./14RUN bun install --frozen-lockfile --production15COPY --from=build /app/dist ./dist16EXPOSE 300017CMD ["bun", "run", "./dist/index.js"] ``` The build stage installs everything and produces dist/. The production stage installs only production dependencies and copies dist/ across, so build tools never ship. The result is a 65-89 MB image instead of the usual 180-200 MB Node.js one. Bun also has a `--compile` flag that bundles your whole application and the runtime into a single standalone executable: Terminal window ``` bun build ./src/index.ts --compile --outfile myapp./myapp # no runtime install needed on the target machine ``` That removes the need to install any runtime on the target machine, which is a genuine win for distributing CLI tools. ## [What are the real-world migration considerations and risks?](#what-are-the-real-world-migration-considerations-and-risks) Benchmarks show the upside. Running Bun in production shows the risks, and they cluster around garbage collection and memory. The root of it is the difference between V8 and JavaScriptCore. V8 has spent over fifteen years tuning garbage collection for long-lived, highly concurrent server processes. JavaScriptCore was built for the lifecycle of a single web page in Safari. In high-concurrency workloads, like a Next.js server-side rendering app or an API holding thousands of long-poll WebSockets, Bun has shown unbounded memory growth. Observability is the other rough edge. Many APM and telemetry libraries rely on V8-specific hooks to read heap size and event loop handles. Under Bun, those metrics can report zero or return misleading values mapped from Linux system stats, so you can end up flying blind exactly when you need visibility most. The practical takeaway: profile before you commit. Unsettled HTTP promises and unoptimized closures can exhaust memory under Bun in cases that Node.js quietly forgave. Careful here Do not treat a passing test suite as proof that a long-lived service is safe on Bun. Load-test it for hours, watch RSS over time, and confirm your monitoring reports real numbers before you move production traffic. ## [When does it make sense to migrate vs. stick with Node.js?](#when-does-it-make-sense-to-migrate-vs-stick-with-nodejs) The decision comes down to your project’s requirements and your tolerance for edge cases. Reach for Bun when you are: - **Building serverless.** A 60% to 70% cut in cold starts improves user experience and lowers compute cost at the same time. - **Developing CLI tools.** Native TypeScript execution and single-file executables make distribution much simpler. - **Starting greenfield projects.** New APIs on frameworks like ElysiaJS get high throughput without dragging along legacy Node.js configuration. - **Optimizing CI/CD.** Using `bun install` purely as a package manager is low-risk and high-reward for any codebase. Stick with Node.js when you are: - **Running mission-critical legacy systems.** Heavy reliance on native C++ addons, deep V8 internals, or tangled Webpack setups means the migration friction outweighs the gains. - **Running long-lived, high-concurrency services.** For complex SSR apps or large WebSocket brokers that run for weeks, V8’s mature garbage collector and deep monitoring integrations are worth a lot. - **Working under strict compliance.** Node.js runs under the OpenJS Foundation with clear long-term support policies, which matters in regulated industries. Native C++ addons or deep V8 internals point back to Node.js. Long-lived, high-concurrency services lean Node.js or need careful profiling first. Serverless, CLIs, greenfield APIs, and CI installs are where Bun shines. When in doubt, pilot Bun on CI before touching runtime. Neither runtime is going to make the other obsolete. Node.js keeps adopting modern features, and Bun keeps stabilizing its memory management and edge-case compatibility. Picking one is a matter of matching the tool to the workload, not backing a winner. ## [Frequently Asked Questions](#frequently-asked-questions) For the right workloads, yes. Serverless functions, CLI tools, greenfield APIs, and CI package installation are all solid places to run Bun today. The caution is around long-lived, high-concurrency services, where JavaScriptCore’s garbage collection and weaker observability integrations mean you should load-test and profile before moving production traffic. Yes, and it is the lowest-risk way to adopt Bun. Replacing `npm ci` with `bun install` in CI can save minutes per pipeline while your application still runs on Node.js at runtime. Because you are only using the package manager, there is essentially no runtime compatibility risk. JavaScriptCore starts with a low memory baseline, which is great for cold starts. But its garbage collector was tuned for a browser tab, not a server process running for weeks. Under sustained high concurrency, Bun has shown memory growing without settling, so the same trait that helps startup can hurt a long-lived service. Yes. Bun executes TypeScript and JSX directly, with no separate transpilation step. That is a big part of why its cold starts are so fast, and why `bun test` and `bun run` feel instant compared with running `ts-node` on Node.js. Native C++ addons compiled with node-gyp (older `bcrypt`, `sharp`, some database drivers), a few edge-case `node:worker_threads` and `node:inspector` APIs, complex nested dependency overrides, and observability tooling that expects V8-specific hooks. Standard frameworks like Express, Fastify, NestJS, and Next.js generally run without changes. ## [References](#references) - [Bun documentation](https://bun.sh/docs) - [Bun.serve HTTP server reference](https://bun.sh/docs/api/http) - [Bun SQL (native database client)](https://bun.sh/docs/api/sql) - [`bun test` runner](https://bun.sh/docs/cli/test) - [Single-file executables with `bun build --compile`](https://bun.sh/docs/bundler/executables) - [oven/bun Docker images](https://hub.docker.com/r/oven/bun) - [Node.js documentation](https://nodejs.org/en/docs) - [V8 JavaScript engine](https://v8.dev/) - [JavaScriptCore (WebKit)](https://developer.apple.com/documentation/javascriptcore) - [The Rust programming language](https://www.rust-lang.org/) - [Bun’s rewrite from Zig to Rust (PR #30412)](https://github.com/oven-sh/bun/pull/30412) Was this useful? ## Tags [#Bun](/blog/tags/bun)[#Node.js](/blog/tags/nodejs)[#TypeScript](/blog/tags/typescript)[#Performance](/blog/tags/performance)[#Npm](/blog/tags/npm)[#JavaScript runtime](/blog/tags/javascript-runtime)[#Docker](/blog/tags/docker)[#Serverless](/blog/tags/serverless) ## Share [Facebook](https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmkabumattar.com%2Fblog%2Fpost%2Fbun-vs-nodejs-production-performance-comparison "Share on Facebook")[Twitter](https://twitter.com/intent/tweet/?text=Bun%20vs.%20Node.js%20in%20Production%3A%20A%20Real-World%20Performance%20and%20Compatibility%20Breakdown&url=https%3A%2F%2Fmkabumattar.com%2Fblog%2Fpost%2Fbun-vs-nodejs-production-performance-comparison "Share on Twitter")[LinkedIn](https://www.linkedin.com/shareArticle?mini=true&url=https%3A%2F%2Fmkabumattar.com%2Fblog%2Fpost%2Fbun-vs-nodejs-production-performance-comparison&title=Bun%20vs.%20Node.js%20in%20Production%3A%20A%20Real-World%20Performance%20and%20Compatibility%20Breakdown&summary=An%20honest%2C%20benchmark-driven%20comparison%20of%20Bun%20and%20Node.js%20for%20backend%20services%20in%202026.%20Covers%20startup%20time%2C%20HTTP%20throughput%2C%20npm%20compatibility%2C%20Docker%20image%20size%2C%20the%20memory%20gotchas%20nobody%20warns%20you%20about%2C%20and%20when%20it%20actually%20makes%20sense%20to%20migrate.&source=https://mkabumattar.com "Share on LinkedIn")[WhatsApp](https://wa.me/?text=Bun%20vs.%20Node.js%20in%20Production%3A%20A%20Real-World%20Performance%20and%20Compatibility%20Breakdown%20https%3A%2F%2Fmkabumattar.com%2Fblog%2Fpost%2Fbun-vs-nodejs-production-performance-comparison "Share on WhatsApp")[Telegram](https://t.me/share/url?url=https%3A%2F%2Fmkabumattar.com%2Fblog%2Fpost%2Fbun-vs-nodejs-production-performance-comparison&text=Bun%20vs.%20Node.js%20in%20Production%3A%20A%20Real-World%20Performance%20and%20Compatibility%20Breakdown "Share on Telegram")[Reddit](https://www.reddit.com/submit?url=https%3A%2F%2Fmkabumattar.com%2Fblog%2Fpost%2Fbun-vs-nodejs-production-performance-comparison&title=Bun%20vs.%20Node.js%20in%20Production%3A%20A%20Real-World%20Performance%20and%20Compatibility%20Breakdown "Share on Reddit")[Hacker News](http://news.ycombinator.com/submitlink?u=https%3A%2F%2Fmkabumattar.com%2Fblog%2Fpost%2Fbun-vs-nodejs-production-performance-comparison&t=Bun%20vs.%20Node.js%20in%20Production%3A%20A%20Real-World%20Performance%20and%20Compatibility%20Breakdown "Share on Hacker News")[Pinterest](https://pinterest.com/pin/create/button/?url=https%3A%2F%2Fmkabumattar.com%2Fblog%2Fpost%2Fbun-vs-nodejs-production-performance-comparison&media=&description=An%20honest%2C%20benchmark-driven%20comparison%20of%20Bun%20and%20Node.js%20for%20backend%20services%20in%202026.%20Covers%20startup%20time%2C%20HTTP%20throughput%2C%20npm%20compatibility%2C%20Docker%20image%20size%2C%20the%20memory%20gotchas%20nobody%20warns%20you%20about%2C%20and%20when%20it%20actually%20makes%20sense%20to%20migrate. "Share on Pinterest")[Email]() ## Comments ## You might also enjoy More posts on similar topics [![Setting up Node.js, Express, Prettier, ESLint, and Husky application with Babel and TypeScript - Part 1](/_astro/hero.DKzl3k6w_w3X8j.webp)](/blog/post/setting-up-node-js-express-prettier-eslint-and-husky-application-with-babel-and-typescript-part-1) ## [Setting up Node.js, Express, Prettier, ESLint, and Husky application with Babel and TypeScript - Part 1](/blog/post/setting-up-node-js-express-prettier-eslint-and-husky-application-with-babel-and-typescript-part-1) - [Mohammad Abu Mattar](/authors/mohammad-abu-mattar) - [Backend Development](/blog/categories/backend-development) - [Node.js](/blog/categories/nodejs) - [TypeScript](/blog/categories/typescript) - [Development Setup](/blog/categories/development-setup) - [JavaScript Tooling](/blog/categories/javascript-tooling) Introduction All code from this tutorial as a complete package is available in this repos [#Node.js](/blog/tags/nodejs)[#Express.js](/blog/tags/expressjs)[#TypeScript](/blog/tags/typescript)+9 tags [read more](/blog/post/setting-up-node-js-express-prettier-eslint-and-husky-application-with-babel-and-typescript-part-1) [![The ORM Dilemma: To Use or Not to Use](/_astro/hero.DwvXnAvK_Zoy6I4.webp)](/blog/post/why-not-to-use-orm-in-nodejs) ## [The ORM Dilemma: To Use or Not to Use](/blog/post/why-not-to-use-orm-in-nodejs) - [Mohammad Abu Mattar](/authors/mohammad-abu-mattar) - [Backend Development](/blog/categories/backend-development) - [Node.js](/blog/categories/nodejs) - [Database Management](/blog/categories/database-management) - [Software Architecture](/blog/categories/software-architecture) - [TypeScript](/blog/categories/typescript) Introduction Some decisions shape a project more than others. One that keeps coming back is whether to use an Object-Relational Mapping (ORM) tool for database interactions. Should you skip an ORM [#ORM](/blog/tags/orm)[#Node.js](/blog/tags/nodejs)[#TypeScript](/blog/tags/typescript)+8 tags [read more](/blog/post/why-not-to-use-orm-in-nodejs) [![REST API vs RESTful API: Architecture and Constraints Explained](/_astro/hero.D7ffsaFk_ZsjslT.webp)](/blog/post/rest-api-vs-restful-api-architecture-and-constraints-explained) ## [REST API vs RESTful API: Architecture and Constraints Explained](/blog/post/rest-api-vs-restful-api-architecture-and-constraints-explained) - [Mohammad Abu Mattar](/authors/mohammad-abu-mattar) - [API Development](/blog/categories/api-development) - [Web Architecture](/blog/categories/web-architecture) - [Software Engineering](/blog/categories/software-engineering) - [Backend Development](/blog/categories/backend-development) Introduction REST API and RESTful API get used interchangeably, but they aren't quite the same thing. This post covers the difference, REST's constraints, and what they mean for how you design an [#REST API](/blog/tags/rest-api)[#RESTful API](/blog/tags/restful-api)[#API Design Principles](/blog/tags/api-design-principles)+6 tags [read more](/blog/post/rest-api-vs-restful-api-architecture-and-constraints-explained) [![tRPC: End-to-End Type-Safe APIs in TypeScript Without Codegen](/_astro/hero.DhkOXI-y_wLRX0.webp)](/blog/post/trpc-end-to-end-typesafe-apis) ## [tRPC: End-to-End Type-Safe APIs in TypeScript Without Codegen](/blog/post/trpc-end-to-end-typesafe-apis) - [Mohammad Abu Mattar](/authors/mohammad-abu-mattar) - [Web Development](/blog/categories/web-development) - [Backend Engineering](/blog/categories/backend-engineering) The line between the frontend and the backend has always been a place where types go to die. In a normal REST setup you define the shape of a request and a response on the server, then you write those [#TRPC](/blog/tags/trpc)[#TypeScript](/blog/tags/typescript)[#Node.js](/blog/tags/nodejs)+4 tags [read more](/blog/post/trpc-end-to-end-typesafe-apis) [![Setting up Node JS, Express, MongoDB, Prettier, ESLint and Husky Application with Babel and authentication as an example](/_astro/hero.C-0XrT7F_1bXKFs.webp)](/blog/post/setting-up-node-js-express-mongodb-prettier-eslint-and-husky-application-with-babel-and-authentication-as-an-example) ## [Setting up Node JS, Express, MongoDB, Prettier, ESLint and Husky Application with Babel and authentication as an example](/blog/post/setting-up-node-js-express-mongodb-prettier-eslint-and-husky-application-with-babel-and-authentication-as-an-example) - [Mohammad Abu Mattar](/authors/mohammad-abu-mattar) - [Backend Development](/blog/categories/backend-development) - [Node.js](/blog/categories/nodejs) - [JavaScript](/blog/categories/javascript) - [Development Setup](/blog/categories/development-setup) - [API Development](/blog/categories/api-development) Introduction All code from this tutorial as a complete package is available in this repository. If you find this tutorial helpful, please share i [#Node.js](/blog/tags/nodejs)[#Express.js](/blog/tags/expressjs)[#MongoDB](/blog/tags/mongodb)+11 tags [read more](/blog/post/setting-up-node-js-express-mongodb-prettier-eslint-and-husky-application-with-babel-and-authentication-as-an-example) [![Edge Computing: AWS Lambda@Edge vs. Cloudflare Workers. A Practical Guide](/_astro/hero.B0zsiQ7F_fcrYL.webp)](/blog/post/edge-computing-aws-lambda-at-edge-vs-cloudflare-workers-practical-guide) ## [Edge Computing: AWS Lambda@Edge vs. Cloudflare Workers. A Practical Guide](/blog/post/edge-computing-aws-lambda-at-edge-vs-cloudflare-workers-practical-guide) - [Mohammad Abu Mattar](/authors/mohammad-abu-mattar) - [Edge Computing](/blog/categories/edge-computing) - [AWS Lambda](/blog/categories/aws-lambda) - [Cloudflare](/blog/categories/cloudflare) - [Serverless](/blog/categories/serverless) The digital world keeps changing, and so do the demands on our apps and services. We all expect instant responses, smooth experiences, and things to just work, no matter where we are. This constant pu [#AWS Lambda@Edge](/blog/tags/aws-lambdaedge)[#Cloudflare Workers](/blog/tags/cloudflare-workers)[#CDN](/blog/tags/cdn)+3 tags [read more](/blog/post/edge-computing-aws-lambda-at-edge-vs-cloudflare-workers-practical-guide) 6 related posts