Beginner Guide · Full-Stack · Glossary
Full-Stack Development Glossary — Key Terms Explained
Quick summary — the full-stack glossary
Full-stack development has its own vocabulary, and most beginner frustration comes from not knowing the words — not from not understanding the concepts. This glossary covers the terms you will actually hear in a job description, an interview, or a pull request, grouped by frontend (what users see), backend (what powers the app), databases (where data lives), and DevOps (how it ships). Each term has a plain-English definition plus a one-line "why it matters" so you understand it in context, not just as a definition. If you are preparing for an interview, read the frontend and backend sections first — they cover the majority of what junior full-stack interviews probe.
In this glossary you will find:
- Frontend terms — HTML, CSS, DOM, React, bundlers, state.
- Backend terms — APIs, REST, GraphQL, auth, middleware.
- Database terms — SQL, NoSQL, schema, indexes, ORMs.
- DevOps terms — Git, CI/CD, Docker, Kubernetes, cloud.
- Interview terms — the words that come up most in junior interviews.
SECTION 01Frontend terms
Frontend is what users see and interact with. These are the terms you will hear most often in a frontend or full-stack interview.
| Term | Plain English | Why It Matters |
|---|---|---|
| HTML | The structure of a page — headings, paragraphs, buttons | Every frontend starts here; it is not a "programming language" |
| CSS | How the page looks — colours, spacing, layout | Design to implementation bridge |
| JavaScript | The language that makes the page interactive | Every modern frontend framework is built on JS |
| DOM | The browser's representation of the page as a tree of elements | You manipulate the DOM (directly or via a framework) to change the UI |
| Component | A reusable piece of UI — a button, a card, a whole page | Core building block in React, Vue, Angular |
| State | The data a component is currently holding — user input, loading flags | When state changes, the UI re-renders |
| Props | Data a parent passes down to a child component | React's primary way of passing data |
| Hook | A function that lets you use React features inside components (like useState, useEffect) | Core to modern React; interviewers probe them |
| SPA | Single Page Application — one HTML file, navigation handled in JS | Most modern apps are SPAs; affects routing and SEO strategy |
| Bundler | A tool that packages your JS/CSS into files the browser can load efficiently | Vite, Webpack, Parcel — you will use one in every project |
| Responsive design | UI that adapts to screen size — phone, tablet, desktop | Table stakes; every job description mentions it |
| Accessibility (a11y) | Designing UIs usable by people with disabilities | Increasingly required; simple checks like alt text and contrast |
SECTION 02Backend terms
Backend is what powers the app — the server, the APIs, the business logic. These are the terms that come up in every full-stack interview.
| Term | Plain English | Why It Matters |
|---|---|---|
| Server | A computer (or process) that listens for requests and sends back responses | Everything backend runs on a server |
| API | Application Programming Interface — a defined way for two programs to talk | Frontend and backend communicate via APIs |
| REST | A style of API using HTTP verbs (GET, POST, PUT, DELETE) and URLs | Most common API style; every full-stack interview probes it |
| GraphQL | An API style where the client asks for exactly the fields it wants | Growing in popularity; useful for complex UIs |
| Endpoint | A specific URL that performs a specific action (e.g., /api/users) | Every REST API is a set of endpoints |
| Authentication | Proving who you are — usually via login | Every user-facing app has it |
| Authorization | What you are allowed to do — admin vs regular user | Often confused with authentication; interviewers test the distinction |
| JWT | JSON Web Token — a signed token the client sends to prove identity | Common auth strategy; you will implement it in almost every project |
| Session | Server-side state that tracks a user across requests | Alternative to JWT; both appear in interviews |
| Middleware | A function that runs between a request and the route handler — auth checks, logging, etc. | Core pattern in Express, Django, and every backend framework |
| Environment variable | A config value (API keys, DB URL) passed to the app at runtime | Essential for security — never hard-code secrets |
| CORS | A browser security rule that blocks some cross-origin requests | Every frontend calling a different backend hits this |
SECTION 03Database terms
Databases are where the app's data lives. These terms appear in almost every full-stack role, regardless of which database the team uses.
| Term | Plain English | Why It Matters |
|---|---|---|
| SQL | Structured Query Language — the language for relational databases | MySQL, PostgreSQL, SQLite — all use SQL |
| NoSQL | Non-relational databases — flexible schema, often document-based | MongoDB, Firebase — used for many modern apps |
| Table / Collection | Where rows of data live in SQL (table) vs document groups in NoSQL (collection) | Basic mental model of where data sits |
| Schema | The structure of your data — columns, types, relationships | Bad schema design is expensive to fix later |
| Primary key | The unique identifier for a row | Every well-designed table has one |
| Foreign key | A column that references a row in another table | How tables relate; how data stays consistent |
| Index | A data structure that speeds up lookups | Missing indexes cause slow queries under load |
| Query | A request for data — a SELECT statement, or a Mongo find | What every backend does dozens of times per request |
| Transaction | A group of operations that must all succeed or all fail | Essential for payments and anything money-related |
| ORM | Object-Relational Mapper — lets you talk to SQL via code instead of raw queries | Prisma, Sequelize, SQLAlchemy; common in full-stack jobs |
| Migration | A versioned change to the database schema, tracked in code | How schema changes get reviewed and deployed safely |
| Normalization | Structuring data to avoid duplication (but sometimes overkill) | Trade-off between strict structure and query simplicity |
SECTION 04DevOps terms
DevOps is how the app gets from "code on a laptop" to "running for users". Even if you are a full-stack developer, you will use these tools daily.
| Term | Plain English | Why It Matters |
|---|---|---|
| Git | Version control — tracks changes to your code | Non-negotiable; every job expects it |
| GitHub / GitLab | Online hosts for Git repositories | Where your code lives; used for collaboration and CI |
| Branch | A parallel copy of the code, used for a feature or fix | The foundation of how teams review code |
| Pull request | A proposed change reviewed by teammates before merge | Every full-stack job will require you to open and review PRs |
| CI/CD | Continuous Integration / Continuous Deployment — automated build, test, and deploy on every change | How modern teams ship; often the first interview probe on DevOps |
| Docker | Packages an app with its dependencies into a container that runs anywhere | The standard for dev and production environments |
| Container | A running instance of a Docker image | Isolated, reproducible runtime |
| Kubernetes | An orchestration system for running many containers | Required for scaling; usually a mid-level skill, not junior |
| Cloud | AWS, GCP, or Azure — where most apps actually run | You will deploy to one of these; basic familiarity is expected |
| Staging | An environment that mirrors production, used for pre-release testing | Where you test before users see the change |
| Production | The live environment users actually access | Every deploy targets it; mistakes here affect real users |
| Environment | A specific setup of the app — development, staging, production | Config changes per environment; secrets do not move between them |
SECTION 05Interview terms
These terms are specifically tested in full-stack interviews. Knowing them well moves you from "candidate who has used tools" to "candidate who understands engineering".
| Term | Plain English | Interview Context |
|---|---|---|
| Client vs Server | Client = the app in the browser; server = the machine handling requests | The mental model behind every full-stack question |
| Request / Response | Client sends a request; server sends a response | Explain what happens when a user clicks a button |
| HTTP methods | GET, POST, PUT, DELETE — the verbs of REST | Choosing the right verb is a common interview question |
| HTTP status codes | 200 (OK), 201 (Created), 400 (Bad Request), 401 (Unauthorized), 500 (Server Error) | Knowing the difference between 401 and 403 impresses interviewers |
| Idempotent | An operation that gives the same result if repeated | GET, PUT, DELETE are idempotent; POST is not — a common question |
| JSON | The default format for API data | Almost every API you build or consume uses it |
| Callback / Promise / async-await | Three ways of handling asynchronous code in JavaScript | Interviewers test whether you understand promises and event loop basics |
| Event loop | How JavaScript handles async tasks in a single thread | A common senior-level question; juniors should know the basics |
| Clean code | Readable, maintainable code — sensible names, small functions, clear structure | Interviewers judge your code style, not just whether it runs |
| Technical debt | The cost of shortcuts taken to ship faster, which must be paid back later | Hiring managers appreciate when you can name trade-offs |
SECTION 06Common confusions
Some terms are frequently mixed up. Knowing the difference is itself a signal in interviews.
| Confusion | The Difference |
|---|---|
| Framework vs Library | A library gives you tools (React); a framework calls your code (Angular). React is often described as "a library" because you control the flow. |
| Authentication vs Authorization | Authentication = "who are you?" Authorization = "what are you allowed to do?" Both are different steps in login. |
| State vs Props | State = data the component owns. Props = data passed in from the parent. You can change state; you cannot change props. |
| SQL vs NoSQL | SQL = relational, strict schema, ACID transactions. NoSQL = flexible schema, often document-based, horizontal scaling. |
| Container vs VM | A container shares the host OS kernel; a VM has its own OS. Containers are lighter and faster to start. |
| CI vs CD | CI = continuous integration (automated build + test). CD = continuous delivery or deployment (automated release). Usually both together. |
SECTION 07Interview Q&A — glossary terms
Q1What is the difference between state and props in React?
State is data the component owns and can change (via
useState or similar). Props are data passed in from
a parent and are read-only inside the child. State changes
trigger a re-render; changing props requires the parent to pass
new props. A common interview probe — answer clearly and with
an example.
Q2What is the difference between authentication and authorization?
Authentication is about identity — verifying who you are (login). Authorization is about permission — what you are allowed to do once you are logged in. Authentication answers "who are you?"; authorization answers "what can you do?". In a typical web app, authentication happens first, then authorization checks decide which routes and data a user can access.
Q3What does CI/CD actually mean?
CI (Continuous Integration) means every code change is automatically built and tested, catching issues early. CD (Continuous Delivery or Deployment) means every passing change is automatically released to staging or production. Together, they replace manual deploy steps with a repeatable pipeline. Every modern full-stack team uses some version of this.
Q4When would you choose SQL over NoSQL?
Choose SQL when your data has clear relationships, you need ACID transactions (payments, bookings), or your queries will involve complex joins. Choose NoSQL when your schema is evolving fast, you need to store nested documents, or you need horizontal scaling for very large volumes. Most full-stack apps still use SQL as the default, with NoSQL for specific use cases.
Q5What is a pull request, and why does it matter?
A pull request (PR) is a request to merge your branch into the main branch, with the change shown as a diff. Teammates review it, leave comments, and approve or request changes before it merges. PRs are how modern teams review code, catch bugs before they reach main, and keep the codebase healthy. Understanding how to open, review, and respond to PRs is a basic expectation in every full-stack role.
SECTION 08Test yourself — full-stack glossary
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 09Frequently asked questions
What are the most important full-stack terms to learn first?
Start with the difference between client and server, what an API is, HTTP methods and status codes, and the difference between state and props (if you are learning React). Those five terms cover the foundation of almost every conversation about full-stack development.
Do I need to memorise all these terms for a job interview?
You do not need to memorise definitions. You need to be able to explain each term in your own words and, for the top 20 or so, give an example from your own code. Memorised definitions sound rehearsed; explanations in your own words sound like someone who has used the tool.
What is the difference between a framework and a library?
A library gives you functions you call (React). A framework calls your code, controlling the flow (Angular). React is often called a library because you control the render; Angular is called a framework because it decides what runs when. The line is fuzzy in practice, but interviewers still like hearing the distinction.
Is Kubernetes required for a full-stack role?
For junior roles, not usually. For mid-level roles at companies with production infrastructure, familiarity with Docker is expected and Kubernetes is often a plus. Know Docker first, then learn the basics of Kubernetes once you have a real deployment to deploy.
How do I keep up with new full-stack terms?
Follow a small set of sources — official docs of tools you actually use, one or two newsletters, and the changelogs of your stack. Do not chase every new term that appears on Twitter. Depth in the terms you use daily matters more than breadth in every new acronym.
SECTION 10Related reads
Classroom & online · Noida
Learn full-stack — with Uncodemy
Our Full-Stack Development Course covers the whole stack — HTML, CSS, JavaScript, React, Node, Express, MongoDB, and Docker — with the vocabulary built in, so you can explain your work in interviews.
₹32,000 · full programme- Frontend + backend + databases
- React + Node + MongoDB
- Docker + CI/CD basics
- Weekday & weekend batches