Runtime environment
Without a runtime, code can’t be run outside a browser.
Examples of runtime environments
Server Engines
A server engine (aka web framework) is a library or tool that helps you build servers easily by managing things like:
Examples of server engines(frameworks)
Full-Stack vs API-First Frameworks
Some of the frameworks are more API focused than others. Meaning they handle routes/api with minimal html rendering.
TL;DR Cheat Sheet
• ✅ Nuxt Plugin → Vue app logic (client/server/SSR setup)
• ✅ Nitro Plugin → Server-only logic for API requests, SSR, headers, middleware
• ✅ Nuxt Module → Tooling + config to extend Nuxt itself (like making your own library or utility)
Build tools
are programs that help prepare your code base for production. There are many build tools based on categories
Reason for build tools? A lot of code we write majority of it is based on a framework (react,vue etc) all the .vue / .jsx / typescript / SCSS we write, still needs to be compiled into plain HTML, CSS and JavaScriptat the end of the day. So, that’s why we need these build tools to do it for us.
Authentication Strategies
*Session-based vs JWT-based vs JWT-cookie based. *
Session based
Mostly handled on the server.
Flow —> when a user logs in (username, password) server checks credentials.
--> If valid, server creates a session which will hold session-id and user-info.
--> The user-info is stored in either DB or memory and the session-id will be set in a cookie and attached to browser(client).
--> Once it’s set, the client will send this cookie automatically on every other request.
--> The server will check the cookie for its session-id to match against user-info, if matches user is authenticated.
JWT-based
Mostly handled on the client.
When a user logs in with credentials (username, password), its sent to server. Server verifies credentials, if valid server generates JWT token and assigns data and secret to it. It then gets sent to client for it to be stored in either localstorage, sessionstorage. For protected routes, the client passes this token in requests through the authorization header (authorization: Bearer ). Lastly, server gets request and verifies the token by the secret to determine access.
JWT with Cookie
Instead of manually storing it in localstorage or sessionstorage the server stores it in a cookie on the client. The browser automatically sends it on every request. No need to manually send it through authorization header.
To be continued ...
More...
- is an environment to run code on the server (outside the browser) this environment has access to file systems, networks request, and ability to create a server. However, it’s tedious to handle api routes/middleware within a runtime environment that’s where Server engines (aka framework) comes into play.
Without a runtime, code can’t be run outside a browser.
Examples of runtime environments
- Node
- Deno
- Bun
- Edge
Server Engines
A server engine (aka web framework) is a library or tool that helps you build servers easily by managing things like:
- HTTP routing
- Parsing requests (body, params, etc.)
- Sending responses
- Middleware
- Error handling
Examples of server engines(frameworks)
- Express (uses node runtime)
- Fastify (uses node runtime)
- Nestjs (uses node runtime)
- Nitro (can use any runtime either node, deno, bun,edge)
- Hono (can use any runtime either node, deno, bun,edge)
Full-Stack vs API-First Frameworks
Some of the frameworks are more API focused than others. Meaning they handle routes/api with minimal html rendering.
- API-First Frameworks:
• NestJS: Primarily API-first, focused on backend logic (APIs, GraphQL, WebSockets, etc.).
• Can serve HTML, but not built for that (not its strength).
• Great for building APIs, often paired with React, Vue, or mobile frontends. - Full-Stack Frameworks:
Full-stack means the framework can handle both frontend rendering (HTML/SSR) and backend API logic.
Examples:
• Next.js: Full-stack React framework with SSR, API routes, and serverless functions.
• Nuxt.js: Full-stack Vue framework with SSR and API routes via Nitro engine (multi-runtime).
TL;DR Cheat Sheet
• ✅ Nuxt Plugin → Vue app logic (client/server/SSR setup)
• ✅ Nitro Plugin → Server-only logic for API requests, SSR, headers, middleware
• ✅ Nuxt Module → Tooling + config to extend Nuxt itself (like making your own library or utility)
Build tools
are programs that help prepare your code base for production. There are many build tools based on categories
| Bundlers | Webpack, Vite, esbuild, Rollup | Combine multiple files into fewer files, often with tree-shaking and code splitting |
| Transpilers | Babel, TypeScript, PostCSS | Convert code from one format or version to another (e.g., ES6 → ES5) |
| Task Runners | Gulp, npm scripts | Automate tasks like minification, image compression, copying files |
| Package Managers | npm, Yarn, pnpm | Manage dependencies and scripts |
| Dev Servers | Vite, webpack-dev-server | Serve your app with hot module reloading (HMR) for development |
Reason for build tools? A lot of code we write majority of it is based on a framework (react,vue etc) all the .vue / .jsx / typescript / SCSS we write, still needs to be compiled into plain HTML, CSS and JavaScriptat the end of the day. So, that’s why we need these build tools to do it for us.
Authentication Strategies
*Session-based vs JWT-based vs JWT-cookie based. *
Session based
Mostly handled on the server.
Flow —> when a user logs in (username, password) server checks credentials.
--> If valid, server creates a session which will hold session-id and user-info.
--> The user-info is stored in either DB or memory and the session-id will be set in a cookie and attached to browser(client).
--> Once it’s set, the client will send this cookie automatically on every other request.
--> The server will check the cookie for its session-id to match against user-info, if matches user is authenticated.
JWT-based
Mostly handled on the client.
When a user logs in with credentials (username, password), its sent to server. Server verifies credentials, if valid server generates JWT token and assigns data and secret to it. It then gets sent to client for it to be stored in either localstorage, sessionstorage. For protected routes, the client passes this token in requests through the authorization header (authorization: Bearer ). Lastly, server gets request and verifies the token by the secret to determine access.
JWT with Cookie
Instead of manually storing it in localstorage or sessionstorage the server stores it in a cookie on the client. The browser automatically sends it on every request. No need to manually send it through authorization header.
To be continued ...
More...