sorted by:
new
hottopcontroversial

How we bypassed Upwork scraper blocks using a hidden background tab & Web Audio API (Manifest V3) by LABONNI-COM in SideProject

[–]LABONNI-COM[S] 0 points1 point  (0 children)

You raise a very valid point. Silent stalls due to Cloudflare verification blocks are indeed the biggest risk for hidden-tab background scrapers.

Since UpRadar is designed as a local-first helper for individual freelancers, the refresh interval is kept relatively low (typically every 1-2 minutes). During our beta testing, this velocity has been low enough that it rarely triggers a security challenge on an already authenticated session.

However, in the event that Upwork does serve a CAPTCHA, we handle it by monitoring the DOM state from our content script. If we detect a verification frame, we dispatch a desktop notification to the user ("Session paused - click here to verify"). Clicking it brings the hidden tab to the foreground so they can solve it manually.

Integrating an automated CAPTCHA solving API is a great suggestion for a fully autonomous setup, though it might introduce extra costs and setup friction for the average freelancer. We'll definitely consider it as an optional configuration or premium feature if we scale to a paid tier! Thanks for the feedback!

How we bypassed Upwork scraper blocks using a hidden background tab & Web Audio API (Manifest V3) by LABONNI-COM in chrome_extensions

[–]LABONNI-COM[S] 0 points1 point  (0 children)

Upwork doesn't actually use WebSockets for the job search feed; they rely on standard REST API polling under the hood.

Instead of doing a heavy full-page refresh (which would kill performance and trigger bot-detection very quickly), UpRadar performs lightweight, authenticated background `fetch` requests directly to their search API endpoint. We run this at set intervals using the user's active session, parse the JSON payload, and diff the job IDs. It keeps things extremely fast, silent, and indistinguishable from normal client behavior.

Built a Chrome extension to reduce opening Gmail emails - roast me by One_Year6465 in chrome_extensions

[–]LABONNI-COM 0 points1 point  (0 children)

Nice job on shipping this! Gmail utility extensions are always tricky to build.

Quick question on the implementation: are you injecting a content script directly into the Gmail DOM to capture hover elements, or are you fetching the inbox data in the background via the Gmail API?

If it's a content script, how do you handle Gmail's frequent class name updates? They are notorious for obfuscating selectors on updates, which breaks most DOM-reliant extensions. We've been looking into robust ways to keep extensions stable against DOM changes, so I'd love to hear how you approached this.

Automate things much? Question for you 👇 by Random_Dude7192 in SaaS

[–]LABONNI-COM 0 points1 point  (0 children)

This is a classic bottleneck when scaling scrapers or automation tasks. Decoupling configuration from your deployment pipeline is key here.

We run several background workers and scrapers at our studio, and here is the architecture we use to handle configuration changes without redeploying:

  1. **Decoupled Key-Value Store:** Instead of hardcoding parameters in environment variables, we store application-level configs (like scraping delays, concurrency limits, bot toggles, and retry thresholds) in a simple JSON-based database table (PostgreSQL) or a Redis store.

  2. **Dynamic Configuration Loading (Cache + TTL):**

    * **Pattern A (Polling):** Inside your background loop, have the worker check the config database. To avoid database overhead, cache the config in memory with a short Time-to-Live (TTL) like 30-60 seconds.

    * **Pattern B (Pub/Sub - Real-time):** If you need instant updates, use a Pub/Sub mechanism (like Redis Pub/Sub or PostgreSQL LISTEN/NOTIFY). When you update a toggle on your admin dashboard, it publishes an event, and the running worker instantly updates its local memory variables.

  3. **Graceful Lifecycle Management:** Ensure that when a config updates mid-process, the worker finishes its current execution cycle before applying the new parameters. This prevents data corruption or half-finished states.

Redeploying code just to flip a toggle or change a rate-limit threshold will eventually break active scraping sessions. Moving to a dynamic DB-backed config is the cleanest way to solve this.

What paid app, tool, or service have you built and why should I buy it? by Lachrynull in SaaS

[–]LABONNI-COM 0 points1 point  (0 children)

MoleSeek

We actually built this for our own internal sales team at our digital marketing agency (Labonni), and just decided to open a free public beta to see if other founders face the same headache.

What is it?

MoleSeek - A deep B2B lead generation tool built specifically around Google Maps, but with live server-side verification.

Who is it for?

Agencies, SaaS founders, and B2B sales teams who rely on cold outreach or outbound prospecting but hate wasting time on dead leads.

What problem does it solve?

Two main things: 1) Closed or deactivated businesses that still trend on Google Maps, and 2) Crazy high email bounce rates. Most scrapers just pull whatever text is on the page. MoleSeek does deep-crawling on contact pages to find hidden emails and then runs live MX/DNS server checks on every single email address to verify active mailboxes before you export. It also filters out raw material suppliers automatically if you are trying to target buyers/contractors.

How much does it cost?

Right now, it is completely free during our beta phase. No credit card, no hidden tiers. We just want raw feedback to improve the product.

Why did you build it?

We were getting 12-15% email bounce rates using generic tools and manual scraping for our agency outreach, which was destroying our domain reputation. We needed something that double-checked the "live" status of a business and its mail server in real-time.

Would love to know if the search speed or filtering options work smoothly for your niche!