SDK Proxy Strategy

SDK Proxy Strategy for Raydium Framework Projects
A best‑practice architecture for integrating any third‑party SDK into WordPress

1  Overview

The Raydium Framework lets developers enjoy modern dependency management, but it also exposes a long‑standing pain point: WordPress loads all plugin code in the same global runtime, so two plugins that ship different versions of the same SDK can crash each other.

The SDK Proxy Strategy attempts to solves that by:

• installing each SDK once, at the project root, under Composer control;
• exposing a thin, namespaced proxy class that plugins can use;
• letting you add cross‑cutting concerns (configuration, logging, retries) in one place.

---

2  Problem Statement

When multiple plugins bundle their own copies of an SDK you can hit:

Conflict	Typical symptom
Version drift	Subtle bugs, missing methods
Duplicate classes	Fatal error: cannot redeclare class
Autoload roulette	“Last loaded wins”—unpredictable behavior

---

3  Solution in a Nutshell

1. Install each required SDK once via composer require.
2. Create a proxy class in your Raydium project namespace that extends (or composes) the real SDK client.
3. Enforce usage of the proxy in all custom plugins and themes.
4. Bootstrap Composer early via a must‑use plugin.

---

4  Concrete Example — SendGrid

<?php
// File: src/Proxies/SendGridProxy.php
namespace MySite\Proxies;

use SendGrid;

/**
 * Central SendGrid entry point for the entire Raydium project install.
 *
 * Add project‑wide defaults (timeout, retries, logging) here.
 */
class SendGridProxy extends SendGrid
{
    // Optional: inject a PSR‑3 logger, wrap send() with error handling, etc.
}

Plugin usage

use MySite\Proxies\SendGridProxy;

$sg = new SendGridProxy( env('SENDGRID_API_KEY') );
$response = $sg->send($email);

Result: every plugin now compiles against one SendGrid version—the one you declared in Raydium's root composer.json.

---

5  Composer Autoload & Bootstrap

Update Raydium's composer.json (root)

{
  "autoload": {
    "psr-4": {
      "MySite\\": "src/"
    }
  }
}

Generate the map:

composer dump-autoload --optimize

---

6  Repeating the Pattern

SDK	Proxy skeleton	Typical cross‑cutting extras
Stripe	class StripeProxy extends \Stripe\StripeClient {}	Default currency, idempotency keys, telemetry
Twilio	class TwilioProxy extends \Twilio\Rest\Client {}	Messaging queue, exponential back‑off
AWS S3	class S3Proxy extends \Aws\S3\S3Client {}	Central bucket names, IAM credential rotation

(Favor composition over inheritance if the SDK’s client class is final or if you need stricter encapsulation.)

---

7  Extensibility Ideas

• Interfaces – e.g. EmailProviderInterface, PaymentGatewayInterface to enable easy swapping/mocking.
• Dependency Injection – wire proxies through a lightweight container (e.g. Pimple, Symfony DI).
• Configuration Service – centralise env‑specific secrets and feature flags.
• Unit Tests – mock the proxy, not the raw SDK, for faster and safer tests.

---

8  Key Takeaways

• One SDK, one version – conflicts disappear.
• Single integration point – add retries, logging, or metrics once.
• Cleaner plugins – they depend on your API, not an external vendor.
• Easier upgrades – bump the version in composer.json, adjust the proxy if needed, you’re done.

The SDK Proxy Strategy and Raydium brings modern PHP practices to WordPress without sacrificing the plugin ecosystem.