MaJu Tech Notes

← 7/8 Frontend and backend d… 📚 Series Index (series end) A service is not truly in operation just because it runs. It also needs a trustworthy address, a secure connection, separated environments, and visible failures. Key Takeaways A domain is the human-readable service address, while DNS is the system that maps that address to actual infrastructure. HTTPS is not only encryption. It also supports authenticity, integrity, browser trust, and modern session behavior. If development, staging, and production are not clearly separated, authentication, API calls, and monitoring data start contaminating each other. Tools such as Sentry turn hidden failures into observable signals with environment and release context. 1. Why domains and DNS are the starting point of operations Users remember domain names, not IP addresses. But the deeper reason domains matter is that they define service boundaries. They let a team express clear roles such as: example.com for production s...

← 6/8 Build 📚 Series Index 8/8 HTTPS → Deployment is not just buying a server. It is designing how requests travel through boundaries until they reach the code that should handle them. Key Takeaways EC2 is a virtual server environment, while nginx is commonly the web-facing layer that serves files and proxies requests to application processes. A common request path is domain -> nginx -> application server -> database or external services . In deployment, the frontend/backend distinction becomes clearer when framed as execution responsibility, not only as file type. A single EC2 machine can host multiple layers, but understanding their separation is what makes scaling and debugging possible later. 1. Why EC2 appears so often in deployment discussions Amazon EC2 is one of the classic entry points for learning server-based deployment. The official AWS docs describe it as a way to launch and manage virtual server instances. For beginners, the easiest mental model...

← 5/8 Why OAuth and SSO Feel… 📚 Series Index 7/8 Frontend and backend d… → Code that is comfortable for developers to write is usually not the same shape as the output a browser or server wants to execute. Key Takeaways A frontend build is the full process that turns source code into files and server artifacts that can actually run in production. Compile, transpile, bundle, and code splitting are different jobs inside one pipeline, even though beginners often experience them as one command. In the current Next.js docs, Turbopack is the default bundler, with Webpack still available when explicitly requested. Many deployment failures come from build output, asset paths, runtime boundaries, or environment-variable timing rather than from the visible application logic alone. 1. What "build" really means The most practical definition of a build is "the process that turns development source into deployable output." In frontend work, that usually includes...

← 4/8 What You Miss If You T… 📚 Series Index 6/8 Build → Login is not one screen. It is a short chain of trust exchanges across the browser, the identity provider, and the application. Key Takeaways OAuth is an authorization framework, while SSO is a login experience that lets one authentication session cover multiple services. Login delays usually happen in the redirect -> authentication -> token exchange -> session creation -> user sync path, not in the button itself. Organization SSO often feels slower than personal login because it adds policy checks, group mapping, and identity-provider integration. After deployment, authentication issues often come from redirect URIs, cookies, domains, or environment separation rather than only from application code. 1. OAuth and SSO are not the same thing These terms often appear together, so beginners naturally blur them. OAuth is mainly about delegated authorization. An application can ask another service to veri...

← 3/8 How Far Should You Tru… 📚 Series Index 5/8 Why OAuth and SSO Feel… → Connecting a database does not finish data handling. Most real operational problems begin before storage, after retrieval, and at the point where access must be restricted correctly. Key Takeaways Supabase is a managed backend layer built around Postgres, but its educational value is wider than simple storage. The most important concept for beginners is not the feature checklist. It is the data boundary. CRUD sits in the middle of the data flow. Before it comes validation and preprocessing. After it comes postprocessing and permission control. Operational quality depends less on whether data can be stored and more on whether it is stored correctly, read safely, and reshaped appropriately. Why Supabase should not be reduced to "an easy database" Supabase is often introduced as a convenient Postgres-based backend. That description is useful, but incomplete. In practice it also pushes deve...

← 2/8 Why Docker Is the Star… 📚 Series Index 4/8 What You Miss If You T… → Building features quickly is getting easier. Deciding what to build yourself, what to hand off to external services, and what must still be verified by you is becoming harder and more important. Key Takeaways APIs are the basic unit of feature connection, while MCP can be understood as a structured layer for tool access and control. Vibe coding increases speed dramatically, but speed alone does not create an operationally trustworthy system. The more external capability you connect, the more authentication, cost, failure handling, permissions, and data boundaries matter. Good development is not just about connecting things quickly. It is also about deciding what stays under direct control and what gets delegated. Why APIs are the default connection unit Modern web applications rarely implement everything from scratch. Payments, authentication, email delivery, maps, search, and model inference are...

← 1/8 Why Local Success Brea… 📚 Series Index 3/8 How Far Should You Tru… → Docker matters not mainly because it makes deployment feel modern, but because it lets an application carry its execution assumptions with it. Key Takeaways Docker fixes the execution environment into an image and runs that image as a container. For beginners, Docker is most valuable not as automation hype but as a way to reduce local-versus-production drift. Images, containers, networks, and volumes need to be understood separately if Docker is going to make architectural sense. Docker does not solve every operational problem, but it does remove many avoidable environment excuses. Why Docker appeared in the first place The previous article showed that local and production systems often differ in operating system, runtime version, installed packages, system libraries, file paths, and startup commands. Even small mismatches can change behavior. Docker appeared to reduce that gap. Instead of movin...

(series start) 📚 Series Index 2/8 Why Docker Is the Star… → The first real operational wall for beginners is usually not code quality. It is the gap between a controlled local experiment and an uncontrolled real-world system. Key Takeaways Local development succeeds under conditions the developer already understands, while production runs inside a larger system of users, servers, networks, and security rules. The same code can behave differently in production because environment variables, data state, file systems, external APIs, and deployment structure are different. Saying "it works on my machine" only proves that implementation started correctly. It does not prove the system is operationally ready. Docker, API design, Supabase boundaries, build tooling, deployment, and HTTPS all exist partly to reduce this local-versus-production gap. Local success and production success are not the same question Local development usually happens in a small environment one...

📚 Harness Engineering Master Map — 7 Series, 29 Parts A step-by-step map to read the agent harness series from foundations to appendix. 1. Foundations ① Harness Engineering (6 parts) — Context, memory, tools, routing, evaluation — everything around an agent ② Harness Engineering Basics (4 parts) — The work environment and agent loop that matter more than the model 2. Implementation ③ OpenAI and Claude Harnesses (3 parts) — Reading Responses API and CLAUDE.md as operating surfaces 3. Operations ④ Evaluation, Ops, and Memory (4 parts) — Handoff, guardrails, and memory ownership for long-running agents ⑤ AI Operations Economics (4 parts) — Cost, routing, caching, and context decisions 4. Strategy ⑥ Patterns, Strategy, and Cases (4 parts) — Repeatable structures, design decisions, ACI, and case analysis 5. Appendix ⑦ Companion Appendix (4 parts) — Glossary, source verification, workbooks, and multi-agent Q&A This series was created to move one step beyond the expectation t...

← E3 harness workbook 📚 Series Index (Appendix series end) Once multi-agent design enters the conversation, many teams start using "subagent" and "agent team" almost interchangeably. But they are not the same operating choice. They imply different costs, different coordination surfaces, and different reasons for existing. This appendix closes the series with a Q&A guide to that distinction. Key Takeaways A subagent is usually a bounded delegated worker under a lead agent. An agent team is usually a more persistent collaboration model with explicit role separation. Complexity alone does not justify a team. In many cases, clear delegation is enough. Team structures are justified only when the value of role separation outweighs coordination cost. The most useful design question is not "how many agents do we need?" but "where do failure domains need to be separated?" 1. Why the distinction matters docs/blog_series_하네스...