How BAS Is Built: Modules, Blocks, Functions — and Browser vs HTTP-Client

Most people learn Browser Automation Studio by dragging blocks until something works. That gets you a first bot, but it caps how good you get. The faster path is to hold two mental models in your head: how BAS is structured internally, and the two completely different ways it can talk to a website. Get those right and the rest is detail.

The four layers of a BAS project

BAS isn’t a flat pile of blocks. It has a hierarchy, and each level exists to keep the one below it manageable.

1. Modules. The highest level. A module is a reusable package of functionality — built-in ones ship with BAS, and the community publishes many more. Captcha solving, parsing helpers, integrations: instead of rebuilding them, you import a module and call into it. Think of modules as the libraries of the BAS world.

2. Action blocks. The atoms. Each block is a single step: go to URL, click element, type text, extract value, if/else, loop. This is the layer you see most — your project is, at the bottom, a sequence of these. Everything else exists to organise them.

3. Functions. The glue between atoms and architecture. A function groups a set of blocks into a named, reusable unit that takes parameters and returns a result — log in, parse one product, rotate proxy. Write the logic once, call it from twenty places. Functions are where a pile of blocks becomes an actual program.

4. Auto-scenarios. The shortcut. Instead of placing blocks by hand, you turn on recording and just use the page — click, type, navigate — and BAS writes the corresponding blocks for you. It’s the fastest way to draft a flow; you then clean it up, parameterise it and wrap the good parts in functions.

The progression is the whole skill: record a rough scenario, break it into action blocks, lift the repeatable parts into functions, and reach for modules so you don’t reinvent solved problems.

Two ways BAS talks to a website

Here’s the distinction that quietly decides whether your project scales: BAS has two different ways of interacting with sites, and they are not interchangeable.

1. Web browser. BAS opens the URL in a real Chromium browser — the page loads and renders exactly like it does in the browser on your PC. JavaScript runs, dynamic content appears, the visual layout is built. The bot sees what a human sees.

2. HTTP-client. BAS sends requests straight to the web server without opening the page in a browser and without rendering any visuals. It receives the raw server response — HTML, JSON, whatever comes back — and nothing more. No rendering engine, no page paint.

Same goal of “get data from a site,” two completely different machines doing it.

When to use which

The deciding factor is resources, and therefore scale.

Loading a page in a browser is expensive: rendering consumes RAM and CPU. In practice that means a single machine won’t run much more than 100–200 browser threads before it chokes. That’s fine for many jobs — but it’s a hard ceiling.

If you need to work in 1000 threads or more, the browser is the wrong tool. HTTP-client is optimised for exactly that load and runs completely without a browser, so the same hardware handles an order of magnitude more concurrency.

So the rule of thumb:

• Use the browser when the data only exists after JavaScript runs, when there’s a login or anti-bot flow that checks for a real browser, or when you must interact with visual elements (clicks, forms, fingerprints). Correctness over raw speed.
• Use HTTP-client when the data is already in the raw response or you’re hitting an API directly, and you need volume. It’s lighter, faster and scales to thousands of threads — but it sees no rendered page, so anything that depends on JavaScript is invisible to it.

In real projects you often mix them: log in and grab a token with the browser (because that step needs a real one), then fan out across thousands of HTTP-client threads to do the heavy fetching. Browser for the parts that require a browser; HTTP-client for everything that doesn’t.

The takeaway

The structure tells you how to build: scenarios into blocks, blocks into functions, functions resting on modules. The interaction types tell you what to build it on: a browser when you need eyes on the page, an HTTP-client when you need scale. Most beginners struggle because they reach for a browser for everything and then wonder why 50 threads melt their VPS. Pick the right interaction mode first, organise cleanly second, and BAS stops fighting you.