[Question]: Best Practices

[RaphaelStoerk]

What is your question?

Vielleicht wäre in den Docs folgender Hinweis noch gut:

bei "großen" Ressourcen solte darauf geachtet werden, die Werte der conditional Methoden in eine Funktion zu packen.

// statt
'users' => $this->whenFull([UserResource::collection($this->users)]),

// besser
'users' => $this->whenFull(fn() => [UserResource::collection($this->users)]),

Dieser kleine Unterschied kann im Notfall einiges an Effizienz rausholen, da die Werte im ersten Fall vor der Bewertung des conditional berechnet werden. Heißt bei Ressourcen werden dabei immer alle Daten ausgewertet, auch wenn am Ende keine davon relevant wären

Additional Notes

No response

[julian-farbcode]

@RaphaelStoerk
Ich habe das gerade mal getestet.
Das einzige, was minimalen overhead ohne closure hat, ist die Instanziierung der nested Resource Klasse, aber dass die wirklichen Werte berechnet werden konnte ich nicht bestätigen.
toArray wird nur aufgerufen, wenn die Resource wirklich serialisiert wird.

Eine Ausnahme ist, wenn genestete Resources mit ->resolve() direkt innerhalb der Parent-Resource aufgerufen wird. Sehe ich aber allgemein keinen Grund, das wirklich zu tun 🤔

Sonst hätte Laravel selbst ja auch ein Performance-Problem mit Conditionals und nested Resources :)

---

Mein Test:

// CatResource.php
class CatResource extends StatefulJsonResource
{
    /**
     * Transform the resource into an array.
     *
     * @return array<string, mixed>
     */
    public function toArray(Request $request): array
    {
        return [
            // ...
            '_test' => $this->whenStateFull(DogResource::collection($this->enemies)),
        ];
    }
}

// DogResource.php
class DogResource extends StatefulJsonResource
{
    /**
     * Transform the resource into an array.
     *
     * @return array<string, mixed>
     */
    public function toArray(Request $request): array
    {
        dd('DogResource toArray called!');
        return [
            'id' => $this->id,
            'name' => $this->name,
            'breed' => $this->whenState(State::Full, $this->breed),
        ];
    }
}

$resource = CatResource::state('table')->make($cat)->toJson(); // kein dd() von DogResource toArray

$resource = CatResource::state('full')->make($cat)->toJson(); // "DogResource toArray was called!"

[RaphaelStoerk]

Okay, ich geb zu mein Beispiel hat meinen Punkt nicht unbedingt unterstrichen 😅

Du hast da natürlich recht, wenn es um genestete Ressourcen geht macht das (fast) keinen wirklichen Unterschied. Was ich aber eigentlich meinte waren Aufrufe von Relations und gettern innerhalb der oberen Ressource beim Auswerten dieser. Vielleicht machen folgende Fälle das klarer:

[
    // queries, die nicht durch relation abdeckbar sind
    'keys_veranstaltungskategorien'        => $this->getVeranstaltungskategorien()->pluck('id'),
    'lockingTypes'                         => LockingTypeResource::collection(Sperrart::all()),
    // Funktionen, die potentiell weitere queries erzeugen
    'addressAsString'                      => $this->getAddressAsString(),
    'usedInModule'                         => $this->isUsedInModule(),
    'averageDonationAmount'                => $this->calculateAverageDonationAmount(),
    'used_free_registrations_current_year' => $this->getUsedFreeRegistrationsForCurrentYear(false),
    'emailCommunications'                  => KommunikationDatenkorrekturResource::collection($this->getAllEmail()),
    // rekursive relations
    'childKriterien'                       => KriteriumResource::collection($this->allChildKriterienAsTree),
]

Also es geht mir darum, dass Ressourcen intern nicht nur Ressourcen aufrufen können, sondern eben auch komplexere Berechnungen durchführen könnten. Und eben auch Relations aufrufen, die evtl. nicht optimiert sind, etwa in der EventResource in FP wurden alle Participants in einer Relation geladen, was nur für einen State sinnvoll ist aber etwa in einer Tabelle mit 50 Veranstaltungen mit je tausend Teilnehmenden zu Problemen führt,
Mir selber hilft es sich solche Dinge im Hinterkopf zu bewahren, deswegen fände ich einen Hinweis ganz nett, aber ist kein Muss ☺️

[julian-farbcode]

@RaphaelStoerk

Hm, ich finde Resources sind eigentlich nicht der richtige Ort, um solche komplexen Transformationen generell zu machen..
Ich sehe sowas eher in der vorausgehenden Query-Logik, die schon das meiste parat haben sollte.

Die Doku von Laravel sieht es auch so, dass Ressourcen nur für Transformationen der Darstellung da sein sollten.

Ich sehe solche Logik generell eher in Controllern, bzw. der Klasse, die die Resource aufruft.
Klar hilft dann ein wrapping in eine closure, aber ich bin eben generell kein Fan von dem Pattern, alles in die Ressource zu packen.

Ich denke eben, wir laufen so immer noch Gefahr, n + 1 Probleme trotz automatischem eager loading zu kriegen..

Für deine Beispiele können wir doch in allen Fällen Accessors verwenden, die genau für sowas gedacht sind, oder? 🤔
Die werden genau so wie die nested Resources selber auch nur aufgerufen, wenn das Model / die Ressource serialisiert wird.

[RaphaelStoerk]

So tief wollt ich gar nicht einsteigen 😅 ich glaub wir sehen das von unterschiedlichen Seiten, natürlich sollte man sich grundsätzlich Gedanken machen, an welcher Stelle welche Daten verarbeitet werden. Und Accessors sind oft eine gute Lösung zur Optimierung und Strukturierung, ändern aber nichts an der Grundproblematik.

Etwa ein Accessor der Form

    protected function averageParticipantAge(): Attribute
    {
        return Attribute::make(
            get: function () {
//                dd('test');
                $ages = $this->participants()
                    ->whereNotNull('birthday')
                    ->get()
                    ->map(fn(Participant $participant) => $participant->getAgeAtParticipation())
                    ->filter();
                return $ages->isEmpty() ? null : round($ages->avg(), 1);
            }
        );
    }

Wenn ich die EventResource schreibe als

[
    // ...
    'average_participant_age' => $this->whenStateFull($this->average_participant_age),
]

aber die Resource als EventResource::table()->collection($events) aufrufe wird dennoch die Accessor get Methode ausgeführt (zu sehen an dem dd()). Wenn ich aber stattdessen schreibe

[
    // ...
    'average_participant_age' => $this->whenStateFull(fn() => $this->average_participant_age),
]

passiert das nicht.
Und ja, die beste Variante wären Caches oder eine optimierte Verwaltung der Daten, aber das sind unabhängig von meinem Gedanken hier immer Themen, mit denen man sich beschäftigen sollte. Es geht mir grundsätzlich nur darum, dass ich Berechnungen innerhalb einer Ressource besser trennen möchte, wenn ich diese nicht unbedingt brauche.
Deswegen, ich fände den Hinweis nett, aber der löst natürlich niemals die komplexeren Hintergründe optimierter Code-Struktur an sich, sondern dient einem schnellen und sauberen trennen der Kontext-gebundenen Berchnungen ☺️

[julian-farbcode]

@RaphaelStoerk
Danke für dein Feedback, ich hatte bei meinem ersten Test die falsche Ressource getestet und deshalb bin ich darauf gekommen, dass Accessors/Attributes nicht direkt aufgerufen werden😅

Hatte kurz damit experimentiert, die Logik wie StatefulResources auf Model-Attributes/-Accessors zugreifen zu überschreiben und automatisch lazy zu machen, war im Endeffekt aber zu überkompliziert und hätte zu 100% zu Side-Effects geführt.

Ich hab jetzt die Dokumentation angepasst und einen Abschnitt dafür in Basic Usage hinzugefügt: #5

Und wenn wir das Package mal ins Baseprojekt mit aufnehmen, können wir ja dort auch einen Satz dazu machen, möglichst immer Closures zu verwenden :)