Citygov Bundle Laravel Package

Technical Evaluation

What this package actually is. atoolo/citygov-bundle is a Symfony bundle, not a Laravel package. It is a vendor-owned, domain-specific module from Sitepark's Atoolo/CityGov product line that enriches CityGov content objects into Solr index documents and exposes them through GraphQL (online services, teaser features, person search/suggest). Treat the "Laravel/PHP" framing as inaccurate at the framework level: the PHP is compatible (8.1–8.4), the packaging is not.

Architecture fit. The bundle assumes a fairly deep Atoolo/Symfony substrate: atoolo/search-bundle (pinned ^1.14.0 at v1.5.0), a SiteKit schema namespace (SiteKitSchema2x), resource/link-factory abstractions, document-enriching pipelines, and Solr field conventions (sp_meta_string_leikanumber, startletter, etc.). It is an enrichment/integration layer, not a standalone capability. Value only materializes if you already run CityGov content and Atoolo search.

Integration feasibility under Laravel. Low for direct install. Symfony bundles register via Kernel::registerBundles(), DI compiler passes, service tags, and bundle-level config trees — none of which Laravel's container or package discovery understands. You could theoretically consume individual classes via Composer (MIT license permits it), but the practical surface is entangled with Symfony contracts (EventDispatcher, Config, DependencyInjection) and Atoolo interfaces. The realistic options are:

1. Symfony sidecar — run CityGov/Atoolo as a separate Symfony service and consume it from Laravel over GraphQL/HTTP. Highest fidelity, lowest risk.
2. Reference implementation — mine the Solr field mapping and GraphQL schema design, reimplement natively in Laravel. Highest effort, no vendor coupling.
3. Direct port — attempt to shim the bundle into Laravel. Not recommended; you inherit every upstream coupling without the upstream bootstrapping.

Technical risk.

• Single-vendor, low-adoption signal. Zero stars, zero dependents. This is effectively a private-internal bundle published for the vendor's own customer base, not a community asset. Bus factor is effectively one organization.
• Release date anomaly. "Last release 2026-06-03" is a future date relative to any normal evaluation window — flag as a data-integrity issue in the package metadata before relying on release cadence.
• Version cadence is fast and coupled. Six minor releases (1.0→1.6) with breaking-adjacent dependency bumps (search-bundle ^1.14.0) and field-level changes (phone number field change in 1.5.0). Expect to track upstream closely.
• Positive signals: MIT license, PHPStan level 9, Codecov coverage, PHP 8.1–8.4 matrix, external E2E suite (atoolo-e2e-test), conventional-commit changelogs. Engineering hygiene is better than typical for a 0-star repo.

Key questions for the vendor/team.

1. What is the supported CityGov/SiteKit schema version range, and how are schema breaks communicated?
2. Is the bundle usable without the Atoolo search-bundle and Solr, or is that a hard runtime dependency?
3. What is the support contract — is this bundle covered by a CityGov subscription, or is it best-effort OSS?
4. Which releases are LTS/security-supported, and what is the deprecation policy?
5. Does the GraphQL surface have a published schema contract (SDL/Supergraph) stable enough for a Laravel BFF to codegen against?
6. Is there a reference deployment (docker-compose) we can validate before committing?

Integration Approach

Stack fit. Assume a Laravel-first engineering org. The clean architecture is: Laravel remains the product surface (auth, UX, citizen workflows, admin), and CityGov/Atoolo runs as a Symfony-backed content/search service behind a GraphQL boundary. The bundle lives entirely on the Symfony side. Laravel talks to it via HTTP/GraphQL only — no PHP-level coupling, no shared container, no Composer cross-contamination.

Migration path.

1. Discovery (2–3 weeks): stand up the vendor's Symfony deployment with sample CityGov content; validate Solr indexing, person search/suggest, and online-service GraphQL responses. This answers the "can we run it at all" question before any Laravel work.
2. Contract freeze: extract the GraphQL schema as SDL; define it as an internal API contract with versioning, owned by the TPM, not the vendor.
3. BFF layer in Laravel: build a thin GraphQL client / repository layer in Laravel (Lighthouse or plain HTTP client) that maps CityGov types to Laravel domain models. Insulate the rest of the app from schema drift here — one adapter, one place to fix.
4. Content pipeline: decide who owns Solr — vendor-managed or platform-managed. If platform-managed, own the index schema and treat the bundle as a document producer, validating field maps (leikanumber, startletter, umlaut normalization) as explicit contract tests.
5. Strangler cutover: route municipal content and person directories first (lowest risk, read-only), then online services (write-adjacent, higher risk), then intranet/employee features last.

Compatibility.

• PHP 8.1 is flagged "no longer checked automatically" — plan on 8.2–8.4 for the Symfony side.
• Pin atoolo/search-bundle explicitly and gate upgrades behind a contract test suite; the 1.5.0 dependency bump is exactly the kind of change that breaks silently.
• Laravel side has no version constraint from this package — good. Keep it that way.

Sequencing recommendation. Do not open the Laravel workstream until step 1 succeeds. This bundle's entire value is contingent on the surrounding Atoolo substrate; a failed discovery phase should kill the initiative cheaply rather than after a half-built adapter.

Operational Impact

Maintenance. Two runtimes to own (Laravel + Symfony/Atoolo), two dependency graphs, two upgrade cadences. The bundle will pull you along its release train — six minor releases in its short life, with dependency and field changes in each. Budget explicit capacity: roughly 10–15% of one backend engineer for keeping the Symfony side current and contract tests green, plus vendor-relationship time for a TPM.

Support. This is the crux. Zero stars and zero dependents means no community safety net. Support is whatever Sitepark's commercial relationship provides. Before adoption, establish in writing: response SLAs, security-patch turnaround, notification of schema/field changes, and an exit clause — the ability to export content and search documents in a portable format. MIT licensing means you can fork; it does not mean you should be able to operate a fork.

Scaling. Two independent scaling profiles. Laravel scales conventionally. The Symfony/Atoolo side is bound by Solr index size and query load — person search/suggest and faceted municipal-content search are the hot paths. Plan for: index rebuild windows, a staging Solr with representative content volume, and query latency budgets agreed with the vendor. The GraphQL layer between them adds a hop; keep the BFF cache-aware (per-request deduplication, short-TTL caching for directory/search results) so Laravel does not amplify load onto Solr.

Failure modes.

• Silent index drift — schema field renames upstream (as in 1.5.0's phone-number change) cause missing/empty search results without errors. Mitigate with contract tests asserting required fields on a sample document set.
• GraphQL schema drift — breaking changes break the Laravel BFF at runtime. Mitigate with schema snapshot tests and a pinned schema version.
• Vendor abandonment — the package stops receiving releases. Mitigate with the portability/exit clause above and a documented fork-and-own playbook.
• Solr unavailability — degrades search, person directory, and service listings simultaneously. Design Laravel UX to degrade gracefully (cached directory snapshots, clear fallbacks) rather than 500.
• Dual-runtime config drift — environment, secrets, and locale handling diverging between the two apps. Keep config parity in one place and test it.

Ramp-up. Assume 4–6 weeks before a Laravel engineer is productive against this stack: Symfony bundle conventions, Atoolo/SiteKit schema, Solr document modeling, and GraphQL contract discipline. The vendor's docs (sitepark.github.io/atoolo-docs) plus the E2E suite are the primary onboarding assets — assign one engineer as the named owner and require them to run the E2E suite locally in week one. TPM should also budget 1–2 weeks for the discovery spike to produce a go/no-go memo, because the honest expected outcome given zero adoption and single-vendor control is a conditional go — contingent on a support contract and a proven reference deployment.