Weave Code
Core Laravel Package
apiato/core
APIato Core is the foundational package for APIato, an API-first Laravel framework built on the Porto architecture. It provides modular containers, authentication, authorization, routing, shared utilities, and code generation tools for scalable, maintainable backend applications.
Apiato Core Package
Frequently asked questions about Core
- What is apiato/core and how does it relate to Laravel?
- apiato/core is the architectural kernel of Apiato, a Laravel-based framework for API-first applications. It supplies Ports and Containers modules, Actions, Tasks, repositories, request validation, response transformers, generators, helpers, and testing utilities. It is not a general-purpose Laravel utility; it is designed around Apiato conventions and the broader Apiato ecosystem.
- How do I install apiato/core with Composer?
- Installation is typically done with Composer, but practical adoption usually means starting from the Apiato skeleton rather than adding only apiato/core to an existing Laravel app. The package likely registers service providers, configuration, base classes, middleware, and exception handling that assume Apiato conventions. Pin the version explicitly and run a compatibility spike against your target Laravel and PHP versions before committing.
- Which Laravel and PHP versions does apiato/core support?
- The supplied context does not specify exact Laravel and PHP version constraints, so you must inspect the package composer.json and the Apiato starter requirements. Validate those constraints against your application and transitive dependencies in a separate branch or spike. Lock compatible versions and add CI checks before production adoption.
- Can I use apiato/core without the full Apiato starter kit?
- Technically it may be possible to install the package independently, but apiato/core is a kernel that expects Apiato conventions, base classes, service providers, and application structure. Using it without the starter is likely to require substantial integration work and may fight the framework's assumptions. Treat full Apiato adoption or a bounded-container pilot as the safer path.
- What are Ports and Containers in Apiato?
- Ports and Containers is Apiato's HMVC-style modular architecture for keeping large codebases organized into self-contained components. A container typically groups related routes, controllers, actions, tasks, repositories, transformers, and configuration. This supports reusable domain modules and clearer ownership boundaries, but it also means adopting Apiato's directory and convention model.
- What is the difference between Actions and Tasks in apiato/core?
- Actions represent focused business use cases, often orchestrating a request-level operation, while Tasks are smaller reusable units of work called by actions or other components. Both keep controllers thin and move business logic into testable classes. The exact boundaries are a design convention, so document your team's rules for when logic belongs in an Action versus a Task.
- How does the repository and criteria pattern work with Eloquent?
- apiato/core provides repositories and criteria over Eloquent so query logic can be encapsulated and reused instead of scattered across controllers. Criteria typically express reusable query constraints, while repositories provide a consistent data-access interface for actions and tasks. Eloquent remains the underlying ORM; the pattern adds structure rather than replacing Laravel's database layer.
- Is apiato/core suitable for an existing Laravel monolith?
- It is generally a poor fit for retrofitting an entire existing Laravel monolith because it brings opinionated modular conventions, base classes, and request/response pipeline assumptions. A safer approach is a strangler pattern: introduce Apiato in a new bounded context or container, route selected endpoints through it, and adapt existing domain services behind interfaces. Do not rewrite the whole application solely to adopt the core package.
- What are the main production risks of adopting apiato/core?
- The main risks are framework lock-in, upgrade coupling across the Apiato ecosystem, uncertain release and backward-compatibility cadence, and sparse public support visibility. The supplied assessment also notes unknown canonical repository metadata and low visible adoption for a core kernel. MIT licensing helps, but maintaining an internal fork adds ownership cost; pin versions, run contract tests, and define an escalation path.
- How should I test and maintain an application built with apiato/core?
- Treat apiato/core as a platform dependency: pin explicit versions, run contract and integration tests in CI, and maintain performance and security baselines. Track Laravel upgrades, CVEs, dependency conflicts, and upstream activity through an internal platform owner. Document Apiato conventions and golden paths, and budget for internal patches or a maintained fork if upstream support is insufficient.
Weaver
How can I help you explore Laravel packages today?