Cet article n'est une réimpression que de la partie technique du blog personnel. Pourquoi avons-nous abandonné Java et adopté Typescript sans serveur -Junks, GC ne peut pas balayer-
De plus, comme je l'ai écrit sur le blog, il existe d'abord une version anglaise en raison de diverses circonstances. J'ai écrit ceci aussi, alors comprenez que ce n'est pas un vol.
\ [Article original ]: Pourquoi nous avons remplacé Java par Typescript pour Serverless dans dev.to
** sans serveur ** est l'une des méthodes de conception les plus populaires de nos jours, et peut-être que de nombreux développeurs commencent à l'appliquer à leurs produits, plus ou moins.
Je suis moi-même complètement fasciné par l'absence de serveur et je n'ai pas envie de retourner moi-même dans le monde désuet de la gestion et de l'exploitation de serveurs et d'intergiciels.
Si votre application est conçue en tenant compte de la mise à l'échelle et de la dispersibilité, les avantages des fonctionnalités traditionnelles des applications serveur seront relativement faibles et les inconvénients du passage au sans serveur ne sont pas si grands. Récemment, lorsque j'ai une consultation sur le design, j'essaie toujours de parler de sans serveur.
Soit dit en passant, sans serveur est très différent de la méthode de développement existante, il est donc nécessaire de ** renouveler les connaissances que nous avons maintenant et de les développer tout en passant en revue la méthode et la pile technologiques existantes **. Lorsqu'il s'agit de réviser, ** le langage à utiliser comme base de développement ** est bien entendu soumis à la pile technologique qui doit être revue.
Comme le titre l'indique, nous avons finalement adopté ** TypeScript ** et l'avons développé et mis à jour pendant environ un an et demi. Et maintenant, un an et demi plus tard, c'est juste mon impression personnelle, mais TypeScript a fait plus que ce que nous attendions.
Donc, dans cet article, j'aimerais expliquer quels étaient les problèmes avec le langage que j'utilisais auparavant, et pourquoi j'ai bénéficié du passage à TypeScript.
Maintenant, avant de parler des raisons pour lesquelles nous avons adopté TypeScript, parlons d'abord des raisons pour lesquelles nous avons dû abandonner Java, le langage très puissant que nous utilisions auparavant.
Maintenant, avant de parler des raisons pour lesquelles nous avons adopté TypeScript, parlons d'abord des raisons pour lesquelles nous avons dû abandonner Java, le langage très puissant que nous utilisions auparavant.
Dans notre service, le côté serveur a été essentiellement écrit uniquement en Java à partir du moment où le service a été établi. Bien entendu, Java présente déjà de nombreux avantages, notamment
Il n'y a pas de fin à la liste.
Cependant, lorsque j'ai expérimenté le code sur AWS Lambda, j'ai réalisé que Java n'était pas très sans serveur.
Les raisons sont les suivantes.
Tous les points ci-dessus sont assez ennuyeux, mais cette fois je voudrais écrire un peu plus sur les problèmes qui étaient particulièrement ennuyeux.
La chose la plus ennuyeuse était la surcharge ** de démarrage à froid ** écrasante. Peut-être que de nombreux développeurs en souffrent également. .. ..
Nous avons utilisé AWS Lambda comme infrastructure informatique, mais AWS Lambda lance un nouveau conteneur chaque fois qu'un utilisateur le demande.
Une fois démarré, il réutilisera ** la même instance de conteneur ** pendant un certain temps, mais au premier démarrage, en plus du runtime Java, le conteneur DI et le conteneur Web utilisés dans le framework seront tous ** Doit être initialisé **.
De plus, ** un conteneur ne peut traiter qu'une seule requête, pas plusieurs requêtes **. (Même si vous regroupez des centaines de threads de requête en interne.)
Cela signifie que si plusieurs utilisateurs envoient des demandes en même temps, Lambda devra lancer un autre conteneur en plus de celui qu'il exécute. Normalement, nous ne pouvons pas prédire à l'avance combien de demandes arriveront en même temps et à quelle heure. En d'autres termes, même si vous créez un mécanisme, il n'est pas possible de mettre tous les Lambda en veille à l'avance.
Cela oblige inévitablement l'utilisateur à attendre de quelques secondes à 10 secondes ou plus, ce qui réduit considérablement la convivialité.
Réalisant que Cold Start était terrible comme ça, nous avons décidé d'abandonner la pile technologique qui avait été écrite au cours des dernières années et de choisir une autre langue.
C'est une histoire embarrassante, mais honnêtement, je n'ai pas décidé en examinant et en comparant toutes les langues prises en charge par Lambda. Mais pour être honnête, je n'avais pas d'autre choix que TypeScript dans la situation.
Tout d'abord, ** j'ai supprimé la langue à saisie dynamique **. Maintenance et maintenance par des développeurs aux compétences disparates sur une longue période. Je ne veux pas vraiment utiliser le typage dynamique car c'est du code étendu.
Par conséquent, ** Python ** et ** Ruby ** étaient hors des options assez tôt.
Comme pour ** C # ** et ** Go **, la plupart des équipes développent actuellement principalement Java, donc si vous utilisez un langage trop éloigné du langage existant, il sera difficile pour les nouveaux développeurs de se joindre. A en juger comme **, il a été mis de côté cette fois.
Bien sûr, je sais que ces deux langues majeures retiennent beaucoup l'attention ces jours-ci, et surtout Golang augmente progressivement sa part. Cependant, nous avons dû déplacer rapidement le développement vers le sans serveur, nous avons donc dû y renoncer, compte tenu de notre propre temps de rattrapage.
C'est pourquoi nous avons commencé à utiliser TypeScript. Quels sont les avantages de TypeScript?
Il n'est pas nécessaire de dire à quel point le langage à typage statique peut apporter des avantages aux projets qui seront exploités et développés sur une longue période, je ne l'écrirai donc pas ici. Ici, je voudrais principalement écrire sur les types de points de TypeScript familiers au développement sans serveur. Les avantages de l'utilisation de TypeScript autre que le typage statique sont énormes,
Je pense que c'était probablement le plus important en termes des avantages d'utiliser TypeScript sans serveur. (Parce que les autres mérites sont presque les mérites de TypeScript lui-même ...)
Comme je l'ai mentionné précédemment, Java a une surcharge très importante pour démarrer le conteneur DI / Web utilisé par la JVM elle-même et le framework. De plus, en raison de la nature de Java, AWS Lambda présente les faiblesses suivantes.
Le multithreading est une fonctionnalité très puissante, et en fait, nous avons résolu de nombreux problèmes de performances grâce à cette fonctionnalité. La JVM elle-même exploite également le multithreading par défaut pour le ramasse-miettes et la compilation JIT pour obtenir cette excellente exécution. (Voir G1GC et [JIT Compile](https://aboullaite.me/understanding-jit-compiler-just -in-time-compilateur /))
Cependant, si vous regardez uniquement le temps de démarrage, vous pouvez voir qu'il faut de 100 millisecondes à plusieurs secondes pour terminer tous les threads utilisés pour l'application. Cette fonction elle-même est une surcharge qui peut être presque ignorée pour les applications exécutées sur EC2 avec l'ancien modèle dit Krasaba, mais elle ne peut jamais être ignorée pour les applications sans serveur exécutées sur FaaS telles que Lambda.
** TypeScript est basé sur NodeJS et est essentiellement un thread unique **. Asynchrone est géré par des files d'attente de travaux, des boucles d'événements, etc., et non par des threads ou des processus séparés.
Par conséquent, la plupart des bibliothèques et des frameworks ne nécessitent pas d'extension de thread au démarrage et nécessitent peu de temps système pour démarrer l'exécution.
En mode sans serveur, l'archivage des paquets du code source est fondamentalement ** petit **.
Au démarrage, le conteneur Lambda télécharge ** la source à partir du compartiment S3 pour le code source géré par AWS et la déploie dans le conteneur. ** **
Le temps de téléchargement depuis S3 est généralement très court, mais quand il s'agit de 100 Mo ou 200 Mo, il ne peut pas être ignoré.
Les packages NodeJS sont fondamentalement plus petits que Java.
Pour être honnête, je n'ai pas étudié et je ne sais pas pourquoi, mais je pense que les raisons suivantes peuvent être liées. (Si vous le savez, faites-le moi savoir dans les commentaires)
En fait, lorsque j'écrivais en Java, je pouvais créer des paquets de ** 200 Mo ** ou plus au maximum, mais après être passé à NodeJS, ce n'est qu'environ ** 35 Mo **.
Cette énorme archive de paquets est en grande partie due à nos tentatives de réutiliser l'ancien code écrit dans Spring, mais en fait, même le code optimisé sans ces frameworks indésirables nécessite absolument 50 Mo. Il est devenu.
Puisque nous sommes également des développeurs Web, nous écrivons également le front-end. Par conséquent, j'avais quelques connaissances en JavaScript et NodeJS.
De l'apogée de jQuery au développement de frameworks modernes comme React / Vue, j'ai supprimé certaines fonctionnalités linguistiques, et je vais comprendre dans une certaine mesure comment écrire du code.
** TypeScript est un langage d'extension JavaScript qui sera éventuellement transpilé en JavaScript. ** **
De nombreuses grammaires et idiomes sont hérités de JavaScript, nous pourrions donc commencer à développer le service en moins de temps.
De plus, ** la plupart des principales bibliothèques NodeJS fournissent les définitions de type nécessaires pour TypeScript **, ce fut donc un grand plaisir de profiter des avantages de l'écosystème NodeJS.
En parlant des tendances technologiques récentes, on ne peut pas parler sans la montée des types fonctionnels. De par leur nature même, les implémentations fonctionnelles contribuent de manière significative à l'écriture de code stable, simple, testable et à faible risque.
Surtout dans le cas d'AWS Lambda, puisque du code qui externalise toujours l'état est requis, l'implémentation fonctionnelle qui isole l'état et les effets secondaires est très compatible et facile à maintenir.
En premier lieu, comme John Resig, le créateur de jQuery, l'a dit dans The Secret of JavaScript Ninja, JavaScript a un support pour la programmation fonctionnelle en premier lieu. Les fonctions sont des objets de première classe en JavaScript, et jQuery est en fait créé dans l'espoir qu'il sera écrit en tant que type de fonction.
Mais d'un autre côté, essayer d'écrire du code fonctionnel dans un langage typé dynamiquement peut parfois être très ennuyeux. Par exemple, le nombre de fonctions qui ne peuvent être exprimées que par des types primitifs est très limité et il est généralement assez dangereux de prendre Object comme valeur de retour ou argument.
Cependant, TypeScript vous permet de spécifier des types pour les arguments et les valeurs de retour.
De plus, les fonctionnalités TypeScript suivantes élargissent la représentation des fonctions que nous écrivons et nous aident à écrire du code plus sûr et plus simple.
TypeScript a de nombreuses autres fonctionnalités qui sont très utiles lorsque vous essayez d'écrire de manière fonctionnelle, mais je ne les énumérerai pas toutes ici. (La plupart d'entre eux sont dérivés de JavaScript)
J'aimerais écrire un article sur les types de fonctions et TypeScript quelque part dans le futur.
Lorsque vous apprendrez la grammaire TypeScript, vous serez étonné de voir comment ** vous pouvez écrire quelque chose de très similaire à Java ou Scala **.
En premier lieu, nous avons accumulé quelques bonnes pratiques de code en Java tout en développant pendant un certain temps en Java. Le savoir-faire accumulé, comme la manière de concevoir des classes et des interfaces, comment utiliser efficacement enum et comment écrire l'API Stream pour améliorer la maintenabilité, était quelque chose qui ne pouvait pas être perdu.
En plus des interfaces et des classes, TypeScript supporte les modificateurs d'accès et en lecture seule (propriétés finales en Java), nous avons donc pu présenter le savoir-faire que nous avions cultivé en Java.
Cela inclut les ** meilleures pratiques et modèles de conception orientés objet **. (Les fonctions orientées et les objets ne sont pas bilatérales, donc je pense qu'il est normal de les utiliser en même temps dans un projet. Personnellement.)
Si nous devions adopter Python ou Ruby, qui a une grammaire légèrement unique, je pense que nous aurions passé beaucoup de temps à décider comment appliquer les pratiques pour écrire du code de meilleure qualité dans ce langage. .. (C'est amusant, je sais, juste le temps ...)
Bien sûr, je n'ai pas copié et collé toute la conception et la logique, mais plutôt réécrit la majeure partie du code. Cependant, je pense qu'il convient de noter que la réécriture a été réalisée dans un délai raisonnable et court avec une qualité raisonnable, même si la partie approximative a été réécrite avec des rayures.
Nous devons encore étudier TypeScript à un niveau qui peut être considéré comme un débutant, mais nous en profitons déjà de toutes nos forces.
Lorsqu'on me le demande maintenant, je me demande si Golang est bon, Micronaut et GraalVM pourraient être intéressants, ou peut-être y avait-il d'autres options, mais je suis très satisfait de TypeScript pour le moment et c'est le meilleur. Je pense que c'est l'une des options.
Bien sûr, le traitement est lent, mais le traitement par lots, le traitement parallèle, le traitement distribué, la conception de flux de travail, la gestion du délai d'expiration de la passerelle API, la cohérence des données, le serveur, etc. J'ai rencontré beaucoup de problèmes causés par Les et TypeScript.
Mais ça a été très amusant de travailler dessus en tant que geek, et c'est déjà la meilleure pratique pour le moment, non? J'ai également trouvé des méthodes. (Je veux écrire ceci dans un article plus tard.)
Si vous travaillez actuellement sur un serveur sans serveur en Java et que vous recherchez un serveur sans serveur, serré ou juste un serveur normal, vous devriez également essayer TypeScript. J'espère que ce sera plus productif que je ne l'imaginais.
Merci pour votre longue relation. Si vous avez des commentaires ou des corrections, n'hésitez pas à nous contacter.