标签：#Web

I used to deliver food on Zepto. 14-15 hours a day. Sun, rain, didn't matter. I saved up, bought a laptop, and started doing video editing for clients. That's when things got messy. I was managing clients on WhatsApp. Tracking who paid me in Google Sheets. Sending invoices as PDF attachments that nobody opened. Every new client meant another chat group, another row in my spreadsheet, another folder I'd forget about. I went looking for one tool that could handle all of this. CRM, invoicing, projects, client communication — in one place. Everything was either $200+/month (when you add up all the separate tools) or missing basic stuff like a client portal. So I started building my own. That was a month ago. What I actually built Arpixa. One dashboard for agencies and freelancers. CRM, invoicing, project boards, AI assistant, file manager, scheduling, analytics, and a client portal where your clients can view projects, pay invoices, and message you. Every agency gets a branded subdomain — youragency.arpixa.io. Your clients see your brand, not mine. I'm not going to dump the whole feature list here. You can check arpixa.io if you're curious. The hard parts nobody warns you about Subdomains are a nightmare. Giving every user their own subdomain sounds simple until you realize auth doesn't work across subdomains by default. I had to build a token handoff system where you log in on one domain and the session gets securely passed to your workspace subdomain. It took longer than I expected going in — auth is the part everyone assumes is solved and nobody explains. Two payment gateways, because one isn't enough. I integrated both Stripe and Razorpay. Stripe for international users, Razorpay for India (UPI is how everyone pays here). The app auto-detects your country and shows the right payment flow. Sounds fancy — mostly it was just a lot of logic and twice the amount of webhook handling. Security rules will humble you. I wrote database-level security rules for every single co

A cat astrologer, spec-driven and running on Amazon Bedrock A companion to A Builder in Paris: Do Devs Dream of Électrique Chats? Last month I wrote about the idea. Six rainy days in Paris, a closed laptop, and a hackathon I did not mean to enter, and somewhere between the Musée de l'Orangerie and a lot of walking, an idea arrived. Cats are inscrutable. The people who love them are obsessed with understanding them anyway. Astrology is an old framework for making the unknowable feel readable, and maybe, just maybe, it helps us understand them a little. Her name is Madame Minou , a French cat astrologer who reads your cat's stars from a café terrace. That first article was the idea . This one is the build. Vibe-coded, but on rails Was it vibe-coded? You know it! AI wrote the lines, and I said "no, not like that" more times than I can count. But it was vibe-coding on rails, and the rails were Kiro. Before a single line of app code, I wrote the requirements in EARS notation, a design doc, and a build-ordered task list, all living in .kiro/specs . Decide what "done" means before letting anyone, human or model, start building. The specs are what kept the vibes on track. Then the steering files. .kiro/steering held the enduring rules of the project: product principles, security guardrails, technical direction, and UI law. These were the thing that kept a long, multi-session build from drifting. When a new session opened, the steering files were already the shared context. "The café blue" was one token, not five guesses. Security was not optional. The garbled café sign was a deliberate easter egg, not a bug to fix. From there, the loop: Kiro implemented one approved block at a time, ran each task's PASS/FAIL QA gate on itself before moving to the next, and only stopped for my review on the two things that actually mattered. I directed and approved. Kiro proposed and built. Spec first, block by block, human in the loop. The facts are sacred Here is the part that looks like a

How we integrated real-time phrase translation feedback into our AI-powered book translation workflow, and what we learned about latency, context, and prompt engineering. When we launched LectuLibre, our AI-powered book translation platform, users loved the quality of full-chapter translations. But they kept asking for something else: while reading a partially translated book, they'd stumble on an untranslated phrase or an awkward auto-translation and want to quickly get a better version without leaving the page. So we built 即时翻译求助 (Instant Translation Help)—a feature that lets readers highlight any phrase and get a context-aware, human-quality translation within seconds, along with a brief explanation of tricky parts. Here's how we built it, the technical challenges we faced, and the lessons we learned about stitching LLMs into a real-time reading experience. Problem: Real-time, Context-Aware Translation Inside a Book Most web apps offer generic translation via API calls—send a sentence to Google Translate, get a result. But that doesn't work for literary texts. A phrase like "She let the cat out of the bag" needs to be translated idiomatically, and the appropriate rendering depends heavily on the surrounding paragraphs (is the tone formal? sarcastic? part of a metaphor chain?). Our existing translation pipeline processes entire chapters in bulk with carefully crafted prompts, but for instant help, we needed sub-second latency while preserving that same depth of context. Our Approach: Server‑Sent Events and a Smart Prompt Buffer We chose Server-Sent Events (SSE) over WebSockets because the communication is one-directional (server pushes translation tokens) and SSE is simpler to implement with FastAPI. The client (a React app) sends a POST request with: The phrase to translate The book ID and the exact location (chapter/paragraph index) The target language Our backend retrieves the surrounding text from PostgreSQL (we store the original book in chunks), feeds a care

📖 Article original : GitHub Gist Un guide technique par Mohamed ben mallessa Le problème Recevoir un dossier de 500 fichiers HEIC à convertir en WebP pour un site web est une situation courante pour tout développeur. Les solutions traditionnelles ont leurs limites : ImageMagick nécessite des codecs spécifiques, les convertisseurs en ligne sont limités en taille, et le traitement manuel est exclu à cette échelle. La solution Photopea (Photoshop gratuit dans le navigateur) supporte nativement tous les formats d'image courants. En l'utilisant comme moteur de conversion piloté par script, on obtient un pipeline batch rapide et fiable. Formats supportés Entrée Sorties possibles HEIC / HEIF JPG, PNG, WebP JPEG WebP, PNG, PSD PNG JPG, WebP WebP PNG, JPG PSD PNG, JPG, WebP SVG PNG, JPG TIFF PNG, JPG, WebP Pipeline Dossier source (500 HEIC) → Photopea → Dossier sortie (500 WebP) Le script préserve la structure des sous-dossiers, applique le redimensionnement et la qualité configurés, et livre les fichiers organisés. Paramètres typiques --format webp # Format de sortie --quality 80 # Qualité (1-100) --resize 1920 # Redimensionnement (côté long) --output ./web/ # Dossier de destination Avantages Un seul outil pour tous les formats d'entrée Aucun codec à installer (Photopea gère tout nativement) Gratuit et sans abonnement Local — les fichiers ne quittent pas votre machine Structure préservée — l'arborescence est conservée Mohamed ben mallessa — Full-stack developer & solutions B2B 🔗 GitHub · LinkedIn opensource #webp #python #tutorial 💻 Vous avez un projet technique ? Développement full-stack, automatisation IA, solutions B2B sur mesure. 🔗 GitHub 💼 LinkedIn 🎨 Behance Article initialement publié sur GitHub Gist

We’ve all been there. You start your morning feeling like a Productivity God, sitting straight and typing at 120 WPM. Fast forward four hours, and you've morphed into a literal shrimp, face inches away from the monitor, hunting for a missing semicolon. 🦐 In this era of remote work, real-time posture correction and computer vision for health have become more than just "cool projects"—they are spinal lifesavers. Today, we’re going to build a desktop application using MediaPipe , WebRTC , and Electron that monitors your neck angle and sends a desktop notification the moment you start slouching. By leveraging MediaPipe Pose and TensorFlow.js , we can calculate the Forward Head Posture (FHP) ratio with surgical precision directly in the browser environment. The Architecture 🏗️ Before we dive into the code, let’s look at how the data flows from your webcam to that "Sit up straight!" notification. graph TD A[Webcam Feed] -->|MediaStream| B(WebRTC API) B -->|Video Frames| C[MediaPipe Pose Model] C -->|Landmarks| D{Geometry Engine} D -->|Calculate Ear-Shoulder Angle| E{Threshold Check} E -->|Angle > 30°| F[Electron Main Process] F -->|Trigger| G[System Desktop Notification] E -->|Healthy| H[Continue Monitoring] style G fill:#f96,stroke:#333,stroke-width:2px Prerequisites 🛠️ To follow along, you'll need the following tech stack: MediaPipe Pose : For high-fidelity body tracking. WebRTC : To capture the video stream from your webcam. Electron : To wrap our logic into a desktop app that runs in the background. TensorFlow.js : The backbone for running ML models in JavaScript. Step 1: Setting up the Video Stream (WebRTC) First, we need to grab the camera feed. In a modern browser environment (or Electron's Chromium), we use navigator.mediaDevices.getUserMedia . async function setupCamera () { const videoElement = document . getElementById ( ' input_video ' ); const stream = await navigator . mediaDevices . getUserMedia ({ video : { width : 640 , height : 480 }, audio : false }); v

If you've ever built a feature that extracts text from PDFs, an Arabic-speaking user has probably filed this bug: "the words come out in reverse order." Not the letters — the words . Every line reads last-word-first. I spent the better part of a year fixing this class of bugs while building Confileo , a free PDF toolkit with first-class Arabic support. Here's what's actually going on, because almost every explanation online is wrong or incomplete. The four distinct failure modes People say "Arabic breaks" as if it's one bug. It's four: 1. Visual vs logical order (the reversed-words bug) A PDF doesn't store text the way a Word file does — it stores positioned glyph runs : "paint these shapes at these coordinates." For left-to-right scripts, the paint order happens to match the reading order, so naive extraction works by accident. Arabic is right-to-left. Many PDF generators emit the glyph runs in visual order — the order they appear on screen, left to right. A naive extractor concatenates the runs as stored and produces every line word-reversed. The text was never "reversed" in the file; your extractor just assumed paint order == reading order. Fix: reconstruct logical order using glyph positions + the Unicode Bidirectional Algorithm (UAX #9), not the content-stream order. Libraries like PyMuPDF already return text in logical order — a common mistake is "fixing" that output by reversing it again, which is how you get double-reversed text. Rule of thumb: never reverse Arabic yourself. If it looks backwards, your rendering layer lacks bidi support; the data is usually fine. 2. Disconnected letters (the ransom-note bug) Arabic letters are contextual: ع renders differently in initial, medial, final and isolated positions, and letters join. That joining is applied at render time by a shaping engine (HarfBuzz being the standard). If any step of your pipeline round-trips text through a non-shaping renderer — a canvas library, a barebones PDF writer, an image caption filter

Every business that has ever typed a web address into a browser owes a small debt to a company most people have never heard of. On March 15, 1985, a computer maker called Symbolics registered Symbolics.com and, in doing so, became the first ever holder of a .com domain name. More than forty years later that address is still registered and still resolves - making it the oldest .com domain on the internet. Who was Symbolics? Symbolics Inc. was a Massachusetts company that built specialized computers called Lisp machines - workstations designed from the silicon up to run the Lisp programming language, then the darling of artificial intelligence research. These were serious, expensive machines aimed at labs and universities, and the company sat right at the cutting edge of 1980s computing. So it was fitting, if a little accidental, that they were first in line when commercial domains became available. The domain name system itself was brand new. DNS had only been introduced in 1983 to replace the unwieldy HOSTS.TXT file that every machine on the early internet had to keep in sync. The now-familiar top-level domains - .com , .org , .net , .edu , .gov - were defined in 1984. When registration opened, .com was meant for commercial entities, and Symbolics grabbed theirs before anyone else did. A slow start for the web's most valuable real estate What is striking today is how little demand there was. In the whole of 1985, only a handful of .com domains were registered - names like BBN, Think, and a few other technology companies trickled in over the following months. There was no gold rush, because there was no web yet. Tim Berners-Lee would not propose the World Wide Web until 1989, and the first website would not appear until 1991. A domain name in 1985 was a technical convenience for reaching a machine, not a brand or a piece of property. That makes Symbolics.com a kind of time capsule. It was registered before the web, before browsers, before e-commerce, and before anyon

Notes from shipping a real-world PWA in Korea: Vite SSG is worth it. SPAs lose Korean SEO because Naver's crawler doesn't fully render JS. Leaflet > Mapbox for cost-sensitive projects. Free OSM tiles + zero cost. Firebase Hosting rewrites let you have deep URLs (/city/suwon) without a backend. KakaoTalk share is non-negotiable in Korea — 70%+ of social traffic. PWA install banner: don't auto-prompt, let the user discover. Project: https://gyeonggi-currency-map.web.app?ref=devto&utm_source=devto&utm_medium=social&utm_campaign=multi-site-bot

OAuth recovery emails look harmless until you test them the lazy way. A team sends password reset links or recovery codes into one shared mailbox, confirms that something arrived, and marks the job done. From a security view, that test is too weak. It can hide token reuse, wrong-user delivery, or log retention that exposes sensitive account events. For non-production checks, I like using a disposable email address that belongs to one test run. Some teams build that inbox layer themselves, some use tempmailso, but the core principle is the same: isolate the recovery event, inspect it quickly, and delete the evidence you no longer need. That is helpful when Authentication and OAuth changes ship together. Why OAuth recovery emails deserve their own threat model Recovery email tests are not just "did the mail send?" checks. They sit on the edge of account takeover risk, so the message itself matters almost as much as the login flow. A decent threat model for these emails should ask: did the message reach only the intended inbox for this run? does the link or code expire when the product says it does? is the message revealing too much user data in subject lines or previews? can an older token still be used after a new recovery request? do logs or test fixtures keep the recovery secret longer than they should? This is where shared inboxes become dangerous in a subtle way. Even if nobody has bad intent, mixed test data makes it harder to prove which token belonged to which request. The same operational confusion shows up in email change confirmation checks , and it gets worse when the email can restore account access. OWASP recommends testing authentication recovery features with the same care as sign-in and session controls, because weak recovery paths are a common bypass route for stronger primary login defenses: https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html A safer test flow for recovery links and codes The cleanest pattern is one inbox

This is a reprint from my tips blog. You can find the original article here: [ https://tips.ojapp.app/en/ios-android-pwa-goal-difference-3/ ] Android vs. iPhone: Different Goals for PWAs When people talk about PWAs, the explanation often sounds like this: Android supports PWAs. iPhone does not support PWAs very well. If you only look at the PWA specifications, this explanation is easy to understand. Android Chrome supports manifest.json, Service Worker, installation, notifications, shortcuts, and many other PWA features quite strongly. iPhone Safari, on the other hand, does not behave the same way as Android. But after testing PWAs on both iPhone and Android many times, I started to see the difference in another way. More accurately, Android and iPhone have different goals for PWAs. That is the biggest difference I noticed while testing repeatedly. Android tries to turn web pages into apps Android PWAs are clearly designed in the direction of making web pages feel closer to native apps. The idea is to take a website opened in the browser and move it toward a native-app-like experience. This direction is very strong on Android. That is why many PWA-related features are well supported. manifest.json Service Worker Push notifications Install Prompt Shortcuts theme_color background_color maskable icons display modes orientation Of course, it is not perfect. Manifest cache can be stubborn, multiple PWAs on the same domain can become confusing, and real-device testing can still create plenty of traps. Even so, when you build according to the PWA specification, Android usually responds in a fairly straightforward way. For example, if you set display: fullscreen , the app feels much more full-screen. theme_color is often reflected in the toolbar color. orientation also works quite strongly on Android. In other words, for Android, a PWA is an app made from the Web . iPhone starts from the experience of placing web pages on the home screen iPhone is different. Even before the

My father is a stroke patient. Watching him try to speak clearly again — with patience, repetition, and no small amount of courage — is what pushed me to build Voice Revive. It’s a free web app for stroke survivors and people with aphasia: pick a category, hear a word, say it back, get forgiving feedback. No accounts, no scores, no pressure. I vibecoded most of it with AI tools, but the reason behind it is deeply personal. If it helps even one person feel a little more confident speaking again, it was worth it. Let’s work together: Voice Revive is a personal project, and I’m open to: Collaboration — features, accessibility, reaching more people who need it Sponsorships — to keep the app free and accessible Part-time / freelance web development — I’m comfortable building with: What I work with today: Next.js & TypeScript Node.js (Express) Python (FastAPI) Tailwind CSS What I’ve built with before (freelance): Kotlin & Java for Android Development(previous experience - freelance) ESP32 & C++ for IOT Development Try it: https://voicerevive.online/ Connect with me: https://www.linkedin.com/in/aaron-mercado-163b02369/

I have been turning old code projects into sellable source-code products. The hard part is not changing the cover image. It is not renaming the ZIP. It is deciding whether the project deserves to be sold at all. A lot of old apps are useful to the person who built them. Far fewer are useful to a stranger who has never seen the repo, never heard the backstory, and only wants to know one thing: Will this save me time, or will it become another folder I regret buying? Here is the checklist I now use before treating a source-code project as a starter kit. 1. The buyer must understand the workflow "Full-stack dashboard" is not enough. A buyer should immediately understand the workflow the project helps with. For example: a review and scoring portal; a maintenance and work-order dashboard; an email-template governance tool; a runnable technical code lab. The more generic the product sounds, the harder it is to buy. I now try to answer this in one sentence: This kit helps [specific buyer] start from a working foundation for [specific workflow]. If I cannot fill that sentence honestly, the project is not ready. 2. A stranger must be able to run it "It runs on my machine" is not a product standard. A buyer needs a path from download to working state. That usually means: setup instructions; environment notes; seeded demo data; demo accounts or fixtures; expected local startup behavior; known limitations; a simple smoke-test checklist. The goal is not perfection. The goal is that a competent developer should not have to reverse-engineer the project before deciding whether it is useful. 3. The product needs proof, not adjectives Marketing adjectives are cheap: production-ready; powerful; scalable; enterprise-grade; battle-tested. Most of those words create more risk than trust if they are not backed by evidence. Better proof looks boring: screenshots; a short demo video; a verified release ZIP; install notes; architecture notes; included / not-included boundaries; a changelog;

Welcome to My Generative AI Learning Journey Artificial Intelligence is changing the way we work, learn, build software, and solve problems. Every day, new AI tools, models, and technologies are being released, making it difficult to know where to begin. Instead of randomly watching videos or reading articles, I've decided to follow a structured learning path—and I'm inviting you to join me. This blog marks the beginning of a long-term Generative AI learning series. Whether you're a student, software developer, freelancer, entrepreneur, or simply curious about AI, this roadmap will help you understand what we'll learn together over the coming weeks and months. The goal isn't just to understand AI theory. It's to build practical skills that can be used in real-world projects and professional development. Why Learn Generative AI in 2026? Generative AI is no longer a futuristic concept. It is already transforming industries such as: Software Development Healthcare Education Finance Marketing Customer Support E-commerce Human Resources Design and Creativity Companies are actively seeking professionals who can build AI-powered applications, automate workflows, and integrate AI into existing systems. Learning Generative AI today means preparing for the next generation of technology. What You Can Expect from This Series This series is designed for beginners but will gradually move toward advanced concepts. Each article will build upon the previous one, making the learning process simple and structured. We'll focus on: Understanding AI concepts Learning industry terminology Exploring popular AI models Writing effective prompts Building AI applications Working with APIs Using open-source models Creating AI-powered software Deploying AI projects By the end of this journey, you'll have both theoretical knowledge and practical development experience. Complete Learning Roadmap Phase 1: AI Fundamentals We'll begin by building a strong foundation. Topics include: What is Generativ

Bootstrap 5 and Tailwind CSS are the two most popular CSS frameworks in 2026. If you're starting a new project and trying to decide between them, this guide gives you an honest comparison based on real-world usage — not just feature lists. The Core Difference Bootstrap 5 gives you pre-built components. Tailwind CSS gives you utility classes to build your own. That's the fundamental difference and it drives every other comparison. With Bootstrap you get a navbar, modal, card, and dropdown out of the box. With Tailwind you build those yourself using utility classes like flex , px-4 , bg-blue . Neither is wrong. They solve different problems for different teams. When Bootstrap 5 Makes More Sense You Need to Ship Fast Bootstrap's pre-built components mean you spend less time on UI and more time on business logic. For admin dashboards, CRM panels, and internal tools — where UI consistency matters more than pixel-perfect custom design — Bootstrap is the faster choice. Your Team Knows HTML and CSS Bootstrap has a shallow learning curve. Any developer who knows basic HTML and CSS can pick up Bootstrap in a day. Tailwind requires understanding its utility-first philosophy and memorizing class names. You're Building an Admin Dashboard Admin dashboards need data tables, modals, dropdowns, sidebars, and form components — all of which Bootstrap provides out of the box. Building these from scratch with Tailwind takes significantly more time. You Want Predictable Output Bootstrap's components look consistent across browsers and screen sizes without extra configuration. Tailwind output depends heavily on how well your team implements it. When Tailwind CSS Makes More Sense You're Building a Custom Marketing Site If your design is highly custom — unique layouts, non-standard components, pixel-perfect design system — Tailwind gives you more flexibility without fighting Bootstrap's default styles. You Have a Design System Already If your team has a defined design system with specific t

Walkthrough experience includes visits to stars, exoplanets, and observatories.

Are you a football fan? Since the FIFA hype is at its absolute peak at this moment, it is hard to...

When I published the first article about the Neuron AI Router , I expected questions about routing rules. Which rule to use for structured output, how to write a custom one, how the round robin behaves under load. Some of those questions arrived, but the most frequent one was different, and it wasn't really about routing at all. It was about failure. What happens to my agent when the provider goes down? It is a fair question, and if you are new to building AI applications it deserves a proper answer before we look at any code. Here is the short version. The new fallback strategy in Neuron AI Router lets you define an ordered list of LLM providers for your PHP agent. When an inference call fails with a transient error, such as a rate limit, a timeout, or an overloaded server, the same request is automatically retried on the next provider in the list. The failover is transparent: the agent never knows it happened, and the conversation continues without losing state. The rest of this article explains why this problem exists, why the usual solutions fall short, and how to configure it. Why LLM providers fail in production An LLM provider is an external service you talk to over HTTP. Every time your agent thinks, it is making a network call to a machine you don’t control, operated by a company that is currently serving millions of other requests. These services fail in very ordinary ways. You hit a rate limit because your traffic spiked. The provider returns an “overloaded” error because their traffic spiked. A request times out. A deployment on their side causes a few minutes of elevated error rates. None of this means you did something wrong, and none of it is rare. If you keep an agent in production long enough, you will see all of these. In a classic web application, a failed call to a third party API is usually a corner of the system. You log it, maybe retry it in a queue, and the rest of the page still works. In an agent based application the inference call is not

The Shop on the Corner: How I Learned System Design Without Building Amazon Nephew asks his uncle — 10 years deep into building large-scale systems — to explain "system design," and all the scary jargon that comes with it. Uncle refuses to start with the jargon. Instead: "Forget servers and databases for a minute. Just imagine you're running a small shop." What follows is a thought experiment, built one problem at a time — no cloud bills, no fancy stack, just a counter, a storeroom, and a lot of common sense. Part 1: The Counter — Your First "API" 👦 Nephew: Uncle, everyone at work keeps throwing around terms — load balancer, cache, index, sharding. I nod along, but I don't actually get any of it. 👨‍🦳 Uncle: Then don't start there. Close your eyes for a second and forget servers exist. Suppose — just suppose — you're running a small shop. One counter, one small storeroom at the back. A customer walks up and asks for something. What do you do? 👦 Nephew: I'd walk into the storeroom, find it, walk back, hand it over. 👨‍🦳 Uncle: That's it. That's the entire job of a server handling a request. You don't need to understand Amazon's warehouse to understand Amazon's problems. You need a counter and a storeroom, imagined clearly, and the patience to grow them one honest problem at a time. Here's the shape of what you just described, whether you realized it or not: 🧍 Customer 🧑 You (Counter) 📦 Storeroom (Database) | | | |── "Got Maggi?" ───────>| | | |──── Walk in, search ────────>| | |<─────── Found it ────────────| |<── Hand it over, ──────| | | take payment | | 👨‍🦳 Uncle: One customer, one request, one trip to the storeroom, one response. This is fine. This is correct , even, for a shop with five customers a day. Don't let anyone tell you a single counter isn't "scalable" — a shop that small doesn't need two counters, it needs someone to stop worrying and open the shutter. 👦 Nephew: So this is just... a server handling one request at a time? 👨‍🦳 Uncle: Exactly. Customer sen

Google has released A2UI v0.9, a framework-agnostic standard for AI agents to declare user interface intent across multiple platforms without arbitrary code. The update emphasizes alignment with existing design systems. It includes a new SDK for Python, improved error handling, and various transport methods. Migration guidance and evolution specifications are also provided. By Daniel Curtis

สวัสดีครับเพื่อนๆ! 👋 วันนี้จะมาเล่าเรื่องน่าตื่นเต้นให้ฟังนะเพื่อนๆ สำหรับใครที่เป็นสาย SvelteKit เตรียมตัวอัปเดตความรู้ใหม่กันได้เลย เพราะตอนนี้เขามีของเล่นใหม่ที่กำลังอยู่ในช่วงทดลองใช้งาน แต่บอกเลยว่าว้าวมาก! เราไปดูกันดีกว่าว่ามันคืออะไร... 📡 Remote function คืออะไร เป็น function ตัวใหม่ ✨ (ที่คาดว่าจะเป็น new way to implement สำหรับ Sveltekit 3.0) เอาไว้ใช้สื่อสารพูดคุยกันระหว่างฝั่ง client และ server ของ Sveltekit นั่นเอง 💬 ความเจ๋งคือเราสามารถเรียกใช้มันจากมุมไหนของ Sveltekit ก็ได้ 🌍 ไม่จำเป็นต้องจำกัดแค่ฝั่ง server หรือ client แต่จุดสำคัญคือ การทำงานของมันจะเกิดขึ้นที่ฝั่ง server เสมอ 👍 นั่นหมายความว่ามันสามารถทะลุทะลวงไปดึงข้อมูลหรือโมดูลที่เป็น server-only ได้สบายๆ เช่น ตัวแปร environment ที่เราประกาศไว้ หรือพวกฐานข้อมูลต่างๆ ก็ดึงมาได้ชิลๆ เลย 😎 เวลาจะใช้งาน เราจะต้องใช้ท่าการ await แบบใหม่ของ Sveltekit ⏳ ที่ช่วยให้คุณโหลดหรือดึงข้อมูลแบบ promise มาใช้ใน component ของคุณได้ทันที 🚀 ⚠️ หมายเหตุ: ตอนนี้ทั้ง await และ remote function ยังอยู่ในช่วงทดลองใช้งาน 🧪 (experimental) นั่นแปลว่า syntax บางอย่างอาจจะมีการปรับเปลี่ยนหรือบินหายไปบ้างในอนาคต 🥲 แต่แกนหลัก (core functional) ของมันก็จะยังทำงานได้ตามที่เราคาดหวังแน่นอน ถ้าใครคันไม้คันมืออยากลองของใหม่ตอนนี้ สามารถไปเปิดโหมด experimental ได้ที่ไฟล์ svelte.config.js(.ts) ตามโค้ดด้านล่างนี้เลย 👇 svelte.config.js(.ts) /** @type {import('@sveltejs/kit').Config} */ const config = { kit : { experimental : { remoteFunctions : true } }, compilerOptions : { experimental : { async : true } } }; export default config ; 🏃‍♂️ Let get started!! เราสามารถเริ่มใช้ remote function ได้ง่ายๆ ผ่านการสร้างไฟล์นามสกุล .remote.js หรือ .remote.ts 📝 ซึ่งตอนนี้มี function ให้เราหยิบมาเล่นทั้งหมด 4 ตัวด้วยกันคือ: query (ที่เราจะมาพูดถึงกันในบทความนี้) form command prerender หลักการทำงานเบื้องหลังคือ เวลาที่เรา import ตัว remote function ไปใช้ในฝั่ง client มันจะถูกแอบแปลงร่างเป็นโค้ดที่หุ้มด้วย fetch ในช่วง build time 🏗️ นั่นหมายความว่าระบบจะใจดีสร้างเส้น HTTP endpoint ให้เราแบบอัตโนมัติ ✨ ด้วยเหตุนี้เราเลยเอาไฟล์ .remote.js หรือ .remote.