- What is palpalani/laravel-sqs-queue-json-reader used for?
- It is a narrow Laravel queue adapter for reading plain JSON payloads from AWS SQS queues, especially messages not serialized by Laravel's own job serializer. It is useful when another service, Lambda function, or legacy producer writes JSON into SQS and a Laravel worker must consume it. It is not a general messaging abstraction or multi-transport platform.
- How do I install and configure laravel-sqs-queue-json-reader in a Laravel app?
- Install with Composer using palpalani/laravel-sqs-queue-json-reader, then publish any package configuration and define an SQS-backed queue connection for the reader. You will also need to map raw JSON payloads to application jobs or handlers and run a Laravel queue worker against that connection. The integration surface is intentionally small, but test the payload mapping in a short spike before rollout.
- Does laravel-sqs-queue-json-reader support Laravel 13?
- Version 0.6.0 adds Laravel 13.x support, but the assessment cautions that automated compatibility means the test matrix passes, not that every deprecation or internal API change is exercised in your usage shape. Check composer.json for the exact PHP and Laravel constraints and run your own tests. Do not assume broader framework support without verifying the installed version.
- Can it consume SQS messages produced by non-Laravel services?
- Yes, that is the package's main use case: consuming JSON messages in SQS whose bodies were produced outside Laravel. It acts as a boundary or anti-corruption layer between foreign producers and Laravel jobs. You still need to define and validate the mapping from raw payload shape to application work.
- What changed in version 0.6.0 for SQS message deletion?
- The 0.6.0 fix checks whether Laravel already deleted the SQS message before the package attempts deletion, addressing stale receipt handle or duplicate-delete style failures. The important production question is whether a failed or skipped delete causes redelivery after the visibility timeout or silent message loss. Test that behavior explicitly with your queue configuration rather than relying on the PR title.
- Is this package safe to use in production?
- Treat it as pre-1.0 software: minor releases are not contractually non-breaking, so pin exact versions and read every changelog diff that touches the queue connection, job class, or delete path. Maintainer concentration is a risk because the project has a single primary maintainer and a small contributor base. The narrow scope limits blast radius but does not remove the need for integration tests.
- Can it run alongside Laravel's native SQS driver in the same application?
- The package is intended as a custom queue reader, and the assessment recommends proving in a spike whether it composes cleanly with Laravel's native sqs driver in the same application. That matters if native Laravel queues and foreign-message queues must coexist during a transition. Verify connection names, worker configuration, and delete behavior when both drivers are active.
- How does it handle malformed JSON or schema drift?
- The provided context does not document a specific malformed-JSON, missing-key, or schema-drift policy, so do not assume silent skipping or automatic dead-lettering. Prove in a spike whether bad payloads raise exceptions, fail the job, or get discarded, and add validation plus a dead-letter queue if needed. This is one of the highest-risk areas for a boundary adapter.
- Does it support SQS FIFO queues, batching, middleware, or rate limiting?
- SQS FIFO support, deduplication semantics, job middleware, Bus::batch, and rate limiting are not confirmed by the available context and should be treated as open questions. Because the package consumes non-native message shapes, verify whether Laravel features that depend on native job payloads still apply. Test each feature you rely on before using it in production.
- When should I avoid palpalani/laravel-sqs-queue-json-reader?
- Use Laravel's native SQS driver when your messages are produced by Laravel's own job serializer and you do not need foreign JSON consumption. Use a custom consumer or a broader event platform if you need schema registry, routing DSL, multi-transport support, or documented at-least-once contracts. Avoid this package as a platform foundation; it is a focused adapter for one boundary problem.