Skip to content

Conversation

@birdcar
Copy link

@birdcar birdcar commented Dec 11, 2025

This change introduces Laravel-specific patterns for interacting with WorkOS:

  • A WorkOS facade for static access (e.g. WorkOS::userManagement()->listUsers())
  • A global workos() helper function for fluent access everywhere (e.g. workos()->userManagement()->listUsers())
  • WorkOSService singleton with cached service instances
  • Dependency injection support via service container binding

Additionally, while working on this I noticed a potential performance issue. Previously the service container was setting the API Key and Client ID on every request. The service container now configures the SDK only when requested, and its configuration is cached on subsequent requests.

this does not break or change any existing client code.

Intriguing, tell me more

Throughout Laravel, there are multiple common patterns used to get access to the various services/components of your application. For example, if you're issuing a response, you could either import and use the Response Facade directly:

use Illuminate\Support\Facades\Response;
 
Route::get('/users', function () {
    return Response::json([...]);
});

Alternatively, you could use a global helper as a one-off:

Route::get('/users', function () {
    return response()->json([...]);
});

Or, finally, you could inject the dependency into a function as a typed argument, and it will be automatically resolved by the Service Container:

use Illuminate\Support\Facades\Response;
 
Route::get('/users', function (Response $response) {
    return $response->json([...]);
});

This PR updates the code so that we enable similar ergonomics using their usual patterns. For example:

/* Facade version */
use WorkOS\Laravel\Facades\WorkOS;

Route::get('/users', function () {
    return WorkOS::userManagement()->listUsers();
});

/* Helper version */
Route::get('/users', function () {
    return workos()->userManagement()->listUsers();
});

/* Injection version */
use WorkOS\Laravel\Services\WorkOSService;

Route::get('/users', function (WorkOSService $service) {
    return $service->userManagement()->listUsers();
});

These are automatically registered immediately upon installing the workos-php-laravel package, and make it much, much easier to productively integrate the client into your project.

This change introduces Laravel-specific patterns for interacting with
WorkOS:

* A WorkOS facade for static access (e.g. WorkOS::userManagement()
  ->listUsers())
* A global workos() helper function for fluent access everywhere
  (e.g. workos()->userManagement()->listUsers())
* WorkOSService singleton with cached service instances
* Dependency injection support via service container binding

Additionally, while working on this I noticed a potential performance
issue. Previously the service container was setting the API Key and
Client ID on every request. The service container now configures the
SDK only when requested, and its configuration is cached on subsequent
requests.
@birdcar birdcar requested a review from a team as a code owner December 11, 2025 21:39
@birdcar birdcar requested a review from nicknisi December 11, 2025 21:39
@birdcar
Copy link
Author

birdcar commented Dec 11, 2025

Oof, apparently I need to figure out some dependency issues, Let me do that real quick.

@birdcar birdcar force-pushed the birdcar/better-laravel-ergonomics branch from 0ad0eae to b0896e4 Compare December 11, 2025 22:33
@birdcar
Copy link
Author

birdcar commented Dec 11, 2025

Oooook, some dependency weirdness and incompatibility existed in the composer. But after comparing everything on packagist to our stated requirements (and verifying with Claude) things should be good now 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants