Rajaongkir Laravel Package

Technical Evaluation

Architecture fit. kavist/rajaongkir is a thin, single-purpose SDK wrapping the RajaOngkir shipping-cost API (Indonesian couriers: JNE, TIKI, POS, etc.). It sits at the integration edge of a Laravel application — typically called from checkout, cart, or fulfilment services to quote ongkir. It is not infrastructure-critical, but it is latency-sensitive and on the hot path of checkout, so transport reliability matters more than the package's small surface area suggests.

What v1.1.0 actually changes. Kavist\RajaOngkir\HttpClients\BasicClient swaps cURL for file_get_contents() with (presumably) a stream context. The stated goal is to reduce the cURL dependency and improve compatibility. The public method signatures appear unchanged, so this is an internal transport rewrite rather than an API change.

Integration feasibility. Low effort to adopt, but the release's premise deserves scrutiny. cURL is effectively universal in PHP 7/8 builds — including official Docker images, Forge/Vapor/Cloud/Serverless runtimes, and virtually every shared host. file_get_contents() over HTTP instead depends on allow_url_fopen=1, which is commonly disabled in hardened production php.ini files and is a standard hardening recommendation. The change may trade a near-universal dependency for a less-universal one, and it does so silently: a disabled allow_url_fopen surfaces as a warning plus false return, not a clean exception.

Technical risk.

• Runtime prerequisite inversion. Any environment with allow_url_fopen=0 now fails at call time. This is a behavioral regression risk for existing installs that upgrade on a ^1.1 constraint.
• Weaker error semantics. file_get_contents() returns false on failure and yields the status line only via the magic $http_response_header local. Distinguishing 4xx/5xx API errors (e.g. invalid destination code, quota exceeded, API key rejection) from transport failures requires careful handling that cURL's curl_getinfo() made trivial. If the package doesn't normalize this, error handling in your checkout flow may degrade from typed exceptions to generic failures.
• Timeouts and TLS. Timeouts must be set explicitly via stream_context_create; a missing default means potentially unbounded hangs on a checkout-path call. CA verification should still occur via OpenSSL, but behavior differs subtly from cURL (e.g. no CURLOPT_* knobs for redirects, proxies, or connection reuse).
• Performance. No connection reuse, no HTTP/2, no multiplexing. For a single quote call this is negligible; for a batch of city/cost lookups it is measurably worse.
• Versioning hygiene. Transport behavior and environment requirements changed in a minor bump. Consumers with "kavist/rajaongkir": "^1.0" will absorb it automatically. This is not a SemVer violation in the strict public-API sense, but it is an operational one.

Key questions.

1. Is allow_url_fopen enabled in every target environment, including staging, CI, and any customer-hosted/on-prem deployment? Who owns that check?
2. Which client does the Laravel service provider bind — BasicClient or a Guzzle/Laravel-specific client? If Laravel users resolve a different client, this release may be a no-op for them and the risk is overstated.
3. What is the default timeout in the new implementation, and is it configurable?
4. How are non-2xx responses and false returns translated — same exceptions as before, or new ones?
5. Was there a concrete compatibility complaint driving this, or is it speculative? If speculative, the trade may be net-negative.
6. Is there a test matrix covering both allow_url_fopen states and both clients?

Integration Approach

Stack fit. Standard Laravel package: service provider, config publish, facade. Transport is swappable only if the package exposes a client interface or binding override — worth confirming, because that determines whether you can pin to cURL while still taking the release. If a binding override exists, treat this release as informational and keep cURL in production until the allow_url_fopen question is settled.

Migration path.

1. Pin "kavist/rajaongkir": "1.0.*" immediately in composer.json to freeze current behavior; do not float on ^1.0.
2. Read the actual diff of BasicClient — the release note is one sentence and does not describe timeout, error handling, or context options.
3. Verify in a container that mirrors production php.ini, explicitly testing with allow_url_fopen=0 to confirm the failure mode is observable and handled.
4. Only then move to 1.1.* in staging, run the checkout/cart quote path, and compare results for success, 4xx (bad city id), 5xx, and network-timeout cases against the cURL baseline.

Compatibility. PHP version floor likely unchanged; no new extension is added (in fact ext-curl may be dropped from composer.json requirements — check whether it was, since removal would make Composer stop protecting you from the very environment gap this introduces). Framework compatibility with Laravel 9/10/11 should be unaffected since the change is transport-internal.

Sequencing. Freeze → diff review → environment audit (allow_url_fopen inventory across all deploy targets) → staging verification with failure-mode tests → production rollout behind your existing ongkir integration tests → only then relax the pin. If the package is used in any client-hosted or on-prem distribution, the environment audit must extend to those hosts before the pin is relaxed, since you cannot control their php.ini.

Operational Impact

Maintenance. Slightly negative. The package now has two transport paths across versions, and your runbooks must state which one production uses. If ext-curl was dropped from composer.json, Composer will no longer flag the missing extension, shifting the burden to your own php.ini drift monitoring. Add allow_url_fopen and ext-curl to whatever config-drift check you already run.

Support. Expect a new class of ambiguous incident: "checkout shows no shipping options." Root cause splits between RajaOngkir API outage, quota exhaustion, invalid destination, and now transport-level file_get_contents failure — all surfacing as a false return unless the package distinguishes them. Ensure your application logs the raw failure and the $http_response_header status line so on-call can triage without a code dive. Document the allow_url_fopen prerequisite in the internal runbook and in any deployment checklist.

Scaling. file_get_contents is synchronous and per-call, with no connection pooling. Single-call usage at checkout is fine. If you fan out across multiple couriers or pre-cache city lists, throughput degrades relative to cURL, and there is no clean path to parallelism. If ongkir volume grows, the right move is to cache quotes (city-id → cost, TTL-bound) rather than to optimize the transport.

Failure modes. (a) allow_url_fopen=0 → immediate, universal failure on the changed client; highest severity, easiest to detect pre-deploy. (b) Missing/unbounded timeout → hung checkout requests; verify and, if unconfigurable, wrap calls in your own timeout boundary or pin to 1.0. (c) Silent false masking an API error → wrong or empty shipping options shown to a paying customer. (d) TLS/proxy differences in locked-down corporate networks where cURL respected proxy env vars but stream contexts do not — relevant if any deployment sits behind an egress proxy. (e) composer update silently pulling 1.1.x on an existing 1.0 install is the realistic blast radius; pinning is the single highest-value mitigation.

Ramp-up. Minimal for a Laravel developer — the API is small and stable. The learning cost is not in the package but in the environment contract: whoever operates the app must know that the HTTP client now depends on a php.ini flag rather than a compiled extension. Budget a short note in onboarding docs and one line in the deploy checklist.

Recommendation. Treat v1.1.0 as a conditional upgrade, not a routine patch. Pin to 1.0.* now, complete the allow_url_fopen audit and failure-mode comparison against the cURL baseline, and adopt 1.1.x only if every deployment target satisfies the new prerequisite. If the change was made for speculative compatibility rather than a real reported blocker, the risk/benefit favors staying on 1.0.x until upstream adds an explicit timeout, normalized error handling, or a configurable transport.