标签：#web

You've written retry logic. It probably looks something like this: async function withRetry ( fn , retries = 3 ) { for ( let i = 0 ; i < retries ; i ++ ) { try { return await fn (); } catch ( err ) { if ( i === retries - 1 ) throw err ; await new Promise ( r => setTimeout ( r , 200 * ( i + 1 ))); } } } You test it locally. You simulate a slow dependency like this: const fakeDB = async () => { await new Promise ( r => setTimeout ( r , 200 )); // simulate DB return { id : 1 , name : ' test ' }; }; Your retry logic works. Tests pass. You ship it. Then in production, your app starts dropping requests under load. The problem isn't your retry logic. It's your fake. Real dependencies don't have flat latency Here's what your Postgres instance actually looks like in production: p50: 5ms — half of all queries finish in under 5ms p95: 50ms — 95% finish under 50ms p99: 200ms — 99% finish under 200ms p99.9: 2000ms — that one unlucky query during a GC pause Your setTimeout(fn, 200) simulates the worst case, every single time. That's not how production works. And because it's not how production works, your retry logic has never actually been tested against reality. The bugs hide in the variance — not in the slow case, but in the unpredictability. What the real distribution looks like Latency in distributed systems follows a lognormal distribution . It's right-skewed: most requests are fast, a meaningful minority are slow, and a small tail is very slow. This shape comes from how real systems work: GC pauses — Java, Go, and even Node's garbage collector occasionally stops the world Cold caches — first query after a cache miss is always slower Network jitter — packet routing isn't deterministic Noisy neighbors — other workloads on the same hardware compete for resources Connection pool exhaustion — when all connections are busy, new queries wait None of these are constant. They're random, rare, and multiplicative — which is exactly what produces a lognormal shape. Why this matters fo

GraphQL: A Complete Guide for Developers in 2026 NEWS: MY GAME JUST LAUNCHED Flip Duel Card Battle - Apps on Google Play Outsmart rivals in 1v1 card duels. Joker, bluff, ranked PvP. 5 rounds. play.google.com If you have built more than a couple of APIs, you have probably felt the friction of REST at scale. You ship an endpoint, the frontend team asks for one more field, you version the route, the mobile team needs a different shape of the same data, and six months later you are maintaining /v3/users/:id/full next to /v2/users/:id/summary and nobody remembers which one the Android app actually calls. GraphQL was built to kill that exact pain. It is a query language and runtime that lets clients ask for precisely the data they need — no more, no less — from a single endpoint, against a strongly typed schema that doubles as living documentation. This guide walks through GraphQL from first principles to production concerns. It is aimed at working developers, so expect schema definitions, resolvers, real queries, the N+1 problem, federation, security, and the parts of the ecosystem that actually matter in 2026. By the end you should be able to decide whether GraphQL belongs in your stack and how to build it without shooting yourself in the foot. What GraphQL Actually Is GraphQL is a specification, not a library or a framework. It was created at Facebook in 2012 to power their mobile apps, open-sourced in 2015, and is now governed by the GraphQL Foundation under the Linux Foundation. The spec defines a query language, a type system, and an execution model — but it deliberately says nothing about which database you use, which programming language you implement it in, or how you transport requests over the wire. That last point trips people up, so let it sink in: GraphQL is transport-agnostic and storage-agnostic. Most implementations run over HTTP with JSON, but that is a convention, not a requirement. Your resolvers can pull data from PostgreSQL, a REST microservice, a gR

En una gestoría del automotor, consultar las multas de un auto era entrar a 33 sistemas distintos (Provincia, CABA, municipios), cada uno con su captcha y sus caídas. Lo automatizamos con una sola API, la de Multita , y comparto cómo quedó porque sirve a cualquiera que arme herramientas para el rubro automotor o fintech en Argentina. El problema Las infracciones de tránsito en Argentina no viven en un solo lugar. Hay sistemas provinciales (Buenos Aires, Santa Fe, Entre Ríos, Misiones, Chaco, Salta, Mendoza) y municipales (decenas). Ninguno habla con el otro. Consultar a mano son 15 a 20 minutos por vehículo. La solución: una request, todas las jurisdicciones La API de Multita recibe una patente, un DNI o un CUIT y devuelve, en JSON, las actas de cada jurisdicción con su monto y su estado. curl -X POST https://multita.com.ar/api \ -H "X-Api-Key: TU_KEY" \ -H "Content-Type: application/json" \ -d '{"tipo":"patente","valor":"AB123CD","jurisdicciones":"todas"}' { "resultados" : [ { "jurisdiccion" : "pba" , "nombre" : "Provincia de Buenos Aires" , "cantidad_actas" : 2 , "total_oficial" : 418500 }, { "jurisdiccion" : "caba" , "nombre" : "CABA" , "cantidad_actas" : 1 , "total_oficial" : 95000 } ], "resumen" : { "cantidad_actas" : 3 , "total_oficial" : 513500 } } Lo que nos ahorró Pasamos de 15-20 minutos por auto a segundos, y de cuatro ventanas abiertas a una sola llamada. Para una gestoría que cotiza decenas de carteras por día, es la diferencia entre atender 10 clientes o 30. Datos clave Cubre 33 jurisdicciones argentinas (provinciales y municipales), por patente (dominio), DNI o CUIT. Respuesta en JSON al instante; opcional, el total ya cotizado con tu pricing. Hay también una consulta web gratis para probar sin integrar nada. Si tenés una gestoría o estudio y querés esto andando sin programar, escribinos a BA Gestoría y te lo dejamos listo (y un descuento si venís de este post). Docs de la API: https://multita.com.ar/api

Here's the thing nobody warns you about when you put Supabase behind a "real" backend. My stack is React + FastAPI + Supabase Postgres. Every write goes through FastAPI. Every endpoint checks the user, the role, the ownership. I audited that backend HARD — rate limits, JWT validation, RLS, the whole thing. I was proud of it. And none of it mattered for the two holes I actually shipped. Because the Supabase anon key lives in the browser. It HAS to — that's how supabase-js talks to your project. Which means every logged-in user is holding a key that talks to Postgres directly . Not through my FastAPI. Around it. That anon key is a SECOND API. And I'd spent months hardening the first one while the second one sat there, wide open, the whole time. Hole #1 — the answers were just... readable Quiz questions live in quiz_options , one is_correct boolean per option. My backend never sends is_correct to a student before they submit. Obviously. But the browser doesn't have to ask my backend. // any logged-in student, straight from the console: const { data } = await supabase . from ( ' quiz_options ' ) . select ( ' question_id, label, is_correct ' ) // <- the answer key. all of it. The RLS policy said "authenticated users can read quiz_options ." Totally true for the rows. It just also handed back the column that decides the grade. The answer key. To anyone with a login and ten seconds of curiosity. Fix: column-level REVOKE SELECT from the client role, and let the backend be the only thing that ever reads is_correct . (PR #775.) Hole #2 — they could WRITE things they shouldn't Same class of bug, bigger blast radius. The default Postgres grants let the client role insert/update far more than I'd realized — including a path toward forging a certificate. Nobody did it. But "nobody did it yet" is not a security model! So I stopped patching table by table and flipped the whole thing: -- kill the client's entire write surface, then grant back the ONE thing it needs ALTER DEFAULT PRI

The build-vs-buy question gets answered wrong in both directions. Scrappy teams build things they should have bought, wasting six months reinventing Stripe. Enterprise teams buy things they should have built, ending up with a duct-taped stack of ten SaaS products that cost more than a full-stack engineer. The real answer depends on five questions most decision frameworks don't ask. This guide is a practical walkthrough for anyone trying to figure out the right call for their own business. The Myth That Distorts Every Build-vs-Buy Conversation "Buying is cheaper." This is the default assumption, and it's wrong often enough to be dangerous. Buying looks cheaper because the cost is monthly instead of upfront -- a psychological trick, not an economic one. Run the numbers on any SaaS tool over 5 years and you'll usually find the cost lands within 2x of building custom. Sometimes below. The real cost difference is not price; it's time, flexibility, and ownership. When you buy: You spend less today, more in year 3 You get speed now, rigidity later You trade money for control You own none of the code When you build: You spend more today, less per year You trade speed now for flexibility later You trade money for control You own the code and can change anything Both are rational trades. The question is which one matches the stage and strategy of your business. When Buying Wins Start with the easy case. Buy off-the-shelf when: 1. The problem is generic and solved. Email hosting, payment processing, accounting, HR payroll, customer support tickets, video conferencing, file storage. These are solved problems. Building your own is nearly always the wrong call. 2. The space has mature competitive options. If there are 5 reputable companies competing on price and features, you benefit from that competition. Building custom takes you out of it. 3. Your process is standard. If you do exactly what every other company in your vertical does, a tool built for every company in your verti

→ Try it: gnomeman4201.github.io/r4b1t It's a curated random link generator for security and OSINT...

Filament's export action is great. It's quick to set up, supports queued exports, includes column mapping, handles notifications, and keeps a history of generated files through the Export model. For most use cases, it's exactly what you need. But I recently ran into a limitation that the native export couldn't solve. When XLSX isn't really Excel I was exporting financial data or measurements from a Filament table. The export worked. The file downloaded. Excel opened it without any issue. The problem was that every amount was exported as text instead of a real numeric value. For an accountant, that creates several problems immediately: Excel formulas such as =SUM() don't work correctly Selecting a range of cells doesn't display totals in Excel's status bar Conditional formatting based on numeric values becomes unreliable Additional manual cleanup is required before the file can be used Technically the export contained the data. Practically, it wasn't usable. The root cause is simple: Filament's export system is designed around CSV-style exports. That's perfect for many scenarios, but it doesn't expose the full spreadsheet capabilities offered by PhpSpreadsheet and Laravel Excel . On top of that, I also had a second, completely different requirement: a yearly report with one worksheet per month, merged headers, borders, conditional formatting, and custom layouts. Not a table dump but a report. Why not just use Laravel Excel directly? Laravel Excel already solves all of these problems. It's built on PhpSpreadsheet and provides complete control over cell types, number formats, formulas, styling, and multiple worksheets. The obvious solution would have been to abandon Filament's export action entirely and build custom exports from scratch. But that means losing everything Filament already provides: Export modal and options form Column mapping UI Queue handling Progress notifications Download links Export model history I didn't want to rebuild all of that. I simply wanted

Your backend returned 200. The mobile app showed an error. The user tapped "Pay" three times. Three pending charges hit their account. One order was placed. Their balance was short. And your incident log showed zero failures. Every engineer on the team did their job. Nobody solved the problem. This is the most common way engineering teams fail, not through incompetence, but through excellent execution of the wrong unit of work. And until you recognise the difference between completing a task and solving a business problem , you will keep shipping systems that work perfectly and experiences that don't. The Ticket-Thinker vs. The System-Owner Most engineers early in their careers think in tickets. Ticket assigned → code written → tests pass → PR merged → ticket closed. Done. This is fine when you're learning. It's a liability when you're trying to grow. The engineer who closes tickets is useful. The engineer who asks "what problem does this ticket actually solve, and am I solving it in the right place?" that engineer is dangerous in the best way. Here's the distinction in practice. The backend engineer builds a payment endpoint. It processes charges correctly, returns the right status codes, has proper error handling. 100% test coverage. Ticket closed. The mobile engineer builds the payment screen. It calls the endpoint, handles the response, shows confirmation or error. Smooth UI. Ticket closed. The problem nobody owned: what happens when the network drops after the backend processes the charge but before the mobile app receives the confirmation? The backend: charge processed. No error. The mobile: timeout. Shows "Payment failed." User retries. The user: charged twice. Both engineers solved their assigned problem correctly. The business problem — charge the user once and confirm it reliably — went unsolved. Because that problem lived in the space between their tickets, and nobody was watching that space. Real Scenario 1: The Payment That Worked and Failed at the Same

Most "compress your image" websites upload your photo to a server. You don't need one. The browser's own canvas can re-encode an image at any quality — I built a drag-and-drop compressor in about 30 lines , and your photo never leaves your machine. 🗜️ Try it (drop a photo): https://dev48v.infy.uk/solve/day9-image-compressor.html 1. Catch the dropped file — locally drop . addEventListener ( " drop " , e => { e . preventDefault (); const file = e . dataTransfer . files [ 0 ]; // stays in the tab, 0 bytes uploaded loadImage ( file ); }); For sensitive images (IDs, screenshots), "never uploaded" is a real feature, not just a nicety. 2. Decode it into an <img> A dropped file is just bytes. Load it via a local blob: URL: const img = new Image (); img . src = URL . createObjectURL ( file ); await img . decode (); 3. Draw it onto a canvas Now the browser holds the raw pixels, detached from the original file format: canvas . width = img . naturalWidth ; canvas . height = img . naturalHeight ; canvas . getContext ( " 2d " ). drawImage ( img , 0 , 0 ); 4. Re-encode at a quality (this IS the compression) canvas . toBlob ( blob => { preview . src = URL . createObjectURL ( blob ); showSize ( blob . size ); }, " image/jpeg " , 0.7 ); // 0.7 = 70% quality JPEG and WebP are lossy — they discard detail the eye barely notices. That third argument is the entire compression dial; a small quality drop often halves the file size. 5. Hand the result back as a download link . href = URL . createObjectURL ( blob ); link . download = " compressed.jpg " ; // the browser saves it, no server The takeaway FileReader → Image → Canvas → toBlob is a surprisingly powerful local image pipeline. The same four steps do resizing, format conversion, cropping, watermarking — all client-side, all private. A whole category of "image tools" needs no backend at all. Open it and drop a photo.

Turbo Start Aisle is our agentic e-commerce starter on Shopify and Sanity. Instead of filters...

If you build with AI, three stories this week rhyme into one theme: the hype is colliding with the bill. Here's the builder's read on each — and what I'd actually do about it. 1. Most of a new TikTok feed is now AI slop A Kapwing study reported by Tubefilter hand-checked 10,742 videos across 20 categories and found that 59% of what a brand-new TikTok account sees is AI-generated . Kids content was the worst — 57% slop, with the #CartoonKids tag hitting 97% — and TikTok serves roughly 3x more slop than YouTube. Why builders should care: generation is now free and infinite, so volume is worthless as a moat. The scarce thing is taste and verification. If your product or content can be faked by a feed of bots, it will be. Polish, point of view, and "a human clearly did this" are the new differentiators. 2. Databricks grew 80% — but agents are eating its margins Per CNBC , Databricks' annualized revenue jumped about 80% to ~$6.9B, and its AI products now bring in $1.7B (up from $1.4B). The catch: the CEO says gross margin "will go lower" as customers run more agents. Why builders should care: this is the quiet tax of agentic software. An agent that loops, retries, and calls tools burns far more tokens than a single API call. If you're shipping agents, budget for inference at scale , not the sticker price on the pricing page. Profitability now lives in prompt efficiency, caching, and knowing when not to call the model. 3. 60% of US consumers are turned off by "AI" branding A WordPress VIP survey of 2,000 people, covered by TechCrunch , found that 60% reject "AI" in brand messaging , while 86% still want to check the original sources behind a claim. Why builders should care: "Now with AI!" is starting to read like a warning label. Sell the outcome, not the technology — "2x faster," "fewer errors," "your data stays private" — and cite where your results come from. Trust is becoming a feature you ship, not a slogan you bolt on. The takeaway Feeds are flooded, agents are cost

I Built a Vanilla JS Web App that Scored 100/100 Under Lighthouse’s New "Agentic Browsing" Audit. Here’s What It Means. If you have run a performance audit on PageSpeed Insights or Lighthouse recently, you might have noticed a fascinating new line item quietly slipping into the metadata report: Agentic Browsing . When I audited my free tool suite, Paktheta , I managed to hit the ultimate developer milestone— a perfect 100/100 across Performance, Accessibility, Best Practices, and SEO. But seeing that perfect score alongside the label "Agentic Browsing" got me thinking. What exactly is an AI-driven agent experiencing when it hits our sites, and why is this the new gold standard for web performance? Let's dive into what Agentic Browsing actually means for the future of optimization. What on Earth is "Agentic Browsing"? Historically, speed tests like Lighthouse were passive. A headless browser opened your URL, waited for the page to load, recorded metrics like First Contentful Paint (FCP) and Largest Contentful Paint (LCP), and closed the tab. It was a linear, predictable, and frankly synthetic snapshot. Agentic Browsing changes the paradigm entirely. Instead of a basic static script, modern auditing platforms use autonomous, intelligent browser agents. Guided by modern AI-driven browser control (using updated instances like HeadlessChromium), these agents don't just stare at your page—they explore it like a real human would. An agentic audit runner will: Identify interactive buttons and click them to test responsiveness. Scan form elements to see if they accept paste commands cleanly. Intelligently look for broken layout shifts (CLS) by dynamically scrolling and triggering micro-animations. Interact with JavaScript components to see if they block the main execution thread. In short: It simulates real, unpredictable human behavior at lightning speed. If your site relies on bloated frameworks that look fast initially but lock up the second a user tries to interact, an a

TL;DR — UUID v7 trie 13× plus vite que v4 en simulation B-tree (1M entrées), expose une empreinte mémoire identique, mais révèle son timestamp d'émission. UUID v4 reste le choix "zéro réflexion" pour les identifiants isolés. Le reste de cet article vous donnera les données pour décider. Introduction Les UUIDs sont omniprésents dans les systèmes modernes : clés primaires de bases de données, identifiants de sessions, tokens de traçabilité. Pourtant, le choix de la version impacte directement les performances en écriture et en lecture, la fragmentation des index, et — dans certains contextes — la confidentialité des données. UUID v4 (RFC 4122, 2005) est aujourd'hui la version par défaut de presque tous les ORM et frameworks. UUID v7 (RFC 9562, 2024) est son successeur moderne, conçu pour corriger son principal défaut : le désordre lexicographique. Dans cet article, nous allons mettre les deux en face avec des benchmarks réels sur des volumes de 100 000 à 10 millions d'UUIDs , analyser leur structure bit par bit, et vous donner une grille de décision claire. Structure interne : ce que contiennent ces 128 bits UUID v4 xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx Bits Contenu 0–47 Aléatoire 48–51 Version (0100 = 4) 52–63 Aléatoire 64–65 Variant (10) 66–127 Aléatoire 122 bits d'entropie pure. Aucune information temporelle. Chaque UUID est statistiquement indépendant des autres. UUID v7 019ed5c8-2a2f-7974-91f2-6ba1f313dcfa └──────────────┘ 48 bits = timestamp Unix en millisecondes Bits Contenu 0–47 Timestamp Unix (ms) 48–51 Version (0111 = 7) 52–63 Aléatoire (sub-ms ou compteur) 64–65 Variant (10) 66–127 Aléatoire 74 bits d'entropie + 48 bits de temps. Naturellement monotone : deux UUIDs générés dans la même milliseconde sont toujours distincts et ordonnés de façon cohérente. Lecture du timestamp (Python) : import uuid6 u = uuid6 . uuid7 () b = u . bytes ts_ms = int . from_bytes ( b [: 6 ], ' big ' ) # → 1781703125553 (ms depuis epoch Unix) Depuis la sortie de nos benchmarks : [00

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

Hello Dev Community! 👋 It is officially Day 39 of my non-stop run toward full-stack MERN engineering! Yesterday, I mapped out basic HTTP verbs like GET and POST. Today, I advanced into Prashant Sir's (Complete Coding) backend masterclass to tackle one of the most critical core operations: Handling Data Streams and Body Parsing . When a user submits a form or uploads data, the server doesn't receive the file all at once. It arrives as an asynchronous stream of network data chunks. Today, I learned how to collect and decode those packets natively! 🧠 Key Learnings From Node.js Lecture 7 (Streams & Buffers) Node.js is designed to be non-blocking and memory-efficient. Here is the technical breakdown of how it intercepts client payloads: 1. Inbound Streams & Data Chunks I learned that incoming POST data is treated as a Readable Stream . Instead of loading a massive data file into the server memory instantly, Node transmits the payload in tiny pieces called Chunks (hexadecimal binary data). 2. Event Listeners for Requests ( req.on ) Natively, we don't have an instant req.body object. We have to listen to the network events on the incoming request stream: req.on("data", (chunk) => { ... }) : Fires every single time a fresh chunk of binary data arrives at the network interface. We push these raw chunks into a temporary array. req.on("end", () => { ... }) : Fires automatically once the stream concludes and all chunks have arrived safely. javascript if (req.url === "/submit" && req.method === "POST") { let body = []; req.on("data", (chunk) => { body.push(chunk); // Collecting raw binary chunks }); req.on("end", () => { // Concatenating and converting hexadecimal binary buffers into a readable string layout let parsedBody = Buffer.concat(body).toString(); console.log("Received Form Payload:", parsedBody); res.writeHead(200, { "Content-Type": "text/plain" }); res.end("Data received and parsed successfully!"); }); }

Hello Dev Community! 👋 It is officially Day 38 of my unbroken streak toward mastering the MERN stack! Yesterday, I learned how to extract query strings from the URL bar. Today, I took a massive step forward into full-stack backend architecture by diving into Prashant Sir's (Complete Coding) roadmap to master HTTP Request Methods . Up until now, our server treated every incoming request the same way. Today, I learned how to make the backend execute completely different actions based on the "intent" (HTTP Verb) of the user! 🧠 Key Learnings From Node.js Lecture 6 (HTTP Verbs) An endpoint is no longer static when you map request methods against it. Here is the technical breakdown of what I locked down today: 1. Cracking req.method I discovered that the incoming Request object holds a crucial property called req.method . This tells the server exactly what action the client wants to perform. 2. The Big Four Core Methods GET: Used when the user simply wants to read or fetch data from the server (e.g., viewing a product page). POST: Used when the user wants to securely send or create new data on the server (e.g., submitting a signup form). PUT/PATCH: Used to update existing data records. DELETE: Used to wipe a specific data entry from the server storage. javascript const http = require("http"); const server = http.createServer((req, res) => { if (req.url === "/api/data") { if (req.method === "GET") { res.writeHead(200, { "Content-Type": "text/plain" }); res.end("Fetching and reading secure database records..."); } else if (req.method === "POST") { res.writeHead(201, { "Content-Type": "text/plain" }); res.end("Securely creating and injecting new data into the server!"); } } else { res.end("Standard Route"); } }); server.listen(8000);

Ask a language model to score a developer portfolio out of 100 and you get a confident number back. Hand it a near-empty page with a name and a broken avatar, and it will often still tell you something like 92. Nice layout. Strong personal branding. The model is being polite, not accurate. That was the first wall I hit building Leon, the reviewer inside getfolio. If the score is not trustworthy, nothing downstream matters: the critique, the suggestions, and the fix button all hang off a number the model invented to sound encouraging. This is the build log of how I stopped letting the model hold the pen. Short version: a deterministic rules engine owns the score, and the language model only owns the words around it. The failure mode: an LLM judge wants to be liked If you have shipped anything with an LLM evaluator you have probably seen this. You hand it a rubric, a JSON schema, even worked examples, and it still drifts upward. Empty inputs get encouraging scores. Weak inputs get the benefit of the doubt. Strong inputs land in the same band as the weak ones, just with longer praise. A few reasons, roughly in order of how much they hurt: Tuning rewards a helpful, encouraging tone. Harsh scoring reads as unhelpful, so the model softens it. The model has no ground truth for what a 70 versus an 85 looks like in your specific domain. It is scoring on vibes. Scoring and explaining are entangled. The model writes the kind explanation first, then picks a number to match the nice things it just said. Run it twice on the same input and you get two different numbers. There is no anchor. For a portfolio reviewer that real recruiters and developers would act on, that was a non-starter. If Leon says 64, an empty page should not be able to reach 64 by accident, and a strong portfolio should not get talked down to it either. The number has to mean something. The fix: rules engine owns the score, model owns the language The architecture splits responsibilities hard. A deterministic e

Hello Dev Community! 👋 It is officially Day 37 of my continuous streak toward mastering the MERN stack! Yesterday, I configured clean structural routing to map pages like /about or /contact . Today, I advanced further into Prashant Sir's (Complete Coding) backend roadmap to tackle an essential data communication concept: URL Parsing and Query Parameters . When a user searches for something or filters products on an e-commerce platform, that data is passed directly inside the URL string. Today, I learned how to intercept and decode that data natively! 🧠 Key Learnings From Node.js Lecture 5 (The URL Module) An incoming URL is much more than just a text path; it is a complex structured object. Here is the technical breakdown of how I dissected it today: 1. Ingesting the Native url Module I explored Node's legacy and modern URL parsing engines. By passing the raw req.url string into the parser, Node breaks down the web address into a fully accessible metadata object. 2. Dissecting Pathname vs Query String I learned the difference between the structural endpoint location and the dynamic data payload: Pathname: The core location path (e.g., /search or /api/products ). Query: The actual data key-value strings attached after the question mark ? (e.g., ?name=ali&id=7 ). javascript const http = require("http"); const url = require("url"); const server = http.createServer((req, res) => { // Parsing the URL path and query parameters together cleanly let parsedUrl = url.parse(req.url, true); let pathname = parsedUrl.pathname; let queryData = parsedUrl.query; // Converts query text into a clean JS Object! if (pathname === "/search") { res.writeHead(200, { "Content-Type": "text/plain" }); res.end(`Searching logs for user: ${queryData.name} with ID: ${queryData.id}`); } else { res.end("Standard Endpoint View"); } }); server.listen(8000);

มีคำถามที่น่าสนใจเกิดขึ้นระหว่างใช้งาน AI — "มันรู้ได้อย่างไรว่าต้อง return อะไร?" คำอธิบายที่ AI ให้มักฟังดูซับซ้อนและน่าประทับใจ แต่คำตอบที่ตรงไปตรงมากว่านั้นคือ: มันเห็น pattern นี้มาหลายล้านครั้งแล้ว LLM คิดแบบมนุษย์จริง ๆ หรือไม่? คำตอบคือไม่ — แต่มันทำบางอย่างที่ให้ผลลัพธ์คล้ายกับการคิดได้อย่างน่าทึ่ง ลองนึกภาพคนที่ได้อ่านโค้ดทุกบรรทัดที่เคยถูกเขียนบน GitHub, Stack Overflow, เอกสาร library ทุกตัว รวมถึงบทความด้าน programming จากทั่วโลก แล้วจดจำ pattern ทั้งหมดนั้นไว้ LLM คือสิ่งนั้น เพียงแต่ทำในระดับที่มนุษย์ไม่สามารถทำได้ Tokenization: AI มองโค้ดอย่างไร? เมื่อส่งโค้ดให้ AI ประมวลผล มันไม่ได้อ่านทีละตัวอักษร แต่แบ่งข้อความออกเป็น token ซึ่งเป็นชิ้นส่วนที่มีความหมาย pythondef greet(name): return f"Hello, {name}!" โค้ดนี้อาจถูกแบ่งเป็น token ประมาณนี้: def / greet / (name / ): / \n return / f"Hello / , / {name} / !" แต่ละ token ถูกแปลงเป็นตัวเลข (vector) แล้ว model จึงประมวลผลตัวเลขเหล่านั้น Attention Mechanism: ทำไม AI ถึง "เข้าใจ" Context ได้ ส่วนที่น่าสนใจที่สุดของ LLM คือ attention mechanism — กลไกที่ทำให้ model รู้ว่าเมื่อจะ predict token ถัดไป ควรให้ความสำคัญกับส่วนไหนของ input ที่ผ่านมา ตัวอย่างเช่น เมื่อ model กำลังจะเขียน error handling ใน function มันจะวิเคราะห์: ชนิด exception ที่ function อาจ throw pattern ของ error handling ที่ปรากฏในโค้ดใกล้เคียง library ที่ใช้อยู่และวิธีที่มักจัดการ error ทำไม AI จึง Hallucinate บางครั้ง? เพราะ LLM ไม่ได้ "รัน" โค้ดในกระบวนการคิดจริง ๆ มันแค่ทำนาย token ถัดไปจาก pattern ที่เคยเห็น เปรียบได้กับคนที่ศึกษาโจทย์คณิตศาสตร์มาอย่างมากมาย พอเห็นโจทย์ใหม่ก็เขียนวิธีแก้ออกมาดูสมเหตุสมผล แต่ถ้าโจทย์นั้น novel และไม่เคยเห็น pattern ที่คล้ายกันมาก่อน ก็อาจให้คำตอบที่ผิดได้ นั่นจึงเป็นเหตุผลสำคัญว่าทำไมต้อง test โค้ดที่ AI เขียนทุกครั้ง สรุป LLM เขียนโค้ดได้ดีเพราะสามเหตุผลหลัก: เห็น pattern มาในปริมาณมหาศาล, มี attention mechanism ที่ช่วยเชื่อมโยง context, และถูก fine-tune ให้ output มีประโยชน์จริง การเข้าใจกลไกเหล่านี้ช่วยให้ใช้งาน AI ได้ฉลาดขึ้น — รู้ว่าเมื่อไหรควรเชื่อผลลัพธ์ และเมื่อไหรควรตรวจสอบเพิ่มเติม ด้วยความสามารถของ

One of the most persistent traps in modern software development is the tendency to turn architectural styles into absolute dogmas. We see it constantly on social media and inside engineering rooms: teams arguing over cloud native versus cloud agnostic as if they are choosing a lifelong political alignment. A recent perspective from the engineering team at GeekyAnts titled "Cloud-Native and Cloud-Agnostic Are Not Ideologies; They Are Business-Stage Decisions" cuts through this industry noise. Looking critically at their argument, it becomes clear that many organizations are suffering from premature architectural complexity. Engineering leaders frequently romanticize absolute portability long before their business has the operational maturity or the market validation to justify it. The core takeaway is simple yet profound: your architectural choice should be a reflection of your business stage, not a philosophical stance. The Go To Market Trap In the earliest stages of a business, the primary goal is not infinite scalability. The primary goal is survival. A startup needs to discover product market fit before running out of capital. This requires maximum release velocity, rapid experimentation, and minimum operational overhead. For an early stage company, leveraging a cloud native approach is entirely rational. Relying on managed databases, serverless functions, provider native identity management, and integrated monitoring allows a tiny engineering team to focus entirely on product features. The critical flaw in many early architecture reviews is treating this cloud dependency as a failure. It is actually a deliberate speed asset. At this stage, worrying about vendor lock in is a distraction because if you do not find customers quickly, there will be no vendor left to be locked into. Changing Priorities as the Business Matures The architecture that helps a company launch is rarely the one that sustains its long term growth. As a software product gains traction, the op