Proposal: YAZA Ecosystem Module Roadmap

Status: Draft proposal — module catalog and dependency direction for review
Purpose: Plan a coherent collection of first-party packages for backend, web, mobile, data, maps, realtime, and deployment

1. Goal

YAZA should grow as one connected development ecosystem: language, compiler, CLI, runtime, standard library, official packages, project templates, editor support, and deployment adapters. This proposal gives those future packages a map, clarifies which layer owns each responsibility, and defines the technical foundation they depend on.

The benefit should be less duplicated glue: a model can be validated once and reused in a database, API, browser UI, mobile screen, event stream, and map layer. Shared diagnostics, project manifests, security limits, and build commands should make common tasks more consistent. Native code generation, selective module linking, streaming, typed boundaries, and workload-specific renderers are performance goals; the ecosystem must measure them before making superiority claims.

“First-party” means YAZA owns and reviews the source code and release process. It does not mean every dataset, device API, standard, or cloud host belongs to YAZA. Interoperability adapters and narrow OS bindings remain necessary. Under the previously accepted Option A for data/media, production parser, codec, and analytics implementations should be written and maintained in YAZA; standards and independent tools can serve as test oracles, not linked runtime implementations.

2. Package layers

Names are placeholders until package naming and versioning are standardized. The module lists are candidate scope, not claims that every package exists.

3. Integration architecture

3.1 A small stable core

The compiler and runtime should expose a small set of stable foundations: typed errors, Option/Result, bytes/text, numeric types, collections, memory ownership, streams, clock/deadline, cancellation, and capability checks. Higher packages should not each invent a separate error envelope, allocator, HTTP client, configuration format, or test convention.

3.2 Explicit dependency graph

Use a one-way dependency flow:

language core and runtime
  ├── format, data, database, geo, async primitives
  ├── HTTP and platform adapters
  └── APIs, Pulse, Atlas, and YAZA UI
        └── web/mobile applications and deployment targets

Lower layers must not import application frameworks. UI may consume typed API/Pulse/Atlas data, while those packages cannot depend on UI. Cloudflare or Android support must be a target adapter, not hidden conditional behavior in every library. The compiler should link only imported modules and show why a package enters the final artifact.

3.3 Shared contracts

Where useful and safe, packages should share compiler-checked shapes for API requests/responses, PostgreSQL rows, Pulse events, UI form state, map features, and analytics records. Code generation must preserve nullability, numeric bounds, version, source location, and license/attribution metadata. Runtime conversion at untrusted boundaries still validates values; compile-time types do not make network or file data trustworthy.

3.4 Package and supply-chain rules

The package system should provide immutable versioned releases, a lockfile with content hashes, reproducible resolution, provenance/SBOM, vulnerability notices, and explicit capabilities. First-party packages use the same release gates as the compiler. An application grants network, filesystem, location, camera, or process access explicitly. A package cannot expand its capabilities silently through a transitive dependency.

The registry should distinguish std (bundled/compiler-versioned), yaza.* (official packages), and community namespaces. Package discovery must state supported YAZA versions, targets, API stability, data/codec profiles, licensing, and verification status. Offline builds should work from the lockfile and local cache.

4. Product modules and the advantage of one ecosystem

• Backend and PostgreSQL: generated layered APIs, native runtime, typed models, and the pure-YAZA driver should share checked contracts and request limits.
• Web and YAZA UI: templates should use the first-party UI by default, with server/client contracts generated from the same source and semantic HTML on the web.
• Mobile: the same application/domain types should target Android first and iOS next, while UI, location, camera, notifications, storage, and lifecycle use explicit native adapters.
• Data and analytics: CSV, spreadsheet, PDF, image, audio, video, and statistics APIs should stream bounded data and pass typed results to APIs, dashboards, mobile screens, or Atlas.
• Maps: Atlas should share geometry/feature values with API services, UI components, mobile location, and Pulse updates. Datasets and license obligations remain explicit.
• Realtime and jobs: Pulse should carry the same versioned event types from APIs to browser/mobile clients and from services to durable consumers, without pretending that transient sessions are a durable queue.
• Cloud and edge: build targets should package only modules permitted by their host and expose unavailable capabilities at compile time or startup rather than failing unpredictably in production.
• Tooling: one CLI and LSP should surface the same project graph, source locations, tests, schemas, security limits, and deployment profile.

The expected payoff is fewer handwritten adapters, more consistent safety limits, smaller artifacts through selective linking, and simpler onboarding. These are product hypotheses. Each one needs representative application studies and benchmarks for build time, time-to-first-request/frame, tail latency, memory, binary/bundle size, energy use, and maintenance effort.

5. Delivery order

1. Stabilize the language foundation: errors, ownership/memory, modules, package manifest/lock, diagnostics, and target capability model.
2. Finish dependable runtime services: async socket I/O, structured cancellation, PostgreSQL protocol, HTTP client/server, crypto boundaries, and explicit filesystem capabilities.
3. Deliver small, testable data profiles: CSV, PDF, statistics primitives, then XML/archive/spreadsheet and media formats under the existing data/media proposal.
4. Mature API/database/project tooling: migrations, schema snapshots, layers/interfaces, typed request validation, tests, OpenAPI/Postman, and production diagnostics.
5. Deliver YAZA UI web primitives and accessibility before promising native UI; maintain its separate accepted proposal as the UI specification.
6. Implement Pulse in two independently useful profiles: local durable single-node event log first, then groups/replay/retention, followed by realtime transport adapters and later replication.
7. Build Atlas from geospatial correctness and bounded data parsing up through 2D rendering, tile services, mobile, search, routing, and 3D; each level has separate evidence gates.
8. Add Android, iOS, WASI, Cloudflare, Linux, and Windows targets according to their RFC-specific compiler and host adapter gates.
9. Grow official/community packages only after package signing/provenance, policy, support, and deprecation processes work.

This sequence is a dependency order, not a release-date promise. The implementation status matrix remains authoritative for what currently runs.

6. Readiness standards

An official package should not be labeled ready merely because a template compiles. It needs:

• A documented normative API and explicit supported feature/profile matrix.
• Examples compiled as documentation tests and starter projects built in CI.
• Positive, negative, malformed, boundary, and resource exhaustion tests.
• Fuzzing and sanitizers for parsers and native boundaries, with minimized regressions.
• Cross-platform build/test evidence for each claimed target; target-specific capabilities called out explicitly.
• A repeatable benchmark plan and public results before comparative speed or efficiency claims.
• Security review, package/license metadata, SBOM/provenance, migration/deprecation policy, and a clear support owner.
• Feature flags or module boundaries that keep unrelated runtime code and privileges out of the application.

7. Status and related proposals

This is an ecosystem catalog and integration proposal; it does not accept every listed module or claim implementation. Current decisions and implementation evidence are tracked separately:

• Data, media, analytics, and web modules
• YAZA UI design system
• YAZA Pulse realtime and event streaming
• YAZA Atlas maps engine
• RFCs and accepted language/runtime decisions
• Code-backed runtime capability matrix

← Kembali ke semua dokumentasiVersi dan status rilis →