Forem: O ji nwayo e je

This article proposes a more elegant way to implement webhooks. The code examples are written in PHP using Suphle, a polished framework for building modern full-stack PHP applications.

A robust webhook implementation—such as consuming a payment gateway—requires several key elements, which I’ll walk through below. But first, let’s examine some pseudocode representing the ideal outcome. Any implementation that goes far beyond these essentials risks becoming boilerplate-heavy and unnecessarily complex.

Target Behavior

A typical implementation of our webhook integration might follow this flow:

Initiate payment
Receive a response
Parse and persist relevant data

We generally expect this sequence to complete successfully—requests fire as expected, payloads are intact, and the application responds meaningfully. But real-world systems often grow beyond this simplistic ideal. Complex workflows may require observability, fault tolerance, and testability woven into the entire flow. Let’s explore what that entails.

Bottlenecks in the Process

There are several critical pressure points where things can go wrong, and it's unwise to treat webhook handling as purely a business logic concern. It belongs in the infrastructure layer. Some examples:

The outgoing request might fail due to a missing parameter. Without graceful error handling, the user is stuck.
At the application boundary, we must enforce static types to reliably intercept data. If not, failure will only surface on the provider’s end, leaving users confused until reconciliation (if any) occurs.
Payload processing should happen in a decoupled business layer, enabling graceful failure and testability via mock payloads—all while respecting separation of concerns.

Fleshing It Out

Suphle helps handle infrastructure-layer concerns out of the box, offering tools for fail-safes at key points in the request lifecycle.

Let’s start with outbound request initiation. Suphle provides a base class for such requests: Suphle\IO\Http\BaseHttpRequest. It wraps outgoing PSR-compliant requests with useful features like error-catching, telemetry reporting, fallback support, and domain-level object mapping (DTOs).

Here’s a sample request borrowed from the official documentation:

use Suphle\IO\Http\BaseHttpRequest;

use Psr\Http\Message\ResponseInterface;

use GuzzleHttp\RequestOptions;

class TriggerPayment extends BaseHttpRequest {

    public function getRequestUrl ():string {

        return "http://some-gateway.com/pay";
    }

    protected function getHttpResponse ():ResponseInterface {

        return $this->requestClient->request(

            "post", $this->getRequestUrl(), [

                RequestOptions::HEADERS => [

                    "SECRET_KEY" => $this->envAccessor->getField("FLUTTER_WAVE_PK")
                ]
            ]
        );
    }

    protected function convertToDomainObject (ResponseInterface $response) {

        return $response; // filter to taste or cast to DSL
    }
}

We can then consume this in a coordinator like so:

class HttpCoordinator extends ServiceCoordinator {

    public function __construct (protected readonly TriggerPayment $httpService) {

        //
    }

    public function makePayment ():iterable {

        $dslObject = $this->httpService->getDomainObject();

        if ($this->httpService->hasErrors()) {

            // derive $dslObject some other way
        }

        return ["data" => $dslObject];
}

This is both neat and powerful. With the outbound request sorted, let’s now explore the return leg of the process—handling incoming webhook payloads.

Suphle provides a specialized request reader, Suphle\Services\Structures\ModellessPayload, which allows you to extract known domain objects (DSLs) from payloads. Validation failures at this level are sent to your telemetry service, without impacting the user journey.

Here’s a practical example:

use Suphle\Services\Structures\ModellessPayload;

class ExtractPaymentFields extends ModellessPayload {

    protected function convertToDomainObject () {

        $data = $this->payloadStorage->getKey("data");

        return new GenericPaidDSL($data["trx_id"]);
    }
}

And consumed in a coordinator like so:

class BaseCoordinator extends ServiceCoordinator {

    public function __construct (protected readonly TransactionService $transactionService) {
        //
    }

    public function myCartItems () {

        return [
            "data" => $this->transactionService->modelsToUpdate()
        ];
    }

    public function genericWebhook (ExtractPaymentFields $payloadReader):array {

        return [
            "data" => $this->transactionService->updateModels( 
                $payloadReader->getDomainObject()/*returns instance of GenericPaidDSL*/
            )
        ];
    }
}

The TransactionService encapsulates all the safety mechanisms we've introduced so far. When built correctly, extending Suphle\Services\UpdatefulService and implementing the SystemModelEdit interface guarantees mutative operations occur within safe, locked transactions—ensuring no two users mutate the same resource concurrently.

You can read more about these guarantees in the documentation on mutative decorators.


use Suphle\Services\{UpdatefulService, Structures\BaseErrorCatcherService};

use Suphle\Services\Decorators\{InterceptsCalls, VariableDependencies};

use Suphle\Contracts\{Events, Services\CallInterceptors\SystemModelEdit};

use Suphle\Events\EmitProxy;

use Illuminate\Support\Collection;

#[InterceptsCalls(SystemModelEdit::class)]
#[VariableDependencies([

    "setPayloadStorage", "setPlaceholderStorage"
])]
class TransactionService extends UpdatefulService implements SystemModelEdit {

    use BaseErrorCatcherService, EmitProxy;

    public const EMPTIED_CART = "cart_empty";

    public function __construct (
        protected readonly CartService $cartService,

        protected readonly TransactionVerifier $verifyPayment,

        private readonly Events $eventManager
    ) {
        //
    }

    public function updateModels (object $genericPaidDSL) {

        $products = $this->modelsToUpdate();

        $this->shouldDispenseService($genericPaidDSL, $products);

        $products->each->update(["sold" => true]);

        $this->emitHelper(self::EMPTIED_CART, $products); // received by payment, order modules etc

        return $this->cartService->delete();
    }

    public function modelsToUpdate ():iterable {

        return $this->cartService->authProducts;
    }

    public function shouldDispenseService(GenericPaidDSL $genericPaidDSL, Collection $products):void {

        $this->verifyPayment->setTrxId($genericPaidDSL->trxId); // used to fetch request details

        $dslObject = $this->verifyPayment->getDomainObject();

        if (
            $this->verifyPayment->hasErrors() ||
            !$dslObject->matchAmount($products->sum("price"))
        )
            throw new Exception("Fraudulent Payment");

    }
}

Much of the code above is standard boilerplate with dedicated documentation chapters. We’ve included it here for realism and completeness. What's most relevant to our webhook flow is how naturally GenericPaidDSL is consumed throughout the layers—without relying on brittle scaffolding or random PHP wiring.

Bonus: Handling Multiple Providers

Suppose your application integrates with multiple payment gateways. You could adjust ExtractPaymentFields to dynamically map incoming payloads to their appropriate DSLs:

use Suphle\Services\Structures\ModellessPayload;

class ExtractPaymentFields extends ModellessPayload {

    protected function convertToDomainObject () {

        $data = $this->payloadStorage->getKey("data");

        return match ($data["provider_indicator"]) {
            "paystack" => new PaystackDSL($data["trx_id"]),
            default => new FlutterwaveDSL($data["trx_id"]),
        };
    }
}

Alternatively, you could delegate this responsibility to Suphle’s Condition factories for even tighter encapsulation—ideal when DSLs require container hydration.

Testing

Testing is integral to engineering confidence in your implementation. Fortunately, Suphle’s architecture makes this easy:

You can skip all BaseHttpRequest subclasses and inject DSLs directly into domain classes.
Optionally test ModellessPayload subclasses if they contain complex conditionals.
Focus most of your testing efforts on TransactionService::updateModels.

Here’s how a test could look:


use AllModules\CartModule\{Meta\CartModuleDescriptor, Services\TransactionService};

use AppModels\{CartProduct, User as EloquentUser, Product};

use Suphle\Testing\{TestTypes\ModuleLevelTest, Proxies\WriteOnlyContainer, Condiments\EmittedEventsCatcher, Condiments\BaseDatabasePopulator};

class TransactionTest extends ModuleLevelTest {

    use BaseDatabasePopulator, EmittedEventsCatcher;

    protected function getActiveEntity ():string {

        return EloquentUser::class;
    }

    protected function getModules(): array {

        return [
            $this->replicateModule(CartModuleDescriptor::class, function (WriteOnlyContainer $container) {

                $container->replaceWithMock(TransactionService::class, TransactionService::class, [

                    "shouldDispenseService" => null // or simulate failure if you wish: $this->throwException(InsufficientBalance::class)
                ]);
            })
        ];
    }

    public function test_can_update_models () {

        // given
        $genericPaidDSL = new GenericPaidDSL("nmeri");

        $user = $this->replicator->modifyInsertion(

            1, [], function ($builder) {

                return $builder->has(
                    CartProducts::factory()->has(
                        Product::factory()->count(5)
                    )
                );
            }
        )[0];

        $this->actingAs($user);

        $products = $user->cart->products;

        $this->getContainer()->getClass(TransactionService::class)

        ->updateModels($genericPaidDSL); // when

        // then
        $this->assertHandledEvent(
            TransactionService::class, TransactionService::EMPTIED_CART
        );
        foreach ($products as $product)

            $this->databaseApi->assertDatabaseHas(
                Product::TABLE_NAME, [
                    "id" => $product->id,
                    "sold" => true
            ]);
    }
}

Reconciliation Job: A Final Safety Net

Even with our rigorous setup—outbound request wrappers, typed payload interceptors, and transactional guarantees—there may be rare occasions where failures escape our immediate logic. For example, a payment provider might confirm a transaction we never received due to a brief network outage or delayed webhook delivery.

To cover such cases, we schedule a cron job that queries the provider's API for transactions in a given timeframe, compares them against our own database records, and reconciles any mismatch. For semantic purposes, you might decide to implement the Suphle\Contracts\Queues\Task interface.

A hypothetical implementation may look like this:


use Suphle\Contracts\Queues\Task;

class RectifyFailedPaystack implements Task {

    public function __construct (

        protected TransactionService $transactionService,

        protected UserService $userService
    ) {}

    public function handle ():void {

        $failed = $this->transactionService->fetchPaystackTransfers() // this would implement some outbound call for fetching transactions acknowledged on payment provider side, mapped to our GenericPaidDSL
        ->filter(function (PaystackDSL $paystackDSL) {

            return !$this->transactionService->paystackHasRef($paystackDSL->trxId);
        })->each(function (PaystackDSL $paystackDSL) {

            $user = $this->userService->findByEmail($paystackDSL->email);

            $this->transactionService->addUserForPaystack($paystackDSL, $user);
        });
    }
}

We avoid using TransactionService::updateModels here since cartService::authProducts relies on authenticated user, while this code runs in a cron context devoid of users.

Conclusion

In this post, we walked through building and consuming webhooks in a watertight, testable way—leveraging Suphle’s rich features to handle common pitfalls with elegance and minimal boilerplate. From outbound request handling to payload parsing, from DSL consistency to transactional safety, Suphle has your back.

Clarification for Skeptical Readers

Although this article may appear sparse in implementation details, every major component is in fact fully functional and directly usable in a live Suphle application. The reason it seems lightweight is because Suphle handles a substantial amount of heavy lifting behind the scenes—error reporting, transactional safety, dependency injection, typed requests—all while keeping your business logic clean and testable.

Certain essentials like routing setup and module creation (Suphle supports modular monoliths out of the box) have been omitted here, not due to incompleteness, but because they aren’t central to webhook handling and are thoroughly documented in the official docs. What you see here is exactly how a production-grade Suphle app would appear, minus domain-specific logic like UI layers or custom billing flows.

If you found this helpful, please consider sharing the article and dropping a star on GitHub. Cheers!

A synopsis of the Suphle Framework

O ji nwayo e je — Wed, 26 Apr 2023 18:36:37 +0000

Introduction

Hello there. In this post we will be demonstrating some functionalities of the Suphle framework by drawing parallels between the objectives constituting its blueprint, and implementations intended to alleviate code smells that hamper project maintainability. Suphle is a new PHP framework released recently, for building sophisticated full-stack software. Suphle is most suitable for business-critical database-driven applications that will be actively maintained over time.

For readers not abreast with PHP's development in recent years, permit me to dispel the following misconceptions regarding the language:

With the aid of a load-balancer and no extensions, the PHP processes created by the Suphle server are no longer destroyed after handling each request. Application instances are re-used just as those built in other server-side languages. The project responsible for this is called Roadrunner. It equally grants us access to functionality previously absent in the language e.g. Websockets.
Suphle bundles with Psalm, a library for detecting and correcting type-related errors at compile/server-build time.
PHP is not synonymous with SQL injections and procedural functions. Majority of Suphle's functionality dwells in instantiable classes. There are zero procedural-style functions in Suphle. These classes are auto-wired for you by Suphle's Container. A plethora of ORMs exist to discourage you from exposure to SQL injection risks by minimizing direct interaction with queries.

Suphle's command for bootstrapping resource management is not marketed as a revolutionary facility, since such convenience was already possible more than a decade ago when DHH presented Rails to the world. The industry has not stagnated in that time; as such, new tools are expected to improve on that model. Despite domain uniqueness from business to business, some patterns have emerged as non-negotiable in the journey of the web's evolution:

An API
Fidelity on one or more client interfaces

Various technologies have struggled to assert their presence in every user-facing software published. From serious ones like real-time communication, to trivial ones like GDPR dialogs. Developers within this epoch start out practicing fundamentals such as retrieving input values, exchanging them for database objects, formatting them into shapes expected by the consumer. Unfortunately for them, these rudimentary etiquettes turn out grossly inadequate under real life work conditions. Most enterprise frameworks will arm its developer with the constructs for meeting these needs, but leave their usage to the developer's discretion. This is perhaps Suphle's most significant difference from them -- it's like a code review that complains about anything whose absence is dangerous.

In addition to this core drive, Suphle has the following over-arching objectives:

Breaking business logic into silos for better management between multiple maintainers. A non-existent architecture is potentially a haphazard one, making it difficult for newer collaborators to maintain the project in the absence of the original author.
Enforcing recommended code patterns that encourage cohesion, DRY, testability.
Minimizing application failure to the barest minimum.

Based on both my experience and extensive research, it is evident that certain practices are indispensable for applications that fall into the niche described earlier. There are dedicated chapters on the documentation that go into detail regarding the solutions Suphle offers for circumventing undesirable circumstances. However, diving into the tome has reportedly been overwhelming. So in this post, we will skim over an overview of them.

Business logic architecture

Modules

Perhaps the most visible update in the structure of applications built by immigrating developers is that Suphle brings native support of the tried and proven Modular-monolith concept to PHP Frameworks. It's a progression from code bases with a Controllers folder full of Controllers catering to diverse resources. Aside the potential of relevant modules being scaled into their own microservices, this structure is most advantageous in scenarios where resources entail more than basic CRUD queries. Resources that grow to this size, or those important enough to the business, may necessitate limited interference by assigning one maintainer to it, whose development and testing is designated to an environment as close as possible to isolation (even when they need to depend or communicate with each other).

Below, a Suphle application's entry point is shown to expose two modules for HTTP request handling:


namespace AllModules;

use Suphle\Modules\ModuleHandlerIdentifier;

use Suphle\Hydration\Container;

use AllModules\{ModuleOne\Meta\ModuleOneDescriptor, ModuleTwo\Meta\ModuleTwoDescriptor};

class PublishedModules extends ModuleHandlerIdentifier {

    function getModules():array {

        return [
            new ModuleOneDescriptor(new Container),

            new ModuleTwoDescriptor(new Container)
        ];
    }
}

This is your application's outskirts, superceding the intra-module route collections.

Enforced dependency prohibition

For its high flexibility, Suphle has this as one of its most opinionated aspects. Developers fall for the temptation to perform all sorts of operations within their Controllers, at the detriment of future maintainability. For this reason, Suphle's controllers are sanitized during the application's build phase. Detected violations will halt server build. Following this divergence from the traditional motive of controllers, it makes sense to redefine them into what we call Service-coordinators.

Mandatory integrations

Both frameworks and their accompanying libraries make provision for bolstering their programs with recommended integrations. Unfortunately, these aren't apparent or glaring to all users of the framework. These integrations cut across components of back-end engineering ranging from:

Not centralizing things, to,
Leaving them for later -- one of the technical debts that never gets paid down the line.
Erasing type-related errors.

In concrete terms, the following components are affected:

Image upload: The object for interacting with uploaded images is designed in such a way that further evaluation of the request fails if the image is not stored without further optimization.
Request validation: As an incentive for all validatable endpoints to be decorated by a set of rules, the Framework will terminate request handling if such endpoints are missing validation rules.
Static-type errors: Psalm is bundled with the server build command in order to either indicate or correct type-related errors in a dynamically-typed language; thereby elevating PHP to a sphere previously occupied by only TypeScript.
Database transactions: Endpoints mutating the database in a non-trivial way i.e. executing multiple disparate queries should be wrapped by a transaction. Suphle provides decorators that abstract away the low-level details such as appropriate lock strategy, error management, protecting update integrity, etc, across one or more modules.
Data modelling: Modifications to the connected ORM force all inheriting models to be composed of migrations and factories, encouraging seeding through tests rather than a DBMS.

Violations to these rules are expected to be caught during development/testing, once the routes are being visited.

Self-explanatory design

These are semantics geared towards constructing software that is better open for not only development co-location, but more robust implementation of business requirements.

Authorization: Model-based authorizers promotes authorization-based business rules from the scope of services, into the over-arching model layer itself; leaving the services to handle other computations without fear of manual adherence to those rules.
Conditional factory: This a construct for pooling conditional business rules into an OOP umbrella, abstracting it away for reuse and testability.
Input reader: This builds upon the existing convention of hydrating ORM instances out of route pattern placeholders, both granting greater flexibility in query customization to the caller and restricting database fields retrieved.
Events: Suphle is emphatic in its recommendation to use events, narrowly avoiding an enforcement of their usage. Their binding API is designed to only tolerate assignment of all handlers of events from an emitter to one listening class. It also makes special provision for listening to events emitted by neighboring modules.

A realistic event bind and emitting flow is shown below:


use Suphle\Events\EventManager;

class AssignListeners extends EventManager {

    public function registerListeners ():void {

        $this->local(CheckoutCart::class, CartReactor::class)

        ->on(CheckoutCart::EMPTIED_CART, "handleEmptied" ); // triggers CartReactor->handleEmptied with any payload sent below
    }
}


#[InterceptsCalls(SystemModelEdit::class)]
#[VariableDependencies([

    "setPayloadStorage", "setPlaceholderStorage"
])]
class CheckoutCart extends UpdatefulService implements SystemModelEdit {

    use BaseErrorCatcherService, EmitProxy;

    public const EMPTIED_CART = "cart_empty";

    public function __construct (private readonly Events $eventManager) {

        //
    }

    public function updateModels () {

        $this->cartBuilder->products()->decrement("quantity");

        $this->emitHelper(self::EMPTIED_CART, $this->cartBuilder);

        return $this->cartBuilder->delete();
    }
}

Outbound requests: Abstract HTTP requests out of the business and services department such that response can be statically represented to the caller, tested, and consumed safe from errors.

Infallible requests

Automated testing is one of software's most important facets. This is why each chapter of the documentation is punctuated with a section describing how to test the component it discusses, multiple chapters of the Appendix are dedicated to the subject, in addition to the main Testing chapter. In spite of these, it's inevitable for requests to fail in production. When that occurs, instead of jeopardizing the entire request, writing exception details to a log and waiting for the developer to attend to it, Suphle's services are engineered to not only isolate points of failure, but, with the aid of a Bugsnag configuration, report the emergency through a queued job.

Services insured by this wrapper merely need one decorator to activate it, while the caller now has to check the status of the object before consuming its result.

Suppose we have some Coordinator fetching data from the sources service1Result and service2Result in order to complete its request, a volatile service2Result can be reliably executed as follows:


$response = compact("service1Result");

$service2Result = $this->throwableService->getValue();

if ($this->throwableService->matchesErrorMethod("getValue"))

    $service2Result = $this->otherSource->alternateValue(); // perform some valid action

$response["service2Result"] = $service2Result;

return $response;

Even without the check $this->throwableService->matchesErrorMethod("getValue"), a failure of the preceding statement will not disrupt the successful response nodes, as long as they are independent of each other.

As you may have guessed, this is most useful to SSR applications where content is fetched and rendered in one go rather than tiny requests to diverse endpoints.

Some dessert to go with your Suphle

We have discussed features whose usage the Framework vehemently considers critical. In addition to them, Suphle introduces new constructs you are unlikely to have seen anywhere else:

Flows: This is an experimental performance booster for optimistically loading various kinds of responses before they are being made. Front-end frameworks already do this but no back-end framework currently preserves outgoing response, extracts nodes out of it, visits them using developer-defined rules, caches the result, serves and invalidates the cache with the intricacies relating to resource originator.
Bridge: This is intended to facilitate onboarding existing web-based projects written in other PHP frameworks, instead of recreating them from scratch in Suphle.
Route collection utilities: Aside their traditional responsibility of translating incoming requests into complementary Coordinators, Suphle's route collection brings numerous infra-level equipments to the doorstep of the average developer. First-class support for versioned routes is currently optional.

An API can be derived from the existing browser route collections. The browser routes default to your API's v1, but can also be overridden by more specific API patterns. If this sounds familiar to the concept of Content-Negotiation, it's because they are remotely similar. However, Route-mirroring differs ever so slightly: Content-Negotiation is often implemented as a middleware that simply replaces response format. It's inadequate for applications that require entirely different content on specific paths, for example between the mobile and web versions.

Suphle's route collections also bring closer the concept of canary requests for A/B, internal, and temporary feature releases. Canary collections are like custom route collections for defining any conditions for determining what actual route collection the Router should use in serving the request.

Catching up with the web's evolution

So, where does Suphle stand within the current development standards? DHH has repeatedly proven to be a futurist ahead of his time. One of his great gifts to the development world is a handy library that brings fidelity to server-rendered software, for a fraction of the complexity or replicating that using front-end frameworks.

Suphle leverages these libraries for its presentation layer, entirely obviating the need for an API or dedicated front-end developers.

Summary

Some have argued that not all applications require this level of meticulousness, and that is correct. The sort of applications that derive little to no benefit from the optimizations and introductions discussed here, the framework will be an overkill. It's neither something to be ashamed of or hate the Framework for.

However, do beware of prevention being better than cure. An anecdote to buttress this admonition may suffice: An important document I was writing recently, got overwritten when I unwittingly edited it in-between my devices. All updates made on my laptop were lost when the phone resumed where I left off and synced with the server by sending its present contents.

Since it's neither a collaborative or version controlled program, syncing local copies kind of makes sense, under the assumption that changes may have been made while device was offline. Suphle on the other hand, averts this tragedy using one of the decorators discussed earlier, specifically, MultiUserModelEdit, discussed at length in its appropriate section. Ideally, the user should have been informed of a newer version by terminating the synchronization, regardless of whether it's a collaborative or version controlled software. Thus, it may not be entirely wise to wait until you find a use-case for all components mentioned here.

Most applications are essentially CRUD, but even among them, there are those whose endpoints hardly make simplistic queries. They entail computation of, sometimes, frequently changing business rules. A lot of thought ought to go into their implementation instead of simply going with the flow. Applications that fall into this bracket may find integrating Suphle's implementations painstaking. However, Suphle's mission is standing in as a disciplinarian, not to make the developer's life more difficult. Its utilities should enlighten and equip us with conventions and adequate tooling for improving the quality of our programs.

Introducing Suphle - The tale of a modern PHP framework

O ji nwayo e je — Sat, 24 Dec 2022 20:30:51 +0000

Introduction

Suphle is an opinionated PHP framework for enterprises and SAASes to build anything from command line applications, to robust APIs, to server rendered web apps, without compromising on the high fidelity of SPAs. Because the line between the last two in Suphle is nonexistent, you can virtually go from creating the back end of a web app to having a versioned, documented API in a heartbeat. Aside that, it guarantees your app will never break until you want it to; be it after product release or subsequent maintenance. Then, it has first class support for modular monoliths that can either be exhumed into their own micro-service or used as template for extending modules to reuse.

Suphle is anything but a jamboree for the author to understand how routing requests to controllers work. Its intended audience is enterprises with a fleet of developers working hands-on to create solutions to positively impact users relying on its efficiency. It starts to shine during rapid application development or in environments experiencing feature creep

Whichever is the case, your resulting program should not compromise on being an architectural masterpiece – an art form in itself

"Copy that. Tbf the overview sound great, but does it contain what my current framework does?"

What are the regular culprits you expect at any serious back end framework? Routing, container, authentication, authorisation, events, DAL, testing, middleware, controllers. The rest are nice to haves: task scheduling, sessions, http, cache, templating, validation, exception handling, CLI. Remind me if I missed anything.
Suphle has all that, and more.

"Bold statement. What could possibly be more than those?"

Components themselves arguably don't make a framework. That is why indie developers can get away with cobbling random libraries that fit their needs together instead of starting with the gigantic household names. The first version of Suphle handled middleware, authentication and routing in one class <=500 LOC. It was functionally, a framework that demonstrated the possibility of not formalizing components.

What has been done differently this time around is to

Formalize the components to better accommodate their now larger capacity and recognise diverging responsibilities.
More importantly, to take the spotlight away from components in and of themselves, and instead, point it onto the larger picture. This involves the following expectations:

1) Domain maintenance as perceived by business department
2) Seamless end user experience
3) Testability
4) Project evolution without strict reliance on:

i) Collaboration guidelines or
ii) Developer competence

5) Better managed errors

One of the factors that best exemplifies insignificance of components is that majority of Suphle is democratised by being composed of contracts. There is no little to no vendor lock-in, as long as your component of choice fulfills expected contract

The main takeaway here is to repurpose those known components toward these goals or create new ones when the existing ones can be improved upon. While frameworks number in the dozen, core libraries in even greater abundance, Suphle can be thought to take things a step further to bridge the gap left behind. Below, we look at real life examples of the bullet points outlined above:

Internal feature release and archiving features
Breaking unchanged parts of the code by modifying dependencies cuz No clearcut dependency chain, and certainly, no integration tests
Requiring a full stack developer to work on our UIs (before they were ported to SPAs)
Entire pages crashing because of an error affecting an insignificant page segment/data node
Waiting for negative customer feedback before knowing something went wrong, then wrangling error logs
Sacrificing man hours after giving up on SSR. A front end dev was hired. The back end had to be duplicated into an API with slightly diverging functionality.
Chasing and duplicating state and errors between the SPA and back end, for the sole purpose of a SPA-ey feel/fidelity
Cluelessness when our callback URLs broke in transit
API documentation, testing, breaking clients thanks to indiscriminate updates since there was no versioning
Irresponsible practices such as requests without validators, fetching all database columns, improper or no model authorisation, dumping whatever we had nowhere else to put in middlewares, gigantic images ending up at the server, models without factories, stray entities floating about when their owner model gets deleted, not guarding negative integers from sneaking in from user input, I could go on
Corrupted data when operations separated by logic, that should've been inserted together gets broken in between
Gnarly merge conflicts among just a handful contributors

If you or your team are struggling with any of these, you're in luck! They are some of the problems Suphle was built to solve

"Haha! I am howling right now. Tbh, giving it a try is really tempting at this point, but I'm a little sceptical given its young age and obvious lack of libraries. Might check back, later?"

Yes, it's brand new, but it doesn't lack any more libraries than laravel. The bridge component has adapters well defined to encourage development of plugins for other frameworks. But currently, the laravel adapter enables you access your laravel service providers, container bindings, routes, config, helpers, migrations, in Suphle without the friction that should've come from combining two drastically contrasting frameworks. Mind you, each of them is active on an opt-in basis. Suphle doesn't operate an exclusive us vs them model. It's an inclusive us AND them. Don't throw away your existing apps or port them.

"Are you kidding me?!"

Thankfully, not. Matter of fact, There's an appendix in the docs that go into detail about the ins and outs of automating your tests, especially intended for those who don't know how to, tried and failed to wrap their heads /workflow around TDD, or who don't really think testing is important – that demographic of developers. It even includes articles for progressive development and inclusion of new features, replacing old ones etc.

"..."

Ha! I think you mean "take all my existing and future codebases". As of the moment, the documentation is still in the works, I'll say >80%. Docs repo can be cloned to get a feel of what's going on. The tests can equally be used to fill missing gaps. No further modification will be made to the APIs until the official release. It'll be announced here but you can also watch the repo.

If you're interested in contributing, one feature that won't accompany the first release although I absolutely wish it did, is the routing aggregator. It's the one part of the blueprint discussed above that is yet to be implemented.

To show support, kindly consider leaving a star on the repo. Many thanks for reading