标签：#Web

Building a developer portfolio is more than just listing skills—it's about creating an immersive experience that demonstrates your engineering capabilities in real-time. In this article, I want to share how I engineered my full-stack 3D portfolio website using React.js , Three.js , Tailwind CSS , and Next.js . 🚀 Key Features of the Portfolio: Interactive 3D Workspace : Integrated @react-three/fiber and @react-three/drei to render a interactive 3D desktop PC model. Production Case Studies : Showcased 10+ live deployed production web applications built for clients across the UAE (Dubai, Abu Dhabi) and India. Optimized Performance & SEO : Configured custom Schema.org JSON-LD markup, XML sitemaps, and canonical tags for instant search indexing. Modern UI/UX Aesthetics : Styled with dynamic dark glassmorphism gradients and responsive navigation patterns. 🛠️ Tech Stack Used: Frontend : React 18, Next.js, Three.js, GSAP Animations Backend : Node.js, Express.js, RESTful APIs Database : MongoDB & Mongoose Deployment : Vercel CI/CD 🌐 Check Out the Live Site & Connect! You can explore the live interactive 3D website and view my production projects here: 👉 Official Portfolio : Muhammed Rifad KP | Full Stack Developer Feel free to share your feedback or reach out if you'd like to collaborate on web engineering projects! Developed by Muhammed Rifad KP

The idea Most apps give you a static background. I wanted Pairly to feel alive instead, so I built "Atmosphere": a real-time animated Canvas layer that sits behind every chat, fully tunable by the user, speed, density, opacity, brightness, saturation, all live. There are currently over 40 atmospheres in the system, from calm ones like Snow and Fireflies to more elaborate ones like a black hole accretion disk called Abyss. The interesting part wasn't drawing pretty particles. It was making that work smoothly on a five-year-old Android phone without draining the battery in ten minutes. Two rendering paths, not one Atmosphere isn't a single renderer, it's a small internal package ( @pairly/atmospheres ) with two shared engines that every individual atmosphere builds on: ParticleCanvas , a generic particle system for anything made of many independent objects: snow, fireflies, sakura petals. useCanvasLoop , a raw draw-loop hook for continuous scenes that aren't particle-based, like Abyss's swirling accretion disk. Both engines centralize every "don't destroy the device" concern in one place, so individual atmospheres never have to think about it. Here's useCanvasLoop 's frame loop: const frameInterval = 1000 / perf . fps ; let raf = 0 ; let last = performance . now (); let acc = 0 ; const loop = ( now : number ) => { if ( ! running ) return ; raf = requestAnimationFrame ( loop ); const elapsed = now - last ; last = now ; acc += elapsed ; if ( acc < frameInterval ) return ; const dt = acc / 1000 ; acc = 0 ; draw ( ctx , width , height , elapsedTime , perf ); }; requestAnimationFrame fires at the display's native rate (often 90-120Hz on phones now), but that doesn't mean you should draw every single time it fires. This accumulator pattern throttles actual drawing down to the target FPS from the device's performance profile, instead of trusting rAF's raw rate. Profiling the device before drawing anything Before any atmosphere renders a single frame, it checks the device: ex

Every accessibility tool I have used reports violations like this: Images must have alternative text body > main > div:nth-child(2) > form > div.field > img That selector is correct. It is also useless. It describes the rendered DOM , and I do not write rendered DOM — I write templates. Somewhere in a few hundred .component.html files there is an <img> that produced it, and finding it is manual work: grep for img , get forty hits, open them one by one, compare surrounding markup until something matches. Multiply that by sixty violations and the scan stops being useful. Not because it is wrong, but because acting on it costs more than ignoring it. React solved this years ago If you write JSX, babel-plugin-transform-react-jsx-source puts a _debugSource on every element at build time — file, line, column. That is how React DevTools can jump you straight to source, and how error overlays point at the right line. Angular has no equivalent. The compiler knows the position of every element in every template: it has to, to report template errors. But nothing carries that knowledge into the DOM. So I built the bridge. parseTemplate hands you the positions @angular/compiler exports parseTemplate , the same entry point @angular-eslint uses. Give it a template string and you get an AST where every node carries a sourceSpan with byte offsets, lines and columns: import { parseTemplate } from ' @angular/compiler ' ; const parsed = parseTemplate ( source , filePath , { preserveWhitespaces : true }); // each element node has startSourceSpan.start.{offset,line,col} Two things to know immediately. The compiler counts lines and columns from zero , and every editor counts from one — so you add one, or every location you report is off by one in both axes and nobody trusts the tool again: line : span . start . line + 1 , // the compiler counts from zero, editors do not column : span . start . col + 1 , And preserveWhitespaces: true matters: without it the offsets you get back describe a t

A generic image model is rewarded for producing a convincing picture. A virtual-staging system has a stricter job: produce a convincing picture without changing the property being represented . That distinction sounds small until you build a workflow around real listing photos. A beautiful render can still be unusable if a window moves, a doorway narrows, the floor line bends, or the apparent depth of the room changes. The model has improved the image while damaging the information. This is why I have come to think of virtual staging as a constraint problem rather than a styling problem. The source photo is part of the product contract In an inspiration tool, the uploaded image is a prompt. In a listing workflow, it is evidence. The walls, windows, doors, flooring, built-ins, camera position, and room proportions describe a property that a buyer may later visit. Those elements are not raw material for creative interpretation. They are invariants. That changes how the product should talk to users. Instead of asking only, “Which style do you want?”, the interface should also make the operational boundaries clear: Is the room empty or furnished? Should movable furniture be replaced? Which architectural elements must remain untouched? Is the result intended for an MLS, a brochure, or a social post? Does the final image require a disclosure label? These questions are not secondary settings. They define the job. Separate movable objects from structural truth One practical design decision is to treat furniture replacement and room staging as related but distinct operations. An empty room needs furniture added. A furnished room may need existing movable objects removed or replaced before new furniture is introduced. If the system treats both cases as “redesign this image,” it is more likely to improvise around everything in the frame. A better mental model is: Preserve the structural layer. Identify the movable layer. Replace or add only what the user requested. Compare the

The Performance Wall: Why React Isn't a Data Buffer If you’ve ever built a real-time application—a trading dashboard, a crypto ticker, or a live sensor monitor—you’ve likely hit the "React Performance Wall." You pipe your WebSocket messages directly into useState , and suddenly, your browser becomes a stuttering, unresponsive mess. The culprit is simple but often misunderstood: React is a UI library, not a data buffer. When you treat React state as the ultimate source of truth for every single byte of incoming data, you are essentially asking React to trigger a reconciliation cycle for every packet. If your backend is pushing data at 1,000Hz, you are trying to force 1,000 renders per second. Even the most optimized React app cannot handle that. You are blocking the main thread, tanking your frame rate, and leaving your users with a "lag machine." The "Death by a Thousand Cuts" Problem React’s reconciliation process is brilliant, but it is not built to trigger 1,000 times a second. Every setState call schedules a render. If you have a complex component tree, each render triggers diffing, lifecycle hooks, and DOM updates. When updates arrive faster than the browser can paint (typically 60Hz or 16.67ms per frame), you create a backlog of "long tasks." The browser’s main thread becomes so busy trying to keep up with the data stream that it ignores user interactions like clicks or scrolls. Your UI stops being a tool and starts being a bottleneck. The Architectural Shift: Decouple Ingestion from Rendering The fix isn't to optimize your components; it's to change your architecture. You need to stop letting React "know" about every single data point. At York.ie, we achieved a 40% boost in responsiveness by implementing a Dam Pattern . Instead of pushing packets directly into state, we treat the data flow like a dam: the water (data) flows in at high pressure, but we release it to the UI in controlled, manageable bursts. The Implementation Strategy Buffer Ingested Data: Use

Originally published on tamiz.pro . The proliferation of IoT devices, 5G networks, and real-time data processing demands has catalyzed a fundamental shift in computing paradigms: the move from centralized cloud infrastructure to distributed edge computing. This architectural evolution brings data processing and storage closer to the source of data generation, minimizing latency, conserving bandwidth, and enabling autonomous operations. However, distributing compute power across a vast, often heterogeneous network of edge nodes introduces significant complexities, particularly concerning middleware—the connective tissue enabling communication and data flow—and its inherent challenges around security and scalability. This deep-dive will explore the architectural implications of edge computing on middleware, focusing on the critical facets of security and scalability that define success or failure in this distributed landscape. Table of Contents 1. Understanding the Edge Computing Paradigm 2. The Role of Middleware in Edge Architectures 3. Middleware Security Challenges at the Edge 4. Strategies for Securing Edge Middleware 5. Scaling Middleware in Edge Environments 6. Architectural Patterns for Scalable Edge Middleware 7. Practical Considerations and Best Practices 8. Frequently Asked Questions 1. Understanding the Edge Computing Paradigm Edge computing extends the capabilities of cloud computing by bringing computation and data storage closer to the 'edge' of the network, where data is generated. This can range from industrial IoT devices, smart city sensors, retail points of sale, autonomous vehicles, and even user devices like smartphones. The primary motivations for this shift include: Reduced Latency: Processing data locally eliminates round trips to a central cloud, crucial for real-time applications like autonomous driving or industrial automation. Bandwidth Optimization: Only aggregated or pre-processed data needs to be sent to the cloud, significantly reducin

This is part of my Building Fluentic Style series, where I’m writing down the design decisions, tradeoffs, and small surprises from building Fluentic Style . The feeling I keep having is that styling in component frameworks often asks components to fit back into the old HTML + CSS model, instead of asking what CSS composition should look like when components are the main unit. That is not meant as a takedown of CSS. I like CSS. And the HTML + CSS model makes a lot of sense in its own world. In that model, you write HTML, give elements class names, and use selectors when a nested part needs styling. <div class= "card" > <h2 class= "card-title" > Revenue </h2> <p class= "card-body" > $42,300 </p> </div> .card { padding : 16px ; border-radius : 12px ; } .card-title { font-size : 18px ; font-weight : 700 ; } .card .card-body { color : #475569 ; } That model has problems. Global CSS can leak. Naming is hard. Specificity can become painful. Large stylesheets can become difficult to maintain. But the basic mental model is easy to understand: Give the part a name, then style that named part. Even when the ecosystem adds SCSS, BEM, naming conventions, CSS Modules, and other tools, a lot of the core idea stays familiar. There is markup. There are names. There are selectors. Styles reach elements through those names. That world feels coherent because HTML and CSS are built around that relationship. Then components change the shape of UI. Components Change The Unit In React and other component frameworks, we usually stop thinking of UI as one big HTML document. We think in components: < Card title = "Revenue" > $42,300 </ Card > That is a huge improvement. A component owns its internal markup. It receives props. It composes with children. It hides implementation details. It can be typed. It can be transformed by tooling. It can become part of a design system. But styling still has to answer a familiar question: How do I style the thing inside? In HTML + CSS, if I want to style

Ranking on Google is no longer the same thing as earning a click. Search engines increasingly answer questions directly through AI Overviews, featured snippets, People Also Ask boxes, local results, and other search features. In early 2026, a SparkToro study reported by Search Engine Land estimated that 68.01% of U.S. Google searches ended without a click during the first four months of the year. The comparison needs to be interpreted carefully because different studies use different data panels, but the direction is clear: a search impression does not automatically become a website visit. For small websites, this does not mean that SEO is dead. It means the goal is becoming broader. A useful page should be easy to discover, easy to understand, worthy of being cited, and valuable enough that a searcher wants to continue reading after seeing the short answer. SEO still matters in AI search Google's official guidance says that SEO remains relevant for generative search features because AI Overviews and AI Mode are grounded in Google's core Search ranking and quality systems. Google recommends the same fundamentals that have always helped users and crawlers: valuable original content, clear organization, crawlability, good page experience, and accurate technical implementation. This is important because there is no reliable shortcut called “GEO magic.” Google specifically says that site owners do not need special AI-only markup or an llms.txt file to appear in Google Search. The practical approach is still to build a website that people can use and trust. The question is therefore not only, “How do I rank for this keyword?” A better question is, “If an AI system or search feature reads my page, will it find a clear, specific, well-supported answer that represents my experience?” The four layers of visibility A small website can think about search visibility in four layers: Layer What it means Example signal Discovery Search engines can find and crawl the page Internal

WordPress is often treated as a traditional CMS, but its REST API makes it possible to use WordPress as the backend for applications, dashboards, mobile clients, automation systems, and external services. The difficult part isn't registering an endpoint. The difficult part is designing the endpoint so that authentication, authorization, validation, error handling, and data access are all handled correctly. A production API needs a contract. It needs to know: Who can access it What data they can access What input is accepted What output is returned What happens when something fails Here's a practical approach. Register a Custom Route A basic WordPress REST API route can be registered with register_rest_route() . add_action ( 'rest_api_init' , function () { register_rest_route ( 'myplugin/v1' , '/posts' , [ 'methods' => WP_REST_Server :: READABLE , 'callback' => 'myplugin_get_posts' , ]); }); This creates an endpoint similar to: /wp-json/myplugin/v1/posts The namespace matters. Using: myplugin/v1 gives the API a version boundary. If the response structure changes later, a new version can be introduced without immediately breaking existing clients. Don't Put Authorization Inside the Callback A common beginner implementation does everything inside the callback: function myplugin_get_posts () { if ( ! current_user_can ( 'manage_options' )) { return new WP_Error ( 'forbidden' , 'Access denied' , [ 'status' => 403 ] ); } // Query data... } This works, but WordPress provides a cleaner place for the permission decision. Use permission_callback . register_rest_route ( 'myplugin/v1' , '/posts' , [ 'methods' => WP_REST_Server :: READABLE , 'callback' => 'myplugin_get_posts' , 'permission_callback' => function () { return current_user_can ( 'manage_options' ); }, ]); Now the endpoint has a clearer separation: Request ↓ Permission check ↓ Callback ↓ Data That separation becomes increasingly valuable as an API grows. Authentication Is Not Authorization These concepts are easy to m

A reference guide compiled from deploying two Node.js/Docker apps to AWS EC2, covering the real issues hit and how they were fixed. 1. Getting Connected Q: How do I SSH into my EC2 instance? chmod 400 your-key.pem ssh -i your-key.pem ubuntu@YOUR_ELASTIC_IP Type yes when asked about the fingerprint the first time. Q: chmod 400 doesn't seem to work / I get "bad permissions" / "Permission denied (publickey)" This happens when your .pem key sits on a Windows drive mounted into WSL (e.g. /mnt/c/Users/you/Downloads ). NTFS doesn't honor Linux permission bits properly. Fix: copy the key into WSL's native filesystem first. mkdir -p ~/.ssh cp "/mnt/c/Users/you/Downloads/your-key.pem" ~/.ssh/your-key.pem chmod 400 ~/.ssh/your-key.pem ssh -i ~/.ssh/your-key.pem ubuntu@YOUR_ELASTIC_IP Q: My key filename has spaces in it — how do I reference it? Wrap it in quotes: ssh -i "Terminal Key Pair.pem" ubuntu@YOUR_ELASTIC_IP Q: How do I know which actual instance/IP I'm connected to? TOKEN = $( curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" ) curl -s -H "X-aws-ec2-metadata-token: $TOKEN " http://169.254.169.254/latest/meta-data/instance-id curl -s -H "X-aws-ec2-metadata-token: $TOKEN " http://169.254.169.254/latest/meta-data/public-ipv4 Compare this to what the AWS Console shows for your instance — it's easy to accidentally SSH into an old instance if an Elastic IP got reassigned. 2. Domain Name / HTTPS Without Buying a Domain Q: I don't want to buy a domain — can I still get real HTTPS? Yes — use sslip.io . Any hostname like YOUR_IP.sslip.io automatically resolves to that IP with zero signup. Let's Encrypt (via Certbot) will issue a real, trusted certificate for it just like a paid domain. Q: Why can't I just use the raw IP with HTTP? Clerk (auth) and Razorpay (payments) both require HTTPS with a real hostname in production/live mode. Plain http://ip will not work with either. Q: I later bought a real domain — how do I switch o

Hello everyone, I am new to coding just begun to learn the ins and outs of coding and what it can do. I am in the process of getting my Full Stack Developer certificates. I have always wanted to do something that has to do with computers because I needed something to pass the time when I hurt myself playing football. I am looking forward to chatting with all of you about the struggles you had and what you found that you liked within the development realm.

I remember having a Spirograph as a kid and being obsessed with it. Its geometric patterns are hypnotic and gorgeous. I also love generative music composition. So bringing those two things together in a browser tab, I'm hooked. Musical Spirograph is a relatively simple concept. A set of points dash around the screen according to […]

An RV repair business does not lose a service call because a visitor failed to read a clever headline. It loses the call when a person with a broken slide-out, roof leak, or electrical issue cannot answer four basic questions quickly: Do you handle this exact problem? Do you serve where I am? Are you available and credible? What do I do next? That sounds like marketing. It is mostly a systems-design problem. The implementation goal is not “make more city pages.” It is to make the business's real-world facts available, consistent, crawlable, and usable across the website, Google Business Profile, analytics, and the conversion flow. This post turns SEOG’s RV repair checklist into an implementation pattern a developer can apply to any local-service site. The model: one source of truth, many decision surfaces Local customers do not encounter a business in one place. They may see a Google result, a Maps profile, a service page, a review, or a call button before they ever submit a form. Treat the site as one consumer of a small, canonical business data model rather than a collection of independently written pages. business facts ─┬─> server-rendered service pages ├─> JSON-LD ├─> XML sitemap + canonical URLs ├─> GBP sync/review queue (with human approval) ├─> call/form events └─> audit and change history The important part is the left side. If a mobile RV technician's phone number, service coverage, repair categories, and hours live in five unrelated CMS fields, a mismatch is inevitable. Start with an explicit domain object. type BusinessLocation = { id : string ; legalName : string ; publicName : string ; phoneE164 : string ; website : string ; address ?: { streetAddress : string ; addressLocality : string ; addressRegion : string ; postalCode : string ; addressCountry : " US " ; }; geo ?: { latitude : number ; longitude : number }; serviceAreas : Array < { name : string ; state : string ; proof : string [] } > ; hours : Array < { dayOfWeek : string []; opens : string ; c

Cloudflare recently introduced Kitesurf, a lightweight browser built for automated workloads. Kitesurf runs browser components in isolated WebAssembly/Rust environments on Cloudflare Workers and supports the Chrome DevTools Protocol, allowing tools such as Playwright and Puppeteer to drive it with lower resource overhead than a full Chromium browser. By Renato Losio

I run a search engine that publishes in twelve languages from one static site on Cloudflare Pages. Last week I audited its machine-readable layer — the part crawlers and answer engines read rather than humans — and found four problems. None of them threw an error. None appeared in logs. Every page rendered perfectly. That is the whole point of this post: the multilingual layer fails in a register where nothing tells you. 1. The homepage was serving the wrong language to everyone abroad The site's primary market speaks Hebrew, so / is Hebrew and /en/ , /ar/ , /de/ and nine others sit alongside it. A middleware rule redirected visitors from one specific region to their language. Everyone else — including every English speaker on earth — landed on Hebrew. My first instinct was to fix it with a broader geo-redirect: detect English-speaking countries, send them to /en/ . This would have been a bad idea, and it is worth saying why. Googlebot crawls predominantly from US IPs. A geo-redirect on / that keys off country would take the crawler off the Hebrew homepage and onto the English one almost every time it visited. You do not want your primary-market homepage to become the page the crawler can never reach. The correct tool is hreflang , and it is what search engines built for exactly this. Checking the page, the tags were already there and already right: <link rel= "alternate" hreflang= "he" href= "https://example.com/" > <link rel= "alternate" hreflang= "en" href= "https://example.com/en/" > <link rel= "alternate" hreflang= "ar" href= "https://example.com/ar/" > <!-- …ten more… --> <link rel= "alternate" hreflang= "x-default" href= "https://example.com/en/" > Two things make this work, and both are easy to get wrong: The set must be reciprocal. Every page in the group lists every other page including itself . If /en/ does not point back at / , search engines are entitled to ignore the whole cluster. x-default is not "the default language" — it is the fallback for users

I spent a while building an icon editor that runs entirely in the browser (icons.jamuny.com, free, no account). Here is what cost me the most time. A presentation attribute loses to any author CSS rule I was scaling handle stroke widths by 1 / zoom and writing the result as an attribute. The value was never used. handle . setAttribute ( ' stroke-width ' , String ( 0.35 / zoom )); .handle { stroke-width: 0.35 } in the stylesheet outranks it, because a presentation attribute sits at the very bottom of the cascade. Measured in Chromium: an attribute of 0.05 computed as 0.35px . Every handle thickened on screen as you zoomed in, for months, with no error anywhere. The fix is a custom property, which is an ordinary declaration and wins where an attribute cannot: layer . style . setProperty ( ' --px ' , String ( 1 / zoom )); /* .handle { stroke-width: calc(0.35 * var(--px)) } */ Geometry attributes like r and width are unaffected. They have no CSS counterpart here, so nothing was ever overriding them. A focused SVG element gets a focus ring measured in user units My canvas is 24 units wide and about 620 pixels. Chrome drew its default focus ring at outline-width: 2.72727px in user units, which is about 24 screen pixels. A fat blue disc appeared around every point you clicked. It was reported to me four times, and four times I thinned something of my own that was not the cause. getComputedStyle ( document . activeElement ). outline That one line found it. My rule only covered :focus-visible , which is the keyboard case, and the keyboard case is the one where I draw a ring of my own. var() does work in a presentation attribute, and I wrote down that it doesn't I needed a segment colour that changes with the theme, so the value is oklch(var(--band-l) var(--band-c) 47) . I applied it through a style and put a comment beside it saying var() is not substituted in presentation attributes. It is. Both forms compute to the same colour, including on an element built detached and ap

Every open-source tool has the same brutal first 90 days: zero users, zero signal, no idea whether anything works. I have shipped several free CLI tools and browser tool sets. This is the exact funnel I use — no ads, no paid growth, no "build in public" theater. Just a repeating sequence of small, concrete actions. Step 1: Make the Tool Trivial to Try The first rule: npx must work. If a reader has to install, configure, and read a README before running the first command, the funnel is already broken. npx @wuchunjie/dotguard . That is the entire onboarding. Zero dependencies, no config, instant output. The first 10 seconds decide whether the reader comes back. Step 2: Publish One Article Per Angle Not one article. One per angle , spread over time: Tutorial — "Scan your .env files in 1 command" (the how) Comparison — "Why I stopped using X" (the why) Listicle — "5 tools for Y" (the discovery) Workflow — "My dev setup" (the context) Security/devops — "Your CI is missing this" (the fear) Each article targets a different search intent. A developer looking for "pre-commit secret scan" lands on article 4, not article 1. The funnel is wide because the angles are wide. Step 3: Cross-Link Everything Every article mentions every tool. The footer of a snippet article lists the scaffolder and the scanner. The GitHub repo links to the articles. The npm README links to the articles. The effect is compounding: a reader of article 3 meets four tools, not one. Your content becomes a network instead of a pile. Step 4: Make the GitHub Repo the Hub The repo README is the landing page that never goes stale: One-line description per tool Install/run commands (copy-paste ready) Links to every article A donation link, present but quiet GitHub is where developers actually trust. Stars and forks are the signal that converts "interesting article" into "let me try it". Step 5: Add the Quiet CTA One line at the end of every article: If this saved you time, a Ko-fi keeps the next tool coming. No

Introduction Git is a version control system that tracks changes in code. When writing code we need to save every significant change or feature that does a certain function as a commit that can be reverted to if we ever need that instance of the code. This helps programmers to traverse code since nothing is ever lost in the product life cycle of the project. It also helps in debugging since we have a copy of the previous working state. So how do we start out with git you ask. Install git Install git for your specific operating system. After installing git you will note that the file comes with git bash which is a command line terminal that is used to run commands or instruct the version control git. To ensure that git has been installed open git bash and run the command git --version which will return the version of git installed Download Visual Studio Code Install VS code a text editor for writing code. Create a github account GitHub is a cloud-based platform used by developers to store, track, and collaborate on software code. It operates as a hosting service for git, an open-source version control system that tracks changes made to files. Head over to github and create and account Creating a directory tracked by git On git bash run mkdir <filename> . This will create a folder ie the project that will contain your files of code. Enter the folder through cd <filename> and create a file README.md file which explains what this project does touch README.md . Run the command ls to list files in the directory Open the vs code from terminal by running code . and edit the README.md file. Now the file is ready to be tracked by git on github Staging, committing and pushing We now need to initialize the directory making sure that git is now tracking the file. Running the commands ls-la will confirm that git has been initialized in the repository. There are two ways of doing this either via the text editor VS code or the terminal . Let us go through both. 1. VS code Make sure

I built an OLX scraper for 24 countries — the boring version that actually ships OLX runs classifieds in about two dozen countries. Same brand, different domains, different anti-bot setups. Everyone scraping it does one country at a time. I got tired of forking. So I put 24 countries behind one input. country: "id" or country: "pl" or country: "br" — same schema out. It's live on Apify as primesieve/olx-global-scraper . One file. No browser. Here is the boring part that matters. What it does Input: { "country" : "id" , "keywords" : [ "iphone 13" ], "maxResults" : 50 , "maxPages" : 3 , "proxyConfiguration" : { "useApifyProxy" : true , "apifyProxyGroups" : [ "RESIDENTIAL" ] } } country — two-letter code ( id , pl , in , br , ua , pt , ro , bg , kz , uz , pk , za , ng , ke , eg , lb , ph , co , ar , pe , ec , gt , az , ma ). Default id . keywords — one or more search terms. Each runs sequentially. maxResults / maxPages — caps. Defaults 50 / 3, max 1000 / 30. proxyConfiguration — optional for Indonesia, required for the other 23. Output — same shape every country: { "listingId" : "123456789" , "title" : "iPhone 13 128GB mulus" , "price" : 6500000 , "priceText" : "Rp 6.500.000" , "currency" : "IDR" , "city" : "Jakarta Selatan" , "location" : "Tebet, Jakarta Selatan, DKI Jakarta" , "images" : [ "https://...jpg" ], "thumbnailUrl" : "https://...jpg" , "listingUrl" : "https://www.olx.co.id/item/123456789" , "country" : "id" } Title, price (numeric plus display text), currency, location, images, URL. No seller PII beyond what the listing page shows. No tricks. Try: https://apify.com/primesieve/olx-global-scraper The boring stack // no playwright, no puppeteer // apify + fetch + cheerio. That's it. The scraper is one file. Apify SDK for input, dataset, and pay-per-event. Native fetch for HTTP. cheerio for the HTML path. Undici ProxyAgent when a proxy is configured. Node 20, 512 MB, 600s timeout. I check the endpoint before I write the scraper. Indonesia answered with clean JSO

Most free chess game review gives you one game per day. Chess.com works that way, and so does almost every smaller site offering the feature. I assumed for a long time that this was just a paywall placed where it hurts. It is partly that. But there is a real cost sitting behind the cap, and once I worked out what the cost was, I built my own analysis site differently. The cost of one game review Reviewing a 40 move game means evaluating about 80 positions. Give the engine two seconds on each one and you have spent close to three minutes of CPU. None of it is cacheable, because your game is not anyone else's game. Run that on your own hardware and you pay for every minute. A thousand people reviewing one game a day is roughly 50 CPU hours daily, for a feature you are giving away. The quota is not greed. It is the number that stops the free tier from eating the company. Which raises a more interesting question than "how do I price this". What happens if you delete the cost instead of rationing it? Move the engine to the client Stockfish compiles to WebAssembly. Put it in a Web Worker and the visitor's own processor spends those three minutes. Your server ships static files and never sees a chess position. The whole free tier problem disappears, because there is no per-user cost left to control. Nothing to meter, so nothing to cap. Getting started is unremarkable: const engine = new Worker ( " stockfish.js " ); engine . postMessage ( " uci " ); engine . postMessage ( " isready " ); After that you speak UCI over postMessage . Set a position, ask the engine to think, and read results off the message stream: engine . postMessage ( `position fen ${ fen } ` ); engine . postMessage ( `go depth 15 movetime 2000` ); That is the pitch. Now the parts nobody mentions. The protocol is strings, and it is asynchronous UCI was designed for a pipe between two processes. You get that pipe, faithfully, with all of its ergonomics intact. The engine answers with lines like this: info dept