Software Guide

Runtime environment

• 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.

1. 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.

2. 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

Type	Example Tools	What they do
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 (secure) 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 <Token>). 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.

Rendering

SSR —> the html and data is generated on server, per request. User makes a request, server sends back html with data. (Fast speed, better seo)

CSR —> JS renders html and does data fetching on client. So html isn’t rendered until JS is done. User makes a request, server sends back empty.
<div id=“app”></div>
The client then populates the rest (html,data) (slow speed, not good seo)

SSG —> when the app gets built for production, the data and html is generated before hand. This way, the data and html is available to server already when client makes request. (Faster speed, better seo)

Example frameworks that handles this

• Nextjs
• Nuxtjs
• Astro
• Svelte-kit

Web security

CORS —> web security features that restricts your Frontend from making API calls from a different domain. The API server would need to allow access for that frontend to make calls. If CORS is not configured, the API server is accessible to anyone (dangerous).
Same domain —> no Cors needed
FE: https://mycoolapp.com
BE: https://mycoolapp.com/api/posts

Different domain —> Cors need to allow access
FE: https://mycoolapp.com
BE: https://api.mycoolapp.com/posts

HTTPS (Hypertext Transfer Protocol Secure) —> ensures a secure communication between client and server.

Content Security Policy (CSP)
What it is:
A browser feature that lets you control which sources (scripts, styles, images, etc.) are allowed to load on your site.

Why it matters:
It helps prevent Cross-Site Scripting (XSS) and data injection attacks.

Example:

Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com

This means:
• Load resources only from the same origin ('self')
• Scripts only from self or cdn.example.com

OWASP Security Risks

What it is:
A list of the top 10 most critical web application security risks, maintained by OWASP.

Why it matters:
It’s a go-to standard for developers, security teams, and companies to follow best practices.

Examples of OWASP Top 10 Risks (2023):
• Broken Access Control
• Cryptographic Failures
• Injection Attacks (like SQL/XSS)
• Security Misconfiguration
• Vulnerable & Outdated Components

Good practice:
Use the OWASP list to audit your app regularly, especially before launching.

To be continued ...