Help
Options
Didn't know it?
click below
click below
Knew it?
click below
click below
Don't Know
Remaining cards (0)
Know
retry
shuffle
restart
0:00
Embed Code - If you would like this activity on your web page, copy the script below and paste it into your web page.
Normal Size Small Size show me how
Normal Size Small Size show me how
Development Terms
| Question | Answer |
|---|---|
| Source Code | Human-readable instructions that make up a program. Everything in your monark-widget and monark-admin folders is source code. Computers can't run it directly — it needs to be processed first. |
| Compiler / Build Tool | Takes your source code and turns it into something a computer can actually run. For React, Vite does this — it takes your JSX files and produces plain HTML/CSS/JS that browsers understand. |
| Runtime | The environment where code actually executes. Node.js is a runtime — it's what lets JavaScript run on a server instead of just in a browser. |
| Dependencies | Other people's code your project relies on. When you run npm install, you're downloading all your dependencies. React, Express, Axios, Prisma are all dependencies. They live in the node_modules folder. |
| Package Manager (npm) | The tool that manages dependencies. npm install downloads them, package.json lists which ones your project needs and what versions. |
| JavaScript | The programming language everything in your stack is written in. Runs in browsers natively, and on servers via Node.js. |
| TypeScript | A superset of JavaScript that adds static typing. It catches bugs at write-time rather than runtime. You may see .ts and .tsx files in other projects. Your project uses plain JavaScript but devs may migrate it. |
| JSX | A syntax extension for JavaScript used in React. Lets you write what looks like HTML inside JavaScript files. Your .jsx files use this. Vite converts it to regular JavaScript before the browser sees it. |
| HTML | HyperText Markup Language. Defines the structure of a web page — headings, paragraphs, buttons, forms. Every website starts with HTML. |
| CSS | Cascading Style Sheets. Controls the visual appearance of HTML elements — colours, fonts, layout, spacing. |
| SQL | Structured Query Language. The language used to talk to relational databases like Postgres. Prisma generates and runs SQL for you behind the scenes. |
| React | A JavaScript library for building user interfaces. Instead of manually updating the page when data changes, you describe what the UI should look like and React figures out the updates. |
| Component | The building block of a React app. A reusable piece of UI — a button, a form, a whole page. Scanner.jsx, Shell.jsx, BrainRow.jsx are all components. |
| Props | Short for properties. How you pass data into a React component from its parent. Like function arguments for components. |
| State | Data that lives inside a component and can change over time. When state changes, React re-renders the component. useState is the React hook for managing state. |
| Hook | A special React function that lets you use React features inside functional components. useState manages state, useEffect runs code when something changes, useContext reads from a context. |
| useEffect | A React hook that runs side effects — code that should run after the component renders or when a dependency changes. Commonly used for fetching data, setting up subscriptions, or syncing with external systems. |
| useRef | A React hook that holds a mutable value that doesn't cause re-renders when changed. Often used to reference a DOM element directly (e.g. focusing an input) or to store a value that persists across renders without triggering UI updates. |
| Context | React's way of sharing data across many components without passing props through every level. Your AuthContext, StoreContext, and WSContext use this so any component can access the data. |
| React Router | A library that handles navigation in a React app. Maps URLs like /scanner or /brain-list to specific components. Makes a single-page app feel like it has multiple pages. |
| Single Page Application (SPA) | A web app that loads one HTML page and dynamically updates content using JavaScript instead of loading new pages from the server. React apps are SPAs. Faster and more app-like. |
| DOM (Document Object Model) | The browser's representation of a web page as a tree of elements. JavaScript can manipulate it to change what's on screen. React manages the DOM for you. |
| Virtual DOM | React's trick for performance. Instead of updating the real DOM directly (slow), React keeps a lightweight copy in memory, calculates what changed, and only updates the parts that need to change. |
| Re-render | What happens when React updates a component's output in response to a state or prop change. Happens automatically. Understanding when re-renders happen (and when to avoid unnecessary ones) is key to React performance. |
| Controlled Component | A form input whose value is driven by React state. Every keystroke updates state, and state drives what's displayed. Contrast with uncontrolled components where the DOM holds the value. |
| Conditional Rendering | Showing or hiding parts of the UI based on a condition. Common in React: {isLoading && <Spinner />} or {user ? <Dashboard /> : <Login />}. |
| Key Prop | A special React prop used in lists to help React identify which items changed, were added, or removed. Required when rendering arrays of components. Bad keys cause bugs; good keys (unique IDs) keep things performant. |
| Node.js | A runtime that lets JavaScript run outside the browser — on a server. Your Express API runs on Node.js. It's what makes it possible to use one language for both frontend and backend. |
| Vite | A build tool and development server for frontend projects. In development it serves files instantly with hot module replacement. For production it bundles everything into a dist/ folder. |
| Hot Module Replacement (HMR) | When you save a file during development, the browser updates instantly without a full page reload. Vite does this automatically — you've seen it every time you save a .jsx file. |
| Concurrently | An npm package that lets you run multiple commands at the same time in one terminal. Your monark-widget project uses it to start the React frontend, Express server, and WebSocket bridge all at once with npm run dev. |
| package.json | A file at the root of every Node.js project. Lists the project name, version, all dependencies, and scripts (like npm run dev). The first file to check when understanding a new project. |
| node_modules | The folder where npm downloads all your project's dependencies. Never committed to Git (it's in .gitignore) — anyone cloning the repo runs npm install to recreate it. |
| .env File | A local file for environment variables. Lists things like DATABASE_URL, JWT_SECRET, and VITE_API_URL. Never committed to Git. Each developer has their own, and each environment (staging, prod) has its own equivalent. |
| Linter / ESLint | A tool that statically analyzes your code for potential bugs, bad patterns, or style inconsistencies. Catches things like unused variables or incorrect React hook usage before you even run the code. |
| Express | A minimal web framework for Node.js. It powers your API server — handling routes like GET /api/orders/:id, middleware like authentication, and sending responses back to the client. |
| API (Application Programming Interface) | A defined set of rules for how two systems talk to each other. Your Express server exposes an API — a collection of URLs (endpoints) that the React frontend calls to get or save data. |
| REST API | A common style for designing APIs using HTTP. Uses standard methods: GET to read, POST to create, PUT/PATCH to update, DELETE to remove. Your server follows REST conventions. |
| Endpoint | A specific URL in your API. GET /api/orders/7577471 is an endpoint. Each endpoint does one specific thing. |
| Middleware | Functions that run between a request arriving and a response being sent. Your auth.js checks the JWT token on every protected route. Morgan logs requests. Helmet sets security headers. |
| Route Handler | The function that runs when a specific endpoint is hit. Takes the request object (req) and response object (res), does its work, and sends back a response. |
| Request / Response Cycle | The fundamental pattern of the web. A client sends a request (GET /api/orders/123), the server processes it, and sends back a response (200 OK with order data). Every API call follows this pattern. |
| Status Code | A number in an HTTP response indicating the outcome. 200 = OK. 201 = Created. 400 = Bad Request (your fault). 401 = Unauthorized. 403 = Forbidden. 404 = Not Found. 500 = Server Error (our fault). |
| JSON (JavaScript Object Notation) | The standard format for sending data between a frontend and backend. A plain text representation of JavaScript objects. Your API sends and receives JSON for almost everything. |
| Axios | A JavaScript library for making HTTP requests. Your api/client.js uses it to call your Express server from the React frontend. |
| JWT (JSON Web Token) | A compact token for authentication. When a user logs in, the server creates a JWT signed with a secret key. The client stores it and sends it with every request. The server verifies the signature — no database lookup needed. |
| Authentication | Proving who you are. The login process. Your authenticate middleware handles this by verifying the JWT token on every request. |
| Authorization | Proving you're allowed to do something. Role checks. Your requireRole middleware handles this after authentication — checking if the user has the right role. |
| CORS (Cross-Origin Resource Sharing) | A browser security rule that blocks requests to a different domain unless the server explicitly allows it. Your Express server has cors() middleware configured to allow requests from localhost:5173. |
| Webhook | An HTTP callback triggered by an event in one system that sends data to another system. When a hold/cancel is approved, your server POSTs to a Microsoft Teams webhook URL to send the notification. |
| WebSocket | A protocol for persistent, two-way communication between client and server. Unlike HTTP, the connection stays open so either side can send data at any time. Used for real-time events in your WS bridge. |
| HTTP vs WebSocket | HTTP is request-response — client asks, server answers, connection closes. WebSocket is persistent — connection stays open, either side can send at any time. HTTP for API calls, WebSocket for real-time. |
| WebSocket Bridge | A dedicated server that sits between two separate apps and relays real-time events between them. Your WS bridge on port 3002 connects the shipping widget and admin portal so they can communicate without sharing a codebase. |
| Polling vs WebSocket vs Supabase Real-time | Three ways to keep UI in sync with server data. Polling: ask the server every N seconds if anything changed (simple but wasteful). WebSocket: keep a connection open for instant push (efficient, custom). Supabase Real-time: database changes automatically p |
| Pub/Sub (Publish/Subscribe) | A messaging pattern where publishers send events to a channel and subscribers receive them. Supabase real-time uses this — a change in the database publishes an event, connected clients subscribed to that table receive the update instantly. |
| Event-Driven Architecture | A design pattern where actions (events) trigger reactions elsewhere in the system. When a warehouse user scans a shipment, an event fires. The admin portal reacts by updating the UI in real time. Your WS bridge enables this. |
| Database | Persistent storage for your data. When the server restarts, data in memory is gone — the database keeps it safe. Your project uses PostgreSQL. |
| PostgreSQL (Postgres) | A powerful open-source relational database. Data is stored in tables with rows and columns. Tables relate to each other — an Order has many Shipments, a Shipment belongs to a Facility. |
| Schema | The structure of your database — what tables exist, what columns each has, what types they are, how they relate. Your prisma/schema.prisma file defines this. |
| Migration | A versioned change to your database schema. Instead of manually altering tables, you create migration files that describe the change. Every environment can reach the same schema state by running migrations in order. |
| ORM (Object Relational Mapper) | A library that maps database tables to objects in your code. Prisma is your ORM. It generates a type-safe client so you can query the database using JavaScript instead of SQL. |
| Prisma | An ORM that sits between your Node.js code and your database. Instead of writing raw SQL, you write prisma.order.findUnique({ where: { id: '123' } }). It also manages your database schema through migration files. |
| Primary Key | A unique identifier for each row in a table. Most tables in your schema use UUID as the primary key — a randomly generated string like a3f8c2d1-... |
| Foreign Key | A column that references the primary key of another table. Creates the relationship between tables. Shipment.orderId is a foreign key that points to Order.id. |
| Index | A data structure that makes database lookups faster. Like an index in a book — instead of reading every page to find a word, you go straight to the page number. |
| Transaction | A group of database operations that succeed or fail together. If you're marking 10 shipments as received and the server crashes halfway through, a transaction ensures you either get all 10 or none — never a partial state. |
| Seed Data | Pre-populated demo data inserted into a database for development and testing. Your prisma/seed.js inserts the 8 demo orders, 6 facilities, and daily goal so the app works immediately on setup. |
| In-Memory Store | Data stored in RAM rather than a database. Fast but temporary — gone when the server restarts. Your mockStore.js is an in-memory store used when no DATABASE_URL is configured. |
| Data Layer / Abstraction Layer | A layer of code that sits between your business logic and your data source. Your db/index.js is a data layer — routes call db.findOrderById() without knowing or caring whether it hits Postgres or the mock store. |
| Connection Pooling | A technique for managing database connections efficiently. Opening a new database connection for every request is expensive. A connection pool maintains a set of open connections that are reused. Important at scale — Supabase uses PgBouncer for this. |
| PgBouncer | A lightweight connection pooler for PostgreSQL. Sits between your application and Postgres, managing a pool of connections. Supabase includes this. Important when many clients connect simultaneously. |
| Database URL | The connection string your application uses to connect to a database. Contains the host, port, database name, username, and password. Looks like postgresql://user:password@host:5432/dbname. Stored in Secrets Manager in production, .env locally. |
| Row Level Security (RLS) | A Postgres/Supabase feature that controls which rows a user can read or write based on their identity. For example a user can only see their own orders. Supabase uses RLS extensively so the auto-generated API is secure by default. |
| pgSQL / PostgreSQL Functions | Stored procedures written in SQL or PL/pgSQL that run inside the database. Supabase lets you call these via its API. Used for complex operations that should happen atomically inside the database rather than in application code. |
| Supabase | An open-source Firebase alternative built on top of PostgreSQL. Provides a hosted Postgres database plus auto-generated REST and GraphQL APIs, built-in authentication, real-time subscriptions, and a dashboard UI. Your widget likely uses this for its datab |
| Supabase vs Raw Postgres | Raw Postgres is just a database — you need to write all your own queries, auth, and APIs. Supabase wraps Postgres with a full backend-as-a-service layer. You get auth, APIs, and real-time built in without writing that infrastructure yourself. |
| Supabase Real-time | Supabase's built-in pub/sub system that listens for database changes and pushes updates to connected clients via WebSocket. If the widget uses this, database changes (new orders, status updates) automatically push to the UI without polling. Could replace |
| Supabase Auth | Supabase's built-in authentication system. Handles email/password login, OAuth (Google, GitHub etc), JWT generation, and session management. Could replace the custom Orbital Matrix auth flow depending on how the widget is architected. |
| Supabase Dashboard | A web UI for managing your Supabase project. Browse and edit tables, run SQL queries, view logs, manage auth users, configure RLS policies. Like pgAdmin but built into Supabase. Useful for debugging and data management. |
| Supabase Edge Functions | Serverless functions that run close to users on Supabase's global network. Similar to AWS Lambda but built into Supabase. Good for lightweight server-side logic that doesn't need a full Express server. |
| Anon Key vs Service Key (Supabase) | Supabase provides two API keys. The anon key is safe to expose in the frontend — it respects Row Level Security. The service key bypasses all security and should only be used server-side. Never put the service key in frontend code. |
| Backend-as-a-Service (BaaS) | A cloud model where a provider handles your entire backend — database, auth, APIs, real-time. You just build the frontend. Supabase and Firebase are BaaS platforms. Faster to build with but less control than a custom Node.js backend. |
| Firebase | Google's backend-as-a-service platform. Real-time database, authentication, storage, hosting. Supabase is the open-source alternative to Firebase. Both let frontend apps interact with data without building a custom backend. |
| Cloud | Renting computing resources from a provider over the internet instead of owning physical hardware. AWS, Google Cloud, and Azure are the big three. |
| AWS (Amazon Web Services) | Amazon's cloud platform. Dozens of services for every imaginable computing need. Your widget infrastructure uses EC2, Amplify, RDS, Secrets Manager, CodePipeline, and App Runner. |
| Region | A physical location where AWS has data centers. us-west-2 is Oregon. You choose a region when setting up services — ideally close to your users to reduce latency. |
| EC2 (Elastic Compute Cloud) | A virtual machine you rent from AWS. You choose the size (CPU, RAM), the operating system, and it runs 24/7. Your Node.js shipping API runs on an EC2 instance. |
| SSH (Secure Shell) | A protocol for securely connecting to a remote computer via the command line. How you access an EC2 instance to configure it or debug issues. |
| Amplify | AWS's managed hosting service for frontend apps. Point it at a GitHub repo, tell it the build command, and it automatically deploys on every push. Handles CDN, SSL certificates, custom domains automatically. |
| RDS (Relational Database Service) | AWS's managed database service. Instead of installing and maintaining Postgres on an EC2 instance yourself, RDS does it for you — backups, updates, failover all handled automatically. |
| Secrets Manager | AWS's service for securely storing sensitive configuration values. API keys, database passwords, JWT secrets. Your EC2 server reads from Secrets Manager at runtime instead of using a .env file. |
| IAM (Identity and Access Management) | AWS's permissions system. Controls who and what can access which AWS resources. An EC2 instance needs an IAM role with permission to read from Secrets Manager. |
| VPC (Virtual Private Cloud) | A private network within AWS. Your EC2 instances and RDS database live inside a VPC — they can talk to each other privately without going through the public internet. |
| S3 (Simple Storage Service) | AWS's object storage service. Stores files — images, PDFs, backups, static assets. Infinitely scalable, very cheap. Amplify stores your built React app files in S3 and serves them via CloudFront. Your label PDFs could be stored in S3. |
| CloudFront | AWS's CDN service. Caches and serves files from locations close to users worldwide. Amplify automatically puts your React app behind CloudFront so it loads fast for users everywhere. |
| CDN (Content Delivery Network) | A network of servers distributed globally that caches and serves static files from locations close to users. Amplify puts your app on a CDN automatically — much faster than one server in one location. |
| Lambda | AWS's serverless compute service. You write a function, upload it, and AWS runs it when triggered — no server to manage. You pay only for the milliseconds it runs. Good for lightweight tasks like sending emails or processing webhooks. |
| Serverless | A cloud execution model where you don't manage servers. You just deploy functions and the cloud provider handles everything else. Lambda is serverless. Contrasts with EC2 where you manage a persistent server. |
| API Gateway | AWS service that creates, manages, and secures APIs. Often paired with Lambda — API Gateway receives HTTP requests and triggers Lambda functions to handle them. An alternative to running a full Express server on EC2. |
| App Runner | AWS service for running containerized applications. You give it a Docker image and it runs it, handling scaling automatically. Your Dimension Prediction ML service uses this. |
| CloudWatch | AWS's monitoring and logging service. Collects logs from EC2, Lambda, and other services. Sets up alarms (e.g. alert me if CPU goes above 80%). Your EC2 server's console output goes to CloudWatch logs. Essential for debugging production issues. |
| CloudFormation | AWS's infrastructure-as-code service. Instead of clicking through the AWS console to set up resources, you write a template file describing what you want and CloudFormation creates it all automatically. Beanstalk uses CloudFormation behind the scenes. |
| Load Balancer | Distributes incoming traffic across multiple servers. If you have two EC2 instances running your API, a load balancer splits requests between them so neither gets overwhelmed. |
| Elastic Load Balancing (ELB) | AWS's load balancer service. Sits in front of your EC2 instances and distributes incoming requests evenly between them. Also handles health checks — if an instance goes down, ELB stops sending traffic to it. Beanstalk sets this up automatically. |
| Auto Scaling | Automatically adding or removing servers based on traffic. If your API gets a spike in requests, auto scaling spins up more EC2 instances to handle the load. When traffic drops, it scales back down to save cost. Beanstalk and App Runner both handle this a |
| AWS Elastic Beanstalk | A managed AWS service that handles the infrastructure for deploying web applications. You give it your code and it automatically provisions EC2 instances, load balancers, auto scaling, and deployments. Think of it as EC2 with training wheels — less contro |
| Beanstalk vs EC2 + CodePipeline | Both run your Node.js app on EC2 under the hood. EC2 + CodePipeline gives you full control over every configuration detail. Beanstalk manages all that for you automatically. Teams that want speed use Beanstalk. Teams that want fine-grained control wire it |
| ECR (Elastic Container Registry) | AWS's service for storing Docker images. Like npm but for Docker images. App Runner pulls images from ECR to run your containerized services. |
| AWS Secrets Manager vs Supabase | Both store sensitive config securely. AWS Secrets Manager is for your EC2/Node.js services — API keys, DB passwords. Supabase's own credentials (URL, anon key, service key) would themselves be stored in Secrets Manager for your Node.js server to read at r |
| Git | A version control system. Tracks every change to your code over time. You can see who changed what, when, and why. You can roll back to any previous state. Essential for team development. |
| Repository (Repo) | A Git-managed codebase hosted on GitHub or GitLab. Contains all your code and its entire history. |
| Branch | A parallel version of your codebase. You create a branch to work on a feature without affecting the main code. main is the primary branch. deploy/staging is the staging branch. |
| Commit | A saved snapshot of your code at a point in time with a message describing what changed. The building block of Git history. |
| Merge | Combining changes from one branch into another. When a feature is ready, you merge your feature branch into deploy/staging to test, then into main to go live. |
| Pull Request (PR) | A request to merge one branch into another, with a chance for teammates to review the code first. Standard practice — no one merges to main without review. |
| CI/CD (Continuous Integration / Continuous Deployment) | Automation that runs every time code is pushed. CI runs tests to catch bugs. CD deploys the code if tests pass. Your CodePipeline is the CD part — merge to main, pipeline runs, code is live. |
| CodePipeline | AWS's CI/CD service. Watches a GitHub branch, triggers on changes, runs build steps, deploys to EC2. Your shipping API uses this for automated deployments. |
| Pipeline | A series of automated steps that code goes through from commit to deployment. Typical steps: pull code → install dependencies → run tests → build → deploy. |
| Monorepo | A single repository that contains multiple related projects. Your monark-widget folder contains both the client and server as separate packages managed together. |
| .gitignore | A file that tells Git which files and folders to never track. node_modules, .env files, and build output (dist/) are always in here. Prevents secrets and unnecessary files from being committed. |
| Git Conflict | What happens when two people change the same lines of code in different branches and then try to merge. Git can't decide which version is correct, so it flags the conflict for you to resolve manually. |
| Environment Variables | Configuration values stored outside your code. API keys, database URLs, JWT secrets. Live in .env locally, in AWS Secrets Manager in production. Never committed to Git. |
| Local Development | Running everything on your own machine. npm run dev. Fast feedback, easy to debug, no cost. Where you write and test code first before pushing anywhere. |
| Staging | A cloud environment that mirrors production exactly. Real server, real database — but not used by real customers. Where you test before going live to catch issues that don't appear locally. |
| Production | The live environment real users interact with. Treated with the most care. Changes only come through staging first. Downtime here means real business impact. |
| Staging Environment (Supabase) | Just like having separate EC2 instances for staging and production, you'd have separate Supabase projects — one for staging, one for production. Each has its own database URL and API keys configured via environment variables. |
| Port | A number that identifies a specific process on a computer. Your server runs on 3001, WS bridge on 3002, widget on 5173, admin on 5174. Like apartment numbers in a building — same address, different unit. |
| Build / dist | The output of running your build tool. Vite takes your React source code and outputs a dist/ folder of plain HTML, CSS, and JS. This is what gets deployed to Amplify/S3 — not your source code. |
| Dev Tunnel | A tool that creates a temporary public URL that tunnels traffic to a server running on your local machine. You've used VS Code dev tunnels to share your local widget with Milena. The URL changes every session. |
| Docker | A tool for packaging an application and all its dependencies into a portable container. If it works in the container, it works everywhere — your laptop, AWS, a colleague's machine. |
| Container Image | The blueprint for a Docker container. Like a class in OOP — the image is the class, the running container is the instance. Built from a Dockerfile, stored in a registry like ECR. |
| Dockerfile | A text file that defines how to build a Docker image. Lists the base OS, what to install, what files to copy, and what command to run when the container starts. |
| Snowflake | A cloud data warehouse platform. Designed for analytical queries on large datasets rather than transactional operations. Your VMO data is pushed to Snowflake for reporting — it's optimized for running complex reports across millions of rows fast. |
| Data Warehouse vs Database | A regular database (Postgres) is optimized for transactional operations — fast reads/writes of individual rows. A data warehouse (Snowflake) is optimized for analytical queries — aggregating and reporting across millions of rows. Different tools for diffe |
| ETL (Extract Transform Load) | The process of moving data from one system to another. Extract data from the source (VMO database), Transform it into the right format, Load it into the destination (Snowflake). The pipeline that moves your transactional data into Snowflake for reporting. |
| SSL/TLS (HTTPS) | Encryption for data in transit between browser and server. The S in HTTPS. Amplify handles SSL certificates automatically. Never run a production app without it. |
| DNS (Domain Name System) | Translates human-readable domain names (monark.com) into IP addresses that computers use to find each other. When you set up a custom domain on Amplify, you configure DNS records to point to it. |
| Latency | The delay between making a request and receiving a response. Affected by network distance, server load, and code efficiency. CDNs reduce latency by serving files from locations close to users. |
| IP Address | A unique numerical address for a device on a network. EC2 instances have a public IP address that you use to SSH in or route traffic to. DNS maps your domain name to this IP. |
| Firewall / Security Group | AWS Security Groups act as a virtual firewall for your EC2 instances. You define rules for which ports accept inbound traffic. For example, only allow port 3001 from specific IPs rather than the entire internet. |
| Mock / Stub | A fake version of an external service used in development and testing. Your EasyPost, PrintNode, and Teams services are all mocked — they return realistic fake data when real API keys aren't configured. |
| Unit Test | A test that checks one small piece of code in isolation. Test a single function, mock its dependencies, verify the output. Fast to run. The lowest level of testing. |
| Integration Test | A test that checks how multiple pieces work together. Test a route handler end-to-end — real database call, real middleware, real response. Slower but catches more real-world bugs. |
| Test Coverage | A measure of how much of your codebase is exercised by tests. High coverage doesn't guarantee bug-free code, but low coverage means large untested areas that could silently break. |
| Debugging | The process of finding and fixing bugs. Tools include console.log (basic), browser devtools (frontend), and Node.js debugger or CloudWatch logs (backend). |
| REST vs GraphQL | Two styles of API design. REST uses multiple endpoints (GET /orders, POST /shipments). GraphQL uses one endpoint where the client specifies exactly what data it needs. Your project uses REST. |
| Microservices | An architecture where an application is split into small, independent services that each handle one thing. Your WebSocket bridge is a separate service. Your ML dimension prediction runs in its own App Runner container. Contrasts with a monolith. |
| Monolith | An application where all functionality is in one codebase and deployed as one unit. Simpler to start with. As apps grow, teams often split them into microservices. |
| Caching | Storing the result of an expensive operation so the same result can be returned quickly next time without repeating the work. Can happen at many levels: browser cache, CDN cache, API cache, database query cache. |
| Background Job / Queue | Work that happens asynchronously, outside the request-response cycle. If generating a shipping label takes 3 seconds, you don't make the user wait — you queue the job, return immediately, and the job runs in the background. |
Created by:
babybee27