PHP und Go als Tech Stack.

Lassen Sie mich zunächst mit allen Gründen beginnen, warum ich dies anderen berühmten JAVASCRIPT-Tech-Stacks vorziehe.

• Ich hasse den Trend „Javascript für alles“. Ja. Javascript kann derzeit so ziemlich alles. ABBER, ist es dabei effektiv?

• Nehmen wir ein Beispiel für eine sehr intensive CPU-gebundene Aufgabe. Dies ist ein Codebeispiel, das eine CPU-intensive Aufgabe simuliert. Und mal sehen, wie Javascript funktioniert.

Grund 1: Javascript ist bei CPU-gebundenen Aufgaben scheiße!

setTimeout(function() {
    console.log("Hello world")
}, 1000)

const startTime = Date.now();
while (Date.now() - startTime < 3000) {} //Simulating a long CPU intensive main thread task..

console.log("End")

• Also, was haben wir hier? Ich als Benutzer von JAVASCRIPT würde erwarten, dass „Hallo Welt“ nach einer Sekunde ausgedruckt wird. Und wissen Sie was? Das ist nicht der Fall. Nach 3 Sekunden spuckt es „Hallo Welt“ aus.

• Warum passiert das? Um dies zu verstehen, müssen wir verstehen, wie die Ereignisschleife in Browsern und Node-JS funktioniert. Vereinfacht ausgedrückt überprüft die Ereignisschleife gleichzeitig den Aufrufstapel und die Rückrufwarteschlangen. Die Rückruffunktion, die wir in setTimeout() übergeben, gelangt in die Rückrufwarteschlange, sobald der Timer 1000 ms abgelaufen ist.

• Aber wissen Sie was ... Der Aufrufstapel ist nicht leer, wenn der Timer mit seiner Arbeit fertig ist. Er ist immer noch damit beschäftigt, die 3 Sekunden CPU-intensive Aufgabe auszuführen, die wir geschrieben haben (Ja. Es ist eine Simulation. Keine Echtes, dummes Programm, das 3 Sekunden braucht, um das zu tun, was es beabsichtigt.

• Die Rückruffunktionen in der Rückrufwarteschlange und der Mikrotask-Warteschlange würden also verhungern. Schlechte Rückruffunktionen. Sie bekommen erst nach 3 Sekunden die Chance, in den Callstack zu gelangen. Und das ist der Grund, warum wir sehen, dass das „Hallo Welt“ nach 3 Sekunden ausgedruckt wird, obwohl ich 1000 ms angegeben habe.

Ja. Dies ist ein zufälliges Bild der Ereignisschleife, das ich aus dem Internet heruntergeladen habe. Cooles Bild.

Nehmen wir einen Go-Code, der genau das Gleiche tut.

package main

import (
    "fmt"
    "time"
)

func main() {
    time.AfterFunc(1*time.Second, func() {
        fmt.Println("Hello world")
    })

    // Simulating a long CPU-intensive main thread task
    startTime := time.Now()
    for time.Since(startTime) < 3*time.Second {
    }

    print("End")
}

Hier wird das „Hallo Welt“ nach 1 Sekunde ausgedruckt. Wie? Weil AfterFunc() auf einer eigenen GoRoutine läuft, die nichts damit zu tun hat, die Haupt-GoRoutine zu stören..

Grund 2: Ich persönlich hasse clientseitiges Rendern.

• Lassen Sie uns über ReactJS sprechen. Es schiebt die Javascript-Komponenten an den Client und schiebt dem Client so viele Dinge in die Kehle, dass die Clients anfangen zu drosseln.

• Stellen Sie sich einen Low-End-PC vor, der eine Anfrage nach einer statischen HTML-Datei stellt, und Sie erhalten eine Menge Scheiße mit Reaktionskomponenten. Wie würde sich der Kunde fühlen? Es wird langsam. Der Browser muss das Javascript analysieren, das virtuelle DOM ausführen, den HTML-Code daraus generieren. Und was nicht.

• Der Browser erledigt die gesamte Arbeit, die der Server leisten muss.

• Erinnern Sie sich an den NATÜRLICHEN FLUSS DES WEBS?

• Zuerst den HTML-Code laden, dann erst das Javascript laden? Warum? Damit die Erstlackierung so schnell wie möglich erfolgt. Erinnern Sie sich an die Tage, als wir das Javascript in die Fußzeile des HTML-Dokuments geladen haben?

• React hat einfach den gesamten Ablauf auf den Kopf gestellt.

• Und im Ergebnis muss der Kunde eine ganze Weile auf einen leeren weißen Bildschirm starren.

Mit den genannten Gründen..

• Ich wähle zwei Sprachen, die in ihrer eigenen Welt glänzen..

Gehen

• Was mich direkt beeindruckt hat, war, dass Go eine kompilierte Sprache ist und statisch typisiert ist. Man kann blind sagen, Go ist superschnell und viel schneller als Javascript.

• Es verfügt über integrierte, leichte Threads namens „GoRoutines“, die viel schneller sind als echte Betriebssystem-Threads, da die Go-Threads leichtgewichtig sind.

• Go kann zum Erstellen von RESTful-Endpunkten oder für jeden Backend-Dienst verwendet werden.

• ABER, ich kann Go nicht für SSR verwenden. PHP glänzt darin. In meinem Stack wird Go stark für CPU-intensive APIs oder andere Backend-Dienste verwendet.

PHP

• PHP ist das Beste, was ich je für SSR verwendet habe. Einfach und sehr direkt. Erstellt für jeden Client einen Prozess. Das macht es etwas langsam. Aber dennoch sind diese Prozesse unabhängig voneinander, im Gegensatz zu Threads, die sich denselben Prozessspeicherplatz teilen, was sich negativ auf Race Conditions und viele andere Thread-bezogene Probleme auswirkt.

• PHP ist meiner Meinung nach auch eng mit dem Web verbunden. Die sofort einsatzbereiten superGlobal-Variablen wie $_GET, $_SERVER usw., die die Arbeit mit dem Web im Allgemeinen einfacher machen.

• Die Sitzungsverwaltung in PHP ist einfach zu gut. Kommt mit der Sprache selbst. Und ist zu einfach, um die Sitzungen zu verwalten.

Abschluss:

• PHP kann ausschließlich für SSR verwendet werden. Und Sitzungsmanagement. Ich kann PHP bei der Erledigung CPU-intensiver Aufgaben nicht vertrauen, da es das nervt. Warum? Es ist eine interpretierte Sprache und auch nicht multithreaded.

• Also verlagere ich alle CPU-intensiven Anrufe auf Go.

• Das Beste aus zwei Welten. PHP für SSR, damit der Client nicht leidet und sich für CPU-intensive Aufgaben entscheidet, weil es Parallelität so gut beherrscht...

Das obige ist der detaillierte Inhalt vonPHP und Go als Tech Stack.. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!