PHP et Go en tant que pile technologique.

Tout d'abord, permettez-moi de commencer par toutes les raisons pour lesquelles je préfère cela aux autres piles technologiques JAVASCRIPT célèbres.

• Je déteste la tendance "Javascript pour tout".. Oui.. Javascript peut faire à peu près tout à ce stade.. BUTT, est-il efficace pour faire ça ?

• Prenons un exemple de tâche très intensive liée au processeur. Il s'agit d'un exemple de code qui simule une tâche gourmande en CPU. Et voyons comment Javascript fonctionne.

Raison 1 : Javascript est nul pour les tâches liées au processeur !

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")

• Alors, qu’est-ce qu’on a ici ? Moi, en tant qu'utilisateur de JAVASCRIPT, je m'attendrais à voir "hello world" imprimé après 1 seconde. Et devinez quoi. Ce n’est pas le cas. Il crache "hello world" au bout de 3 secondes..

• Pourquoi cela arrive-t-il ? Pour comprendre cela, nous devons comprendre comment fonctionne la boucle d'événements dans les navigateurs et les nœuds js. En termes simples, la boucle d'événements vérifie simultanément la pile d'appels et les files d'attente de rappel. La fonction de rappel que nous transmettons dans setTimeout() entrera dans la file d'attente de rappel une fois le minuteur terminé avec 1000 ms.

• Mais devinez quoi... La pile d'appels n'est pas vide lorsque le minuteur a terminé son travail.. Elle est toujours occupée à effectuer la tâche gourmande en CPU de 3 secondes que nous avons écrite (oui.. C'est une simulation.. Pas un programme stupide du monde réel qui prend 3 secondes pour faire ce qu'il a l'intention de faire).

• Ainsi, les fonctions de rappel dans la file d'attente de rappel et la file d'attente des microtâches mourraient de faim.. Mauvaises fonctions de rappel. Ils n'ont la chance d'entrer dans la pile d'appels qu'après 3 secondes. Et c'est la raison pour laquelle nous voyons le "hello world" s'imprimer après 3 secondes même si j'ai spécifié 1000 ms.

Oui. Il s'agit d'une image aléatoire de la boucle d'événements que j'ai téléchargée sur le Web. Cool Image.

Prenons un code Go qui fait exactement la même chose..

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")
}

Ici, le "hello world" s'imprime après 1 seconde. Comment ? Parce que AfterFunc() fonctionne sur sa propre GoRoutine qui n'a rien à voir avec la GoRoutine principale..

Raison 2 : personnellement, je déteste le rendu côté client.

• Parlons de ReactJS. Il pousse les composants javascript vers le client et lui met tellement de choses à la gorge que les clients commencent à s'étrangler..

• Imaginez un PC bas de gamme faisant une requête pour un fichier HTML statique, et vous obtenez un tas de conneries de composants de réaction.. Que ressentirait le client ? Cela devient lent.. Le navigateur doit analyser le javascript, exécuter le DOM virtuel, en générer le HTML.. Et que sais-je encore..

• Le navigateur fait tout le travail que le serveur doit faire..

• Vous vous souvenez du FLUX NATUREL DU WEB ?

• Charger d'abord le HTML, puis charger le javascript ? Pourquoi? Pour réaliser la peinture initiale le plus rapidement possible.. Vous vous souvenez de l'époque où l'on chargeait le javascript dans le pied de page du document HTML ?

• React vient de bouleverser tout le flux.

• Et en conséquence, le client doit regarder un écran blanc vide pendant un bon laps de temps..

Les raisons étant évoquées..

• Je choisis 2 langues qui brillent dans leur propre monde..

Aller

• Ce qui m'a tout de suite impressionné, c'est que Go est un langage compilé et qu'il est typé statiquement. Vous pouvez dire aveuglément que Go est super rapide et beaucoup plus rapide que javascript..

• Il comporte des threads légers intégrés appelés "GoRoutines", qui sont beaucoup plus rapides que les threads réels du système d'exploitation, car les threads Go sont légers.

• Go peut être utilisé pour créer des points de terminaison RESTful ou peut être utilisé pour n'importe quel service backend..

• BUTT, je ne peux pas utiliser Go pour SSR.. PHP brille là-dedans.. Dans ma pile, Go sera fortement utilisé pour les API gourmandes en CPU ou tout service backend.

PHP

• PHP est la meilleure chose que j'ai jamais utilisée pour SSR. Simple et très direct. Crée un processus pour chaque client. Cela le rend un peu lent. Mais ces processus sont néanmoins indépendants les uns des autres, contrairement aux threads qui partagent le même espace mémoire de processus, ce qui est mauvais pour les conditions de concurrence et de nombreux autres problèmes liés aux threads..

• PHP est également étroitement couplé au Web à mon avis. Les variables superGlobales prêtes à l'emploi comme $_GET, $_SERVER, etc., qui facilitent le travail avec le Web en général..

• La gestion des sessions en PHP est tout simplement trop bonne.. Livré avec le langage lui-même.. Et il est trop facile de gérer les sessions..

Conclusion:

• PHP peut être utilisé uniquement pour le SSR. Et la gestion des sessions. Je ne peux pas faire confiance à PHP pour effectuer des tâches gourmandes en CPU, car cela craint. Pourquoi? C'est un langage interprété et ce n'est pas non plus multithread..

• Donc, je décharge tous les appels gourmands en CPU vers Go.

• Le meilleur des deux mondes.. PHP pour SSR, afin que le client ne souffre pas et n'opte pas pour des tâches gourmandes en CPU car il peut si bien faire de la concurrence...

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!