Dynamic and Hybrid Libraries, Remote Libraries, and Extension Architecture: Configuration, Design Patterns, and Trade-Offs

1. Start from the least powerful architecture that meets the requirement

Every extension style can produce a keyword named Normalize Token, but they do not have the same operational cost. The static API delegates discovery to Python reflection. Hybrid adds runtime name discovery. Dynamic replaces reflection with explicit metadata plus dispatch. Remote then adds serialization, network failure, server lifecycle, and a trust boundary.

The design question is therefore not “Which API can do this?” but “Which API adds the fewest new failure modes while satisfying a real requirement?”

2. Static vs hybrid vs dynamic vs Remote

3. Metadata completeness versus implementation freedom

A dynamic library can technically expose only get_keyword_names and run_keyword. Robot will then treat keywords as broadly accepting arguments. That maximizes implementation freedom but weakens early validation, named-argument ergonomics, type conversion, Libdoc, editor assistance, and incident diagnosis.

When a proxy already knows the target signature, publish it. Metadata should be generated from the authoritative source when possible rather than copied by hand into a second registry that can drift.

4. Remote portability buys isolation at a measurable cost

Remote can isolate language/runtime dependencies and decouple deployments, but each keyword call becomes an RPC. That adds connection setup/reuse behavior, XML encoding/decoding, network scheduling, process availability, and server logging. Fine-grained chatty keyword APIs amplify this overhead.

If Remote is justified, expose cohesive domain operations rather than wrapping every low-level method as a remote keyword. Measure end-to-end latency before optimizing Robot itself; the dominant cost may be the external implementation or network hop.

5. Long-lived server versus per-run server

Do not let Robot suite teardown become the only lifecycle manager for a shared remote service. A long-lived server needs normal service ownership: deployment, health checks, patching, access control, audit logs, and rollback.

6. Treat serialization as an API schema

Remote conversion rules deliberately reduce Python-specific values to XML-RPC-compatible representations. That is a feature for language interoperability and a source of ambiguity if it is ignored. Define DTO-like values using strings, numbers, booleans, lists, and mappings with string keys. Document when absence is represented by an empty string instead of Python None.

Never depend on object identity, open file handles, database cursors, browser objects, sockets, generators, or library instances crossing the Remote boundary.

7. Security architecture is external to Robot keyword syntax

Core Robot configuration can specify a Remote URI and timeout. It does not configure your firewall, reverse proxy, mTLS, identity provider, authorization policy, network namespace, service account, or secret store. Those are separate external-system concerns.

• Loopback lab: 127.0.0.1, synthetic data, no credentials.
• Private deployment: explicit allowlist, authenticated/authorized gateway, transport protection, least-privileged server identity, monitored lifecycle.
• Internet exposure: do not rely on XML-RPC method names as a security boundary.

8. Keep configuration layers separate

9. Worked architecture decisions

10. Parallelism multiplies boundary assumptions

Chapter 24 will teach Pabot directly. For now, remember that multiple Robot workers can independently import a dynamic or Remote library. If they share one server, the server must define concurrency, request isolation, mutable state, and correlation IDs. If each worker starts its own server, ports and workspaces must be unique.

Do not use a single mutable GLOBAL Python object or one fixed loopback port as accidental cross-worker coordination.

11. Version compatibility contract

Pin and record the Robot client version, server implementation version, protocol capabilities, and keyword API version. The Remote protocol is designed for interoperability, but a server that omits newer metadata can still produce weaker tooling or type behavior. A version handshake can be exposed as a harmless metadata keyword if your service needs explicit compatibility checks.

The optional robotremoteserver reference implementation is useful for understanding the protocol, but its published 1.1.1 documentation only explicitly claims Python support through 3.11. The course fixture uses Python's standard library instead so the mandatory lab does not inherit that package's runtime ceiling.

12. Architecture decision record template

Decision: <static | hybrid | dynamic | Remote>
Requirement forcing escalation:
Authoritative keyword metadata source:
Process/language boundary:
Serialization contract:
Network exposure and authentication boundary:
Timeout / health-check contract:
Server lifecycle owner:
Parallel-worker isolation:
Evidence retained on failure:
Rollback / simpler alternative:
Version pins and compatibility test:

If “requirement forcing escalation” is blank, the static design should remain the default.

Knowledge check

References and version anchors

• Robot Framework 7.4.2 — Dynamic library API — metadata/dispatch behavior
• Robot Framework 7.4.2 — Hybrid library API — reflection and recommendation
• Robot Framework 7.4.2 — Remote library interface — transport and supported types
• Python Remote Server README — optional server implementation/version notes