Nachdem ich mehr als vier Jahre in Laravel verbracht habe, bin ich mit der MVC-Architektur (Model-View-Controller) sehr vertraut geworden. Seine Einfachheit und Struktur machen die Arbeit damit zum Vergnügen und die sorgfältig organisierten Ordner von Laravel helfen Entwicklern, den Überblick zu behalten. Sie wissen immer, wo Sie Ihren Code platzieren müssen, und die umfangreichen integrierten Tools – Datenbankverbindungen, Redis, Warteschlangen, Migrationen, ORM und mehr – sorgen für eine reibungslose Einrichtung. Mit nur wenigen Anpassungen an Ihrer Umgebung ist Ihre App einsatzbereit.
Für mich bleibt der MVC-Ansatz von Laravel einer der robustesten. Das Modell definiert Ihre Daten, die Ansicht bestimmt, was Benutzer sehen, und der Controller verwaltet Ihre Geschäftslogik. Es ist einfach, aber strukturiert, und Laravel liefert dieses Setup standardmäßig mit, was es zu einem hervorragenden Framework für die Entwicklung macht.
Aber als meine Karriere voranschritt und ich branchen- und unternehmensübergreifend arbeitete, wurde mir klar, dass der MVC-Ansatz von Laravel nicht immer ausreichte, insbesondere für komplexe Anwendungen.
MVC glänzt bei einfachen Anwendungen, kann jedoch versagen, wenn die Logik komplexer wird. Wenn Sie beispielsweise Laravel für APIs verwenden, bleibt die Ebene Ansicht häufig ungenutzt. Unterdessen kann die Unterbringung der gesamten Logik in Controllern schnell zu aufgeblähten Dateien führen, die schwer zu warten sind.
Um dieses Problem zu beheben, habe ich die MVC-Struktur von Laravel durch die Einführung der Schichten Service und Repository erweitert und so einen Ablauf wie diesen erstellt:
Controller → Service → Repository → Modell
Dieser mehrschichtige Ansatz macht den Code wartbarer und skalierbarer. Mit der Zeit habe ich mich so sehr an diese Struktur gewöhnt, dass es für mich selbstverständlich war, sie auch in anderen Projekten zu übernehmen.
Als ich anfing, mit Go (Golang) zu arbeiten, fühlte es sich an, als würde ich Neuland betreten. Go unterscheidet sich stark von PHP und verfügt nicht über eine inhärente Ordnerstruktur. Da es sich auch nicht um eine objektorientierte Sprache handelt, konnte ich das, was ich von Laravel wusste, nicht einfach reproduzieren.
Nach einigem Ausprobieren habe ich beschlossen, bei dem zu bleiben, was mir bekannt war: dem CSRM-Konzept (Controller, Service, Repository, Modell). Ich habe diese Struktur an Go angepasst, auch wenn dafür etwas kreatives Denken erforderlich war. Darüber hinaus habe ich Frameworks untersucht, die die Entwicklung vereinfachen könnten. Ich habe Gin und Fiber ausprobiert und mich letztendlich aufgrund der Geschwindigkeit, der modernen Funktionen und der aktiven Community für Fiber entschieden.
Nachdem ich mehr als zwei Jahre lang mit Go und Fibre gearbeitet hatte, beschloss ich, ein Standardmodell zu erstellen, um die API-Entwicklung zu optimieren. Das war nicht nur für mich – ich wollte auch anderen helfen, ihre Projekte schnell umzusetzen.
Das Ergebnis: Fiber API Boilerplate.
Dieses Boilerplate ist speziell für APIs gedacht und enthält daher keine Funktionen wie Ansichtsrendering oder Vorlagen-Engines. Die Ordnerstruktur ist inspiriert von:
Ich habe auch viele Ideen von Laravel übernommen, wie zum Beispiel ORM, Datenbankverbindungen, Redis, Warteschlangen und Authentifizierung. Es ist zwar nicht so umfassend wie Laravel, aber für die Erstellung allgemeiner APIs mehr als ausreichend.
Das bietet das Boilerplate derzeit:
Das Repository enthält außerdem Beispielcode und eine detaillierte README-Datei, die Sie durch jeden Ordner und jede Funktion führt.
Während das Boilerplate bereits funktionsfähig ist, habe ich Pläne, es durch das Hinzufügen von Tools wie Migrationen, Ereignis-Listenern und Befehlen weiter zu erweitern. Es handelt sich um ein sich entwickelndes Projekt, das darauf ausgelegt ist, mit seinen Benutzern zu wachsen.
Sie können die Boilerplate gerne erkunden und nutzen. Sie können es jederzeit anpassen – fügen Sie Tools hinzu, die Ihnen gefallen, oder entfernen Sie diejenigen, die Sie nicht benötigen. Wenn Sie Vorschläge oder Funktionswünsche haben, erstellen Sie ein Problem oder senden Sie eine Pull-Anfrage.
Schauen Sie sich die Fiber API Boilerplate an und probieren Sie es aus. Ich hoffe, dass es Ihre Reise zur Go-API-Entwicklung genauso vereinfacht wie für mich. Lasst uns gemeinsam etwas Großartiges aufbauen!
Das obige ist der detaillierte Inhalt vonLaravel to Go: Meine Reise und die Erstellung einer Faser-API-Boilerplate. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!