Glossary A–F
Technical terms from A to F — plain English, Excel analogies, and practical context for CA/finance professionals learning to build web apps.
A
API
Plain English: A set of rules that allows two pieces of software to talk to each other and exchange information.
Excel equivalent: A VLOOKUP that reaches across to a completely different file on a completely different computer. Your sheet asks for data, the other sheet responds with exactly what was asked for, in a format both sides understand.
=VLOOKUP(A2, ExternalFile.xlsx!Clients, 3, 0) — except the "external file" is a live service running on someone else's server, and you never open it directly.In practice: When you tap "Pay" in a UPI app, your app talks to your bank's API to check your balance, then talks to the merchant's bank API to transfer money. Three separate software systems communicated via APIs without any human involved. In our projects, the React frontend will call Supabase APIs to fetch and save data.
As a CA managing client portals, you will hear "API" daily — every integration between your portal and a third-party service (GST filing, payment gateway, SMS alerts) runs through one.
Don't confuse with: A website URL. An API endpoint looks like a URL (https://api.example.com/users) but it returns raw data (usually JSON), not a webpage for humans to read.
Authentication
Plain English: Proving who you are. The process of verifying your identity before being allowed into a system.
Excel equivalent: The password you put on an Excel file. You have to prove you know the password before the file opens. Authentication is the moment of proving the password is correct.
In practice: The login screen. When you type your email and password and click "Sign In", that is authentication. Supabase handles this for us — we do not build the verification logic ourselves.
Every client-facing portal you build will have authentication — it is what separates "your clients" from "the entire internet."
Don't confuse with: Authorization. Authentication is "who are you?" Authorization is "what are you allowed to do?" You can be authenticated (logged in) but not authorized (not allowed to access the admin section).
Authorization
Plain English: Once a system knows who you are, authorization controls what you are allowed to see and do.
Excel equivalent: Sheet protection with different permissions. An Excel file where some users can view Sheet 1, others can also edit Sheet 2, and only the admin can access Sheet 3. The file knows who you are and shows you only what you are allowed to see.
In practice: In Udyogaseva (the real app we study), a candidate can see their own applications but not anyone else's. A recruiter can see all applications for their jobs. An admin can see everything. Same app, same login screen — different access based on their role.
Don't confuse with: Authentication. Think of it this way: at a CA firm, authentication is swiping your employee card at the front door. Authorization is whether your card opens the partners' meeting room. Both steps are separate.
B
Backend
Plain English: Everything that happens behind the scenes — storing data, processing business rules, managing who can access what. Users never see this directly.
Excel equivalent: The raw data sheet plus all the formulas, macros, and data connections. The formatted pivot table the partner sees is the frontend. The messy data sheet with thousands of rows and complex formulas powering it is the backend.
In practice: Supabase is our backend. It stores all data in a database, enforces security rules (RLS), and runs business logic (Edge Functions). When a candidate submits a job application, the backend receives it, validates it, stores it, and sends a confirmation email — all without the user seeing any of it.
As a CA building client portals, the backend is where client data lives securely — users interact with a polished frontend but the data and rules live in the backend.
Don't confuse with: Server. The backend runs on a server, but "backend" refers to the software layer and "server" refers to the computer hardware running it. The distinction matters more as you advance.
Branch (Git)
Plain English: A parallel version of your code that you can work on without affecting the main version. When you are done, you can merge your changes back.
Excel equivalent: Making a copy of your Excel model before making major changes — "Model_v2_before_PIE_changes.xlsx". Except Git does this automatically, tracks every change, and can merge your work back into the original without copy-pasting.
In practice: When you build a new feature, you create a branch with a name like add-fee-payment. You work on that branch. When the feature is ready and tested, you merge it into the main branch. If something goes wrong, you throw away the branch — the main code is untouched. This is the standard workflow for every project in this program.
Don't confuse with: A repository. A repository is the whole project. A branch is one parallel version within that project.
Build
Plain English: The process of converting your development code into optimized files that browsers can efficiently run. Think of it as printing the final PDF of a document.
Excel equivalent: Saving a formatted Excel report as a locked, view-only PDF for a client. The source file (your editable Excel) stays behind; the client gets the clean, optimized output.
In practice: You will run npm run build before every production deployment. It takes your React code, combines and compresses it, and produces a dist/ folder with files ready for Vercel to host. Build errors must be fixed before deployment.
Don't confuse with: Deploy. Build creates the files. Deploy puts those files on the internet.
Bundle
Plain English: The single combined file (or small set of files) that contains all your JavaScript code, ready to be sent to a user's browser.
Excel equivalent: A single consolidated workbook that includes all the data, formulas, and formatting from 20 separate source files. Everything the user needs in one place.
In practice: When a user visits your website for the first time, their browser downloads a JavaScript bundle. A large bundle means slow load times. Keeping bundles small is a performance concern we address later in the program.
C
Cache
Plain English: A stored copy of data that was already fetched, kept nearby so it does not need to be fetched again. Trades storage space for speed.
Excel equivalent: A pivot table with "Refresh" disabled. The data is from the last time you refreshed — it might be slightly stale, but it displays instantly because you are not re-querying the source every time you look at it.
In practice: React Query (a library we use) automatically caches data from Supabase. When a user visits the jobs page, React Query fetches job listings and caches them. If the user navigates away and comes back within 5 minutes, they see the cached data instantly — no loading spinner. We configure how long the cache stays fresh (called staleTime).
Don't confuse with: A database. A cache is temporary, in-memory storage for performance. A database is permanent, on-disk storage for all data.
CI/CD
Plain English: Continuous Integration / Continuous Deployment. An automated system that runs checks on your code every time you push changes, and automatically deploys if all checks pass.
Excel equivalent: Imagine having an assistant who, every time you email a new version of your audit workbook, automatically checks all formulas for errors, runs the reconciliation, and if everything is clean, publishes it to the client portal — without you doing any of that manually. That is CI/CD.
In practice: Every project we build will have a GitHub Actions workflow file. When you push code to GitHub, it automatically runs lint checks, TypeScript type checks, and unit tests. If everything passes, it deploys to Vercel. If anything fails, deployment is blocked and you get an email. We set this up so broken code never reaches clients.
Don't confuse with: Manual deployment. CI/CD is the automation that replaces "I'll FTP the files to the server manually and hope nothing breaks."
CLI
Plain English: Command Line Interface. A text-based way to control software by typing commands, instead of clicking buttons in a graphical application.
Excel equivalent: Instead of File → Save As → choose folder → type name → click Save, you type cp report.xlsx /clients/2025/ and press Enter. Same result, one command.
In practice: You will use the CLI constantly. git commit, npm run dev, npx supabase db push — all of these are CLI commands you type in VS Code's terminal. Claude Code itself is a CLI tool. The command prompt demo in the Power of Code module is your introduction to CLI thinking.
Don't confuse with: A terminal. The terminal is the window where you type. The CLI is the interface style (text-based commands). Subtle difference — in daily use you will say "run this in the terminal" interchangeably.
Cloud
Plain English: Someone else's computers, available over the internet, that you rent instead of owning.
Excel equivalent: Google Sheets vs Excel on your laptop. Excel on your laptop only exists on your machine — close the laptop, it is inaccessible. Google Sheets lives on Google's servers (their cloud) — accessible from any device, always on, automatically backed up.
In practice: Supabase (database), Vercel (hosting), GitHub (code storage) — all are cloud services. Your code runs on their computers, not yours. This is why your app stays available 24/7 even when your laptop is off.
Component
Plain English: A self-contained, reusable building block for a user interface. A button, a card, a navigation bar, a form — each is a component.
Excel equivalent: A named, reusable formula or macro. Instead of writing =SUM(B2:B50)*0.18 for GST in every cell, you create a named formula GST_CALC that you reuse everywhere. Change the GST rate once, it updates everywhere.
In practice: In React, a JobCard component displays one job listing — title, company, location, salary. You write it once and reuse it 50 times on the job listings page. When the design changes, you change one file and all 50 cards update. This is one of the most powerful ideas in frontend development.
Don't confuse with: A page. A page is made up of many components. A component is a single, focused UI element. The jobs page contains many JobCard components, a SearchBar component, a FilterPanel component, and a Navbar component.
CSS
Plain English: The language that controls how a webpage looks — colors, fonts, sizes, spacing, layout, animations.
Excel equivalent: All the formatting decisions in Excel — cell background colors, font sizes, bold/italic, borders, column widths, conditional formatting rules. CSS does all of that, but for webpages and with far more power.
In practice: We use Tailwind CSS, which gives you pre-built CSS classes. Instead of writing CSS rules manually, you add class names to HTML elements: className="text-blue-600 font-bold text-lg" and the text turns blue, bold, and large-ish. You will understand this fully in the Frontend + CSS module.
Don't confuse with: HTML. HTML defines the structure (what elements exist). CSS defines the appearance (how those elements look). A button in HTML is just a rectangle with text. CSS makes it blue, rounded, and hoverable.
D
Database
Plain English: An organized system for storing, retrieving, and managing large amounts of data permanently. Unlike files, databases allow thousands of simultaneous users to read and write without data corruption.
Excel equivalent: Imagine an Excel workbook where Sheet 1 is "Clients", Sheet 2 is "Invoices", Sheet 3 is "Payments" — each row is one record, columns are fields. Now imagine that workbook can hold 50 million rows, 10,000 people can edit it simultaneously without conflicts, and complex cross-sheet queries run in milliseconds. That is a database.
In practice: We use PostgreSQL (via Supabase) as our database. Every user profile, student record, attendance entry, fee record, and payment is stored here. The database enforces rules (RLS) about who can see what. We design the database before building the app — the schema is the foundation everything else rests on.
As a CA, your mental model of "clients sheet, invoices sheet, payments sheet" is already the right mental model for database design. The thinking transfers directly.
Don't confuse with: Storage. A database stores structured data (rows and columns). Storage (like Supabase Storage) holds files — PDFs, images, videos. Both are persistent, but they handle different types of content.
Dependency
Plain English: External code that your project relies on. Libraries and packages that someone else wrote, which your code needs to function.
Excel equivalent: An Excel add-in. Your workbook requires the "Power Query" add-in to be installed to work correctly. Without it, certain features break. The add-in is a dependency.
In practice: Your React project has hundreds of dependencies — React itself, Tailwind, Supabase's JavaScript library, React Query, Zod, and many more. They are listed in package.json and installed in a node_modules folder. Running npm install downloads all of them.
Don't confuse with: A library. Every library is a dependency, but not every dependency is a library. Some dependencies are tools (like TypeScript or ESLint) rather than code you import into your app.
Deploy
Plain English: The act of making your application available to users on the internet. Taking code from your computer and putting it on a server.
Excel equivalent: Emailing the final report to a client. You have been working on it locally (your laptop). Deployment is the moment you send it and they can access it.
In practice: We deploy using Vercel. When you push code to GitHub, Vercel automatically detects the change, runs the build, and makes the new version live within about 60 seconds. You get a URL that anyone in the world can visit. There are two environments: staging (for testing) and production (for real users).
Don't confuse with: Build. You build the code first (compile and optimize it), then deploy the built output. Build is preparation; deploy is delivery.
Docker
Plain English: A tool that packages your app along with everything it needs to run (the operating system, language runtime, dependencies) into a portable container. Run it anywhere and it behaves identically.
Excel equivalent: Sharing not just the Excel file but the exact version of Excel, Windows, and all add-ins needed — as one self-contained package. The recipient does not need to worry about compatibility. They just open the package and everything works.
In practice: You will not use Docker directly in this program. Supabase and Vercel handle that complexity for us. It appears here because you will encounter the term in documentation and job descriptions, and understanding it removes confusion.
E
Edge Function
Plain English: A small piece of server-side code that runs on demand, close to where the user is, without you managing any server infrastructure. You write the function, deploy it, and it runs when called.
Excel equivalent: A VBA macro in Excel. You write the macro once. Whenever a button is clicked or a trigger fires, Excel runs the macro automatically. The macro does not run constantly — only when called. Edge Functions work the same way, but on Supabase's servers instead of Excel.
In practice: We use Edge Functions for tasks that must not happen in the browser: sending emails, processing payments (verifying Razorpay signatures), integrating with third-party APIs. In Udyogaseva, there is an Edge Function that verifies Razorpay payment signatures. The client sends a payment ID; the Edge Function calls Razorpay's API to confirm the payment actually happened; if verified, it updates the database. All of this happens on the server — the user never sees it.
Don't confuse with: Frontend code. Edge Functions run on Supabase's servers, not in the user's browser. This is critical for security — API keys used in Edge Functions are never exposed to users.
Environment Variable
Plain English: A piece of configuration (like an API key or a URL) stored outside your code, so the same code can behave differently in different environments without changing any code.
Excel equivalent: Imagine a cell (let's call it $B$1) where you store the GST rate. All your formulas reference $B$1. Change the number once and everything updates. Environment variables work the same way — configuration values stored in one place, referenced by your code. The difference is that these values live in a .env file, not in the code itself, and they are never committed to Git.
GST_RATE that all formulas reference. Change it once and everything updates. Environment variables are that named cell, but for your entire app's configuration.In practice: Your Supabase URL and API key are stored as environment variables: VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY. Your .env file holds the actual values. Your code references import.meta.env.VITE_SUPABASE_URL — the code is the same everywhere, but the value it reads differs between your laptop (development) and Vercel (production).
Don't confuse with: Secrets. All secrets (API keys, passwords) are environment variables, but not all environment variables are secrets. The app's environment (development, production) is also an environment variable but is not sensitive.
Error Boundary
Plain English: A safety net in a React app that catches errors in a section of the UI and shows a friendly error message instead of crashing the entire page.
Excel equivalent: The IFERROR function. Instead of your entire workbook crashing when a formula produces an error, =IFERROR(formula, "N/A") catches the error and shows something reasonable. An Error Boundary does this for React components — if one part of the page breaks, the rest of the page keeps working.
=IFERROR(VLOOKUP(...), "Not found") — instead of a red error cell breaking your report, you get a graceful fallback. Error Boundaries do this for entire UI sections.In practice: We wrap major sections of the app in Error Boundaries. If the job listings section has a bug, the user sees "Something went wrong, please refresh" in that section — but the navigation, search bar, and other sections continue working normally.
F
Frontend
Plain English: Everything the user sees and interacts with. The screens, buttons, forms, charts, and navigation that appear in a browser or on a phone.
Excel equivalent: The formatted, client-facing reporting sheet with pivot tables, charts, conditional formatting, and dropdown menus. It is the layer the end user interacts with — not the raw data behind it.
In practice: We build frontends with React. The frontend runs entirely in the user's browser — on their device, not on any server. It requests data from the backend, displays it, and sends user actions back to the backend. Everything you see at app.udyogaseva.com is the frontend.
Don't confuse with: The entire app. The frontend is one layer. The app also has a backend (Supabase) that the user never directly sees. The frontend is the face; the backend is the brain.
Function
Plain English: A named, reusable block of code that performs a specific task. You define it once and call it by name whenever you need that task done.
Excel equivalent: A formula like =VLOOKUP() or =SUM(). Someone wrote the VLOOKUP function once. You call it by name with inputs (=VLOOKUP(A1, B:C, 2, 0)) and get an output without knowing how the calculation works inside. In code, you create your own custom functions the same way.
=SUM(), =VLOOKUP(), =IFERROR() — you call them by name with inputs and get outputs. In code, you define your own reusable functions with the same pattern.In practice: You will write functions constantly. A function called formatCurrency(amount) might take a number like 25000 and return "₹25,000". Call it from anywhere in your code. Change the formatting once, it changes everywhere. Functions are the single most important concept in all of programming.
Don't confuse with: Edge Functions. A regular function is a block of code within your app. An Edge Function is a special type of function that runs on Supabase's servers (see Edge Function entry).