Warum brauchen wir immer noch Gin, wenn wir net/http haben?

I. Einleitung

Im Go-Sprach-Ökosystem besitzt das net/http-Paket als Standard-HTTP-Bibliothek leistungsstarke und flexible Funktionen. Es kann verwendet werden, um Webanwendungen zu erstellen und HTTP-Anfragen zu verarbeiten. Da dieses Paket zur Go-Sprachstandardbibliothek gehört, können alle Go-Programme es direkt aufrufen. Angesichts der Tatsache, dass es bereits eine so leistungsstarke und flexible Standardbibliothek wie net/http gibt, warum entstehen dann immer noch Bibliotheken von Drittanbietern wie Gin, die beim Erstellen von Webanwendungen helfen?

Tatsächlich hängt dies eng mit der Positionierung von net/http zusammen. Das net/http-Paket bietet grundlegende HTTP-Funktionen, und sein Designziel konzentriert sich auf Einfachheit und Allgemeingültigkeit, anstatt auf fortschrittliche Funktionen und eine komfortable Entwicklungserfahrung. Bei der Verarbeitung von HTTP-Anfragen und dem Erstellen von Webanwendungen können Entwickler auf eine Reihe von Problemen stoßen, was genau der Grund ist, warum Bibliotheken von Drittanbietern wie Gin entstanden sind.

Im Folgenden wird die Notwendigkeit des Gin-Frameworks erläutert, indem eine Reihe von Szenarien erläutert und die verschiedenen Implementierungsmethoden von net/http und Gin in diesen Szenarien verglichen werden.

II. Umgang mit komplexen Routing-Szenarien

Im tatsächlichen Entwicklungsprozess von Webanwendungen ist es äußerst üblich, das gleiche Routing-Präfix zu verwenden. Hier sind zwei relativ typische Beispiele.

Beim Entwurf einer API muss die API im Laufe der Zeit häufig aktualisiert und verbessert werden. Um die Abwärtskompatibilität zu gewährleisten und das gleichzeitige Vorhandensein mehrerer API-Versionen zu ermöglichen, werden in der Regel Routing-Präfixe wie /v1, /v2 usw. verwendet, um verschiedene Versionen der API zu unterscheiden.

Ein weiteres Szenario ist, dass große Webanwendungen in der Regel aus mehreren Modulen bestehen, wobei jedes Modul für unterschiedliche Funktionen zuständig ist. Um den Code effektiver zu organisieren und die Routen verschiedener Module zu unterscheiden, wird der Modulname oft als Routing-Präfix verwendet.

In den oben genannten beiden Szenarien ist es sehr wahrscheinlich, dass das gleiche Routing-Präfix verwendet wird. Wenn wir net/http verwenden, um eine Webanwendung zu erstellen, sieht die Implementierung in etwa wie folgt aus:

package main

import (
        "fmt"
        "net/http"
)

func handleUsersV1(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "User list in v1")
}

func handlePostsV1(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "Post list in v1")
}

func main() {
        http.HandleFunc("/v1/users", handleUsersV1)
        http.HandleFunc("/v1/posts", handlePostsV1)
        http.ListenAndServe(":8080", nil)
}

Im obigen Beispiel werden verschiedene Routing-Handling-Funktionen durch manuelles Aufrufen von http.HandleFunc definiert. Gemessen an diesem Codebeispiel scheint es kein offensichtliches Problem zu geben, aber das liegt nur daran, dass es derzeit nur zwei Routing-Gruppen gibt. Wenn die Anzahl der Routen weiter steigt, wird auch die Anzahl der Handling-Funktionen steigen, und der Code wird immer komplexer und länger. Darüber hinaus erfordert jede Routing-Regel das manuelle Setzen des Routing-Präfixes, wie z. B. des v1-Präfixes im Beispiel. Wenn das Präfix eine komplexe Form wie /v1/v2/... hat, wird der Einstellungsprozess nicht nur die Code-Architektur unübersichtlich machen, sondern auch äußerst umständlich und fehleranfällig sein.

Im Gegensatz dazu implementiert das Gin-Framework die Routing-Gruppenfunktion. Hier ist der Implementierungscode dieser Funktion im Gin-Framework:

package main

import (
        "fmt"
        "github.com/gin-gonic/gin"
)

func main() {
        router := gin.Default()
        // Create a routing group
        v1 := router.Group("/v1")
        {
                v1.GET("/users", func(c *gin.Context) {
                        c.String(200, "User list in v1")
                })
                v1.GET("/posts", func(c *gin.Context) {
                        c.String(200, "Post list in v1")
                })
        }
        router.Run(":8080")
}

Im obigen Beispiel wird eine Routing-Gruppe mit dem v1-Routing-Präfix mithilfe von router.Group erstellt. Beim Setzen der Routing-Regeln ist es nicht erforderlich, das Routing-Präfix erneut zu setzen, und das Framework wird es automatisch zusammensetzen. Gleichzeitig werden alle Regeln mit dem gleichen Routing-Präfix im gleichen Codeblock verwaltet. Im Vergleich zur net/http-Codebibliothek macht Gin die Codestruktur übersichtlicher und einfacher zu verwalten.

III. Middleware-Behandlung

Bei der Verarbeitung von Webanwendungsanfragen ist es neben der Ausführung der spezifischen Geschäftslogik in der Regel erforderlich, einige allgemeine Logiken im Voraus auszuführen, wie z. B. Authentifizierungsoperationen, Fehlerbehandlung oder Protokolldruckfunktionen usw. Diese Logiken werden zusammenfassend als Middleware-Behandlungslogik bezeichnet, und sie sind in praktischen Anwendungen oft unverzichtbar.

Erstens, bezüglich der Fehlerbehandlung. Während der Ausführung einer Anwendung können interne Fehler auftreten, wie z. B. Datenbankverbindungsfehler, Dateilesefehler usw. Eine vernünftige Fehlerbehandlung kann verhindern, dass diese Fehler zum Absturz der gesamten Anwendung führen, und stattdessen den Client über eine angemessene Fehlerantwort informieren.

Für Authentifizierungsoperationen müssen Benutzer in vielen Web-Handling-Szenarien in der Regel authentifiziert werden, bevor sie auf bestimmte eingeschränkte Ressourcen zugreifen oder bestimmte Operationen durchführen können. Gleichzeitig können Authentifizierungsoperationen auch Benutzerberechtigungen einschränken und unbefugten Zugriff durch Benutzer verhindern, was zur Verbesserung der Sicherheit des Programms beiträgt.

Daher ist es sehr wahrscheinlich, dass die vollständige HTTP-Anfrageverarbeitungslogik diese Middleware-Verarbeitungslogiken benötigt. Theoretisch sollte das Framework oder die Bibliothek Unterstützung für Middleware-Logik bieten. Lassen Sie uns zunächst sehen, wie net/http dies implementiert:

package main

import (
        "fmt"
        "log"
        "net/http"
)

// Error handling middleware
func errorHandler(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
                defer func() {
                        if err := recover(); err != nil {
                                http.Error(w, "Internal Server Error", http.StatusInternalServerError)
                                log.Printf("Panic: %v", err)
                        }
                }()
                next.ServeHTTP(w, r)
        })
}

// Authentication middleware
func authMiddleware(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
                // Simulate authentication
                if r.Header.Get("Authorization") != "secret" {
                        http.Error(w, "Unauthorized", http.StatusUnauthorized)
                        return
                }
                next.ServeHTTP(w, r)
        })
}

// Handle business logic
func helloHandler(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "Hello, World!")
}

// Additionally
func anotherHandler(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "Another endpoint")
}

func main() {
        // Create a route handler
        router := http.NewServeMux()
        
        // Apply middleware and register the handler
        handler := errorHandler(authMiddleware(http.HandlerFunc(helloHandler)))
        router.Handle("/", handler)
        
        // Apply middleware and register the handler for another request
        another := errorHandler(authMiddleware(http.HandlerFunc(anotherHandler)))
        router.Handle("/another", another)
        
        // Start the server
        http.ListenAndServe(":8080", router)
}

Im obigen Beispiel werden in net/http die Fehlerbehandlungs- und Authentifizierungsfunktionen durch die beiden Middleware errorHandler und authMiddleware implementiert. Wenn wir uns Zeile 49 des Beispielcodes ansehen, können wir sehen, dass der Code das Dekorator-Muster verwendet, um dem ursprünglichen Handler Fehlerbehandlungs- und Authentifizierungsoperationen hinzuzufügen. Der Vorteil dieser Code-Implementierung besteht darin, dass durch die Kombination mehrerer Behandlungsfunktionen über das Dekorator-Muster zu einer Handler-Kette die Fehlerbehandlungs- und Authentifizierungsfunktionen erreicht werden, ohne diesen Teil der Logik in jedem Behandlungsfunktionshandler hinzuzufügen, was die Lesbarkeit und Wartbarkeit des Codes verbessert.

Es gibt aber auch einen wesentlichen Nachteil, nämlich dass diese Funktion nicht direkt vom Framework bereitgestellt wird, sondern vom Entwickler selbst implementiert wird. Jedes Mal, wenn eine neue Behandlungsfunktions-Handler hinzugefügt wird, ist es notwendig, sie zu dekorieren und Fehlerbehandlungs- und Authentifizierungsoperationen hinzuzufügen, was nicht nur die Belastung des Entwicklers erhöht, sondern auch fehleranfällig ist. Da sich die Anforderungen ständig ändern, ist es möglich, dass einige Anfragen nur eine Fehlerbehandlung benötigen, einige Anfragen nur Authentifizierungsoperationen benötigen und einige Anfragen sowohl Fehlerbehandlungs- als auch Authentifizierungsoperationen benötigen. Basierend auf dieser Codestruktur wird die Wartung immer schwieriger.

Im Gegensatz dazu bietet das Gin-Framework eine flexiblere Möglichkeit, die Middleware-Logik zu aktivieren und zu deaktivieren. Sie kann für eine bestimmte Routing-Gruppe festgelegt werden, ohne dass jede Routing-Regel separat festgelegt werden muss. Das folgende Beispiel zeigt den Code:

package main

import (
        "github.com/gin-gonic/gin"
)

func authMiddleware() gin.HandlerFunc {
        return func(c *gin.Context) {
                // Simulate authentication
                if c.GetHeader("Authorization") != "secret" {
                        c.AbortWithStatusJSON(401, gin.H{"error": "Unauthorized"})
                        return
                }
                c.Next()
        }
}

func main() {
        router := gin.Default()
        // Add Logger and Recovery middleware globally
        // Create a routing group, and all routes in this group will apply the authMiddleware middleware
        authenticated := router.Group("/")
        authenticated.Use(authMiddleware())
        {
                authenticated.GET("/hello", func(c *gin.Context) {
                        c.String(200, "Hello, World!")
                })

                authenticated.GET("/private", func(c *gin.Context) {
                        c.String(200, "Private data")
                })
        }

        // Not in the routing group, so the authMiddleware middleware is not applied
        router.GET("/welcome", func(c *gin.Context) {
                c.String(200, "Welcome!")
        })

        router.Run(":8080")
}

Im obigen Beispiel wird eine Routing-Gruppe namens authenticated über router.Group("/") erstellt, und dann wird die Use-Methode verwendet, um die authMiddleware-Middleware für diese Routing-Gruppe zu aktivieren. Alle Routing-Regeln unter dieser Routing-Gruppe führen automatisch die von authMiddleware implementierte Authentifizierungsoperation aus.

Im Vergleich zu net/http sind die Vorteile von Gin wie folgt. Erstens ist es nicht notwendig, jeden Handler zu dekorieren, um Middleware-Logik hinzuzufügen. Entwickler müssen sich nur auf die Entwicklung der Geschäftslogik konzentrieren, was die Entwicklungsbelastung reduziert. Zweitens hat es eine höhere Wartbarkeit. Wenn das Unternehmen keine Authentifizierungsoperationen mehr benötigt, muss in Gin nur der Aufruf der Use-Methode gelöscht werden; während in net/http die Dekorationsoperationen aller Handler verarbeitet und die Authentifizierungsoperationsknoten in den Dekorationsknoten gelöscht werden müssen, was eine große Menge an Arbeit und fehleranfällig ist. Schließlich ist Gin in dem Szenario, in dem verschiedene Teile von Anfragen unterschiedliche Middleware verwenden müssen, flexibler und einfacher zu implementieren. Beispielsweise benötigen einige Anfragen Authentifizierungsoperationen, einige Anfragen benötigen Fehlerbehandlung und einige Anfragen benötigen sowohl Fehlerbehandlungs- als auch Authentifizierungsoperationen. In diesem Szenario müssen nur drei Routing-Gruppen über Gin erstellt werden, und dann rufen verschiedene Routing-Gruppen die Use-Methode auf, um verschiedene Middleware zu aktivieren, die die Anforderungen erfüllen können. Dies ist flexibler und einfacher zu warten als net/http. Dies ist auch einer der wichtigsten Gründe, warum das Gin-Framework erscheint, obwohl es bereits net/http gibt.

IV. Datenbindung

Bei der Verarbeitung von HTTP-Anfragen ist eine übliche Funktion das automatische Binden der Daten in der Anfrage an eine Struktur. Am Beispiel von Formulardaten zeigt das Folgende, wie die Daten an eine Struktur gebunden werden, wenn net/http verwendet wird:

package main

import (
        "fmt"
        "log"
        "net/http"
)

type User struct {
        Name  string `json:"name"`
        Email string `json:"email"`
}

func handleFormSubmit(w http.ResponseWriter, r *http.Request) {
        var user User

        // Bind the form data to the User structure
        user.Name = r.FormValue("name")
        user.Email = r.FormValue("email")

        // Process the user data
        fmt.Fprintf(w, "user has been created：%s (%s)", user.Name, user.Email)
}

func main() {
        http.HandleFunc("/createUser", handleFormSubmit)
        http.ListenAndServe(":8080", nil)
}

In diesem Prozess ist es notwendig, die FormValue-Methode aufzurufen, um die Daten einzeln aus dem Formular zu lesen und sie dann in die Struktur einzufügen. Wenn es viele Felder gibt, ist es sehr wahrscheinlich, dass einige Felder fehlen, was zu Problemen in der nachfolgenden Verarbeitungslogik führt. Darüber hinaus muss jedes Feld manuell gelesen und gesetzt werden, was die Entwicklungseffizienz erheblich beeinträchtigt.

Sehen wir uns als Nächstes an, wie Gin die Formulardaten liest und in die Struktur einfügt:

package main

import (
        "fmt"
        "github.com/gin-gonic/gin"
)

type User struct {
        Name  string `json:"name"`
        Email string `json:"email"`
}

func handleFormSubmit(c *gin.Context) {
        var user User

        // Bind the form data to the User structure
        err := c.ShouldBind(&user)
        if err != nil {
                c.JSON(http.StatusBadRequest, gin.H{"error": "error form"})
                return
        }

        // Process the user data
        c.JSON(http.StatusOK, gin.H{"message": fmt.Sprintf("user has been created：%s (%s)", user.Name, user.Email)})
}

func main() {
        router := gin.Default()
        router.POST("/createUser", handleFormSubmit)
        router.Run(":8080")
}

Wenn wir Zeile 17 des obigen Beispielcodes betrachten, können wir feststellen, dass durch direktes Aufrufen der ShouldBind-Funktion die Formulardaten automatisch der Struktur zugeordnet werden können, ohne dass jedes Feld einzeln gelesen und separat in die Struktur eingefügt werden muss. Im Vergleich zur Verwendung von net/http ist das Gin-Framework in Bezug auf die Datenbindung komfortabler und weniger fehleranfällig. Gin bietet verschiedene APIs, die verschiedene Datentypen Strukturen zuordnen können, und Benutzer müssen nur die entsprechenden APIs aufrufen. Net/http bietet jedoch keine solchen Operationen, und Benutzer müssen die Daten selbst lesen und manuell in die Struktur einfügen.

V. Schlussfolgerung

In der Go-Sprache bietet net/http zwar grundlegende HTTP-Funktionen, aber sein Designziel konzentriert sich auf Einfachheit und Allgemeingültigkeit, anstatt auf fortschrittliche Funktionen und eine komfortable Entwicklungserfahrung. Bei der Verarbeitung von HTTP-Anfragen und dem Erstellen von Webanwendungen ist net/http angesichts komplexer Routing-Regeln unzureichend. Für einige gängige Operationen wie Protokollierung und Fehlerbehandlung ist es schwierig, ein steckbares Design zu erreichen. In Bezug auf die Bindung von Anfragedaten an Strukturen bietet net/http keine komfortablen Operationen, und Benutzer müssen sie manuell implementieren.

Aus diesem Grund erscheinen Bibliotheken von Drittanbietern wie Gin. Gin baut auf net/http auf und zielt darauf ab, die Entwicklung von Webanwendungen zu vereinfachen und zu beschleunigen. Insgesamt kann Gin Entwicklern helfen, Webanwendungen effizienter zu erstellen, und bietet eine bessere Entwicklungserfahrung und umfangreichere Funktionen. Ob die Verwendung von net/http oder Gin gewählt wird, hängt natürlich vom Umfang, den Anforderungen und den persönlichen Vorlieben des Projekts ab. Für einfache kleine Projekte ist net/http möglicherweise ausreichend; für komplexe Anwendungen ist Gin jedoch möglicherweise besser geeignet.

Leapcell: Die Serverless-Plattform der nächsten Generation für das Golang-App-Hosting

Abschließend empfehle ich eine Plattform, die sich am besten für die Bereitstellung von Go-Diensten eignet: Leapcell

1. Multi-Sprachen-Unterstützung

• Entwickeln Sie mit JavaScript, Python, Go oder Rust.

2. Stellen Sie unbegrenzt Projekte kostenlos bereit

• Zahlen Sie nur für die Nutzung – keine Anfragen, keine Gebühren.

3. Unschlagbare Kosteneffizienz

• Pay-as-you-go ohne Leerlaufgebühren.
• Beispiel: 25 US-Dollar unterstützen 6,94 Millionen Anfragen bei einer durchschnittlichen Antwortzeit von 60 ms.

4. Optimierte Entwicklererfahrung

• Intuitive Benutzeroberfläche für mühelose Einrichtung.
• Vollständig automatisierte CI/CD-Pipelines und GitOps-Integration.
• Echtzeitmetriken und -protokollierung für umsetzbare Erkenntnisse.

5. Mühelose Skalierbarkeit und hohe Leistung

• Automatische Skalierung zur einfachen Bewältigung hoher Parallelität.
• Null Betriebsaufwand – konzentrieren Sie sich einfach auf den Aufbau.

Erfahren Sie mehr in der Dokumentation!

Leapcell Twitter: https://x.com/LeapcellHQ