BAS Modules Explained: The LEGO Model of Browser Automation Studio

If the structure of BAS ever felt abstract, modules are where it gets concrete. A module is the box that physically holds the things BAS can do — and once you see the analogy behind it, the whole modular design stops being intimidating.

The LEGO model

Picture walking into a shop with a basket. You spot a nice boxed LEGO set and drop it in. The box isn’t empty — it’s full of small LEGO pieces.

That maps cleanly onto BAS:

• The basket is the module — the container you carry.
• Each LEGO set inside it is a function — a self-contained kit for one job.
• The individual LEGO pieces are the action blocks — the smallest parts you actually snap together.

Every module is unique and ships with exactly the components — the action blocks — you’ll use when building functions and automation scenarios. The module isn’t the work; it’s the box that makes the right pieces available.

The modular-structure concept

BAS is built on three levels, each assembled from the one below it:

1. Action set — a developer combines a set of actions to solve a particular task.
2. Function — those actions get placed into special containers so they can be called many times, with parameters.
3. Module — functions are packaged into special blocks called modules, which you then connect to your projects.

Read it bottom-up and it’s the whole craft in one line: snap blocks into functions, bundle functions into a module, plug the module into any project that needs it. This is why BAS scales — you stop rebuilding the same logic and start importing it.

Two kinds of modules

Modules in BAS fall into two groups: core and additional.

Core modules

The set of action blocks you’ll reach for most often — the backbone of nearly every project. They cover:

Browser, script logic, tools, network, wait, HTTP-client, date and time, file system, browser-fingerprint switching, list, path, profile management, resources, string, XPath, JSON, script statistics, regular expressions.

Each one solves a concrete job. The browser module, for example, exposes the Load action that opens a site by URL; the JSON module parses and builds JSON; wait handles timing; fingerprint switching rotates the browser identity. If you build bots, you’ll touch most of these in your first week.

Additional modules

These are action blocks you bring in as needed. If a project doesn’t call for them, you can happily do without. They include:

Open/close browser, clipboard, idle emulation, asynchronous function calls, image processing, mail, phone confirmation, process management, send email, Telegram, timezone, user interaction, built-in languages, Excel, database, URL, checksum, archiving, FTP, SQL.

The point of additional modules is reach: a task occasionally needs something specific, and there’s already a box for it. The image processing module edits downloaded photos and overlays text on them. The Telegram module sends notifications straight to a messenger — perfect for “ping me when the bot finishes or breaks.” You don’t load them by default; you pull the right one when the job demands it.

Why this matters in practice

The modular model is what keeps a growing BAS project from collapsing into chaos. Instead of one giant flat script, you get boxes of capability you can reason about separately, reuse across projects and hand to someone else. Learn the core modules deeply — they’re 90% of daily work — and treat the additional ones as a catalogue you consult when a task asks for something special. That’s the difference between fighting BAS and building with it.