docs(apify-actor-development): add library choice tree — don't reach for Crawlee when you don't need to crawl

[DaveHanns]

Rationale

The current best practices guidance covers Crawlee-internal choices well (CheerioCrawler vs PlaywrightCrawler, when to avoid browser crawlers), but doesn't address the more common miscalibration among Actor authors: reaching for a Crawlee crawler with a single startUrl when the Actor is really a one-shot HTTP call, a webhook receiver, an orchestrator, or an LLM wrapper.

This adds a concise decision table under ## Best practices that maps common Actor shapes to the right library — fetch()/requests + Apify SDK, Crawlee, Standby, Actor.call(), or the model vendor's SDK — so agents and humans stop wrapping non-crawl work in a crawler abstraction.

Added content preview

Choosing the right library for your Actor

Crawlee is designed for crawls — traversing many pages with routing, deduplication, session handling, and concurrency management. For any of the following, do not wrap your code in a Crawlee crawler with a single startUrl, and do not pull Crawlee in at all:

Task	Use
Crawl a website across many pages	Crawlee: CheerioCrawler for HTML, PlaywrightCrawler for JS-rendered
Call one HTTP API, transform, write to dataset	Native fetch() (Node 18+) or requests (Python) + Apify SDK for I/O
Receive webhooks or run a long-lived HTTP server	Standby Actor with an HTTP server (express, Node http, etc.) bound to the platform port
Orchestrate other Actors	Actor.call() / Actor.start() (JS/TS) or Actor.call() / Actor.start() (Python)
AI / LLM work	The model vendor's SDK (e.g. @anthropic-ai/sdk, openai, anthropic) + Apify SDK for I/O

Crawlee for a one-shot fetch adds startup cost, a request queue, a session pool, and a routing layer you don't need — and obscures the actual work behind a crawler abstraction.

Surfaced during an evaluation of Apify surfaces for agent-driven Actor development.