Cnet Connector Laravel Package

Technical Evaluation

Architecture Fit

• Legacy Dependency: The package is designed for Akeneo PIM v1.6–v2.x (Community Edition), which is outdated (last release: 2018). Modern Akeneo PIM (v6+) uses Symfony 5/6+ and a microservices-first architecture, making this connector highly incompatible without significant refactoring.
• Monolithic Integration: The connector relies on Akeneo’s legacy bundle system (AppKernel.php), which is deprecated in favor of Symfony Flex autoloading and modern dependency injection.
• Data Model Assumptions: Assumes CSV-based imports for CNET data, which may not align with modern PIM APIs (GraphQL, REST, or event-driven architectures).
• Custom Entities & Attributes: Requires CustomEntityBundle and ExtendedAttributeTypeBundle, both of which are not part of core Akeneo and may introduce schema rigidity or migration complexity.

Integration Feasibility

• Akeneo PIM Version Gap: The package targets Akeneo PIM v1.x/v2.x, while modern deployments use v5/v6. Backporting would require:
  • Rewriting bundle registration for Symfony 5/6.
  • Adapting to Akeneo’s new API layer (GraphQL, REST).
  • Replacing doctrine:schema:update with Akeneo’s migration system (e.g., pim:installer:migration).
• CNET API Changes: CNET’s data structure may have evolved since 2018, requiring API reverse-engineering or custom mapping logic.
• Dependency Conflicts:
  • akeneo-labs/custom-entity-bundle is abandoned (last commit: 2019).
  • extended-attribute-type is deprecated in favor of Akeneo’s native attribute system.

Technical Risk

Key Questions

1. Is CNET’s data still critical? If not, consider modern alternatives (e.g., Akeneo’s API connectors or third-party PIM integrations).
2. Can we isolate this in a microservice? Instead of bundling, wrap CNET logic in a Symfony standalone service communicating via Akeneo’s API.
3. What’s the cost of backporting? A rewrite would require 3–6 months of development (architecture, testing, QA).
4. Are there modern Akeneo connectors for CNET? Check Akeneo Marketplace or CNET’s official APIs.
5. What’s the data volume? CSV imports may fail at scale; evaluate Akeneo’s job queue system (pim:job:execute).

Integration Approach

Stack Fit

• Target Environment: Akeneo PIM v5/v6+ (Symfony 5/6, PHP 8.0+).
• Compatibility Issues:
  • Bundle System: Modern Akeneo uses autoloaded bundles (no AppKernel.php). Workaround: Use a custom Symfony bundle or Akeneo extension.
  • Database Schema: Akeneo v5+ uses Doctrine migrations (pim:installer:migration). The connector’s doctrine:schema:update would need replacement.
  • Asset Pipeline: yarn webpack is replaced with Vite or Webpack Encore in newer versions.
• Alternative Approach: Instead of bundling, implement as a standalone Symfony service that:
  • Fetches CNET data via HTTP client (Guzzle).
  • Maps to Akeneo’s GraphQL API or REST endpoints.
  • Uses Akeneo’s job system for batch processing.

Migration Path

1. Assessment Phase:
   • Audit CNET’s current API against the connector’s legacy assumptions.
   • Validate if data can be mapped to Akeneo’s native attributes (avoiding CustomEntityBundle).
2. Option 1: Full Rewrite (Recommended for Critical Use Cases)
   • Create a new Symfony bundle or Akeneo extension.
   • Replace CSV imports with Akeneo’s API clients (pim/api-client).
   • Use Akeneo’s job queue for async processing.
   • Deprecate CustomEntityBundle in favor of native attributes.
3. Option 2: Microservice Isolation
   • Deploy a separate Symfony app that:
     • Polls CNET’s API.
     • Pushes data to Akeneo via GraphQL mutations.
     • Uses Akeneo’s OAuth2 for authentication.
4. Option 3: Abandon (Low Priority)
   • If CNET data is non-critical, replace with modern connectors (e.g., Akeneo’s API Platform).

Compatibility

Sequencing

1. Phase 1: API Validation (2 weeks)
   • Verify CNET’s current API structure.
   • Document mapping to Akeneo’s data model.
2. Phase 2: Proof of Concept (3 weeks)
   • Build a minimal API client to fetch/push data.
   • Test with a subset of products.
3. Phase 3: Full Integration (6–8 weeks)
   • Develop job-based processing (if async needed).
   • Replace legacy bundles with modern alternatives.
   • Write unit/integration tests.
4. Phase 4: Deployment & Monitoring (2 weeks)
   • Roll out in staging, monitor performance.
   • Set up alerts for data sync failures.

Operational Impact

Maintenance

• Legacy Codebase: The original connector has no updates since 2018, increasing technical debt.
• Dependency Risks:
  • CustomEntityBundle and ExtendedAttributeTypeBundle are unmaintained.
  • PHP 7.4+ features (e.g., typed properties) may break compatibility.
• Modernization Effort:
  • A rewrite would require ongoing maintenance for Akeneo upgrades.
  • Consider abstraction layers (e.g., adapters) to isolate CNET logic.

Support

• No Vendor Support: Akeneo’s official support does not cover this package.
• Troubleshooting:
  • Debugging may require reverse-engineering legacy Akeneo v2 logic.
  • CNET API changes would need manual updates.
• Fallback Plan:
  • If the connector fails, manual CSV imports could be a temporary workaround (but not scalable).

Scaling

• Performance Bottlenecks:
  • CSV imports may not scale for large catalogs (Akeneo v5+ recommends API-based batch processing).
  • Database schema updates could lock tables during sync.
• Modern Alternatives:
  • Use Akeneo’s job queue (pim:job:execute) for async processing.
  • Implement pagination for CNET API calls.
• Load Testing:
  • Simulate 10K+ products to validate throughput.
  • Monitor database write performance during syncs.

Failure Modes

Ramp-Up

• **Onboarding