Comment aborder le développement fullstack aujourd'hui si vous avez dormi dix ans

En guise d'introduction ...

Concepts de base

• Tout d'abord, mettez à jour vos connaissances sur les normes modernes utilisées pour la mise en page (HTML5, CSS3 et c'est tout). Il sera également utile de lire sur l'évolution du script ECMA (JS, en fait, est une implémentation de cette norme particulière), et de rafraîchir vos connaissances sur JSON et JWT.
• Une approche orientée objet de la programmation . Oui oui Beaucoup de ceux qui semblent comprendre de quoi il s'agit ne sont pas pleinement conscients de l'idée, bien qu'elle soit apparue il y a 50 ans. Par conséquent, il est conseillé de se familiariser à nouveau, au moins un peu de doute.
• Systèmes de contrôle de version . C'est une faute absolue, les connaître aujourd'hui est tout simplement nécessaire pour tous ceux qui travaillent au développement de tout logiciel. Même si vous travaillez seul, les systèmes de contrôle de version sont très utiles, et même une équipe sans eux est un enfer. Auparavant, ils utilisaient principalement SVN ou CVS pour cela, simplement parce qu'ils n'avaient presque pas de concurrents sérieux. Désormais, la norme de facto est GIT (grâce à Linus Torvalds). Je recommande de commencer par étudier la version console (même pour Windows), cela prendra quelques jours, mais quand vous aurez l'idée, vous comprendrez très rapidement toutes les puces (comme git flow), et là vous pouvez mettre un client GUI . Et vous pouvez devenir vraiment cool, par exemple, si vous maîtrisez les hooks git et configurez l'envoi de données au serveur de combat lorsque vous vous engagez dans la branche principale du référentiel de projet.
• Le concept de MVC (il ne serait pas exagéré de dire que dans presque tous les logiciels Web modernes fonctionnent sur ce principe, vous devrez certainement lire).
• Concept RestAPI .
• Types, fonctionnalités et différences des bases de données et des principes fondamentaux de SQL (je ne dis pas que vous devez apprendre cela directement, mais vous devez absolument avoir une présentation, jusqu'à faire au moins les requêtes les plus simples). Découvrez les bases de données NoSQL, en particulier MongoDB et Redis.
• Méthodologies BEM . Je ne suis pas partisan de cette approche, mais beaucoup travaillent avec son utilisation pour comprendre ce qu'il est conseillé de lire au moins brièvement.
• Méthodologies de développement d' Agile et Scrum (il n'y a rien de particulièrement compliqué, très probablement pour le développement général).
• Le concept d' application de page unique (SPA) n'est pas toujours applicable, mais pour une raison quelconque, il est de plus en plus utilisé même pour des projets très volumineux. A lire absolument.
• En savoir plus sur Web Sockets - une technologie qui vous permet de créer une connexion interactive entre un client (navigateur) et un serveur pour la messagerie en temps réel. Les sockets Web, contrairement à HTTP, vous permettent de travailler avec un flux de données bidirectionnel. Je propose de le considérer comme une nouvelle génération d'AJAX. Le principal avantage est l'absence de la nécessité de demander constamment de nouvelles données au serveur. Si nécessaire, le serveur lui-même enverra les données et le navigateur les recevra.
• Les composants Web sont une autre norme susceptible de modifier considérablement le développement frontal dans un avenir proche. Un outil très puissant et il vous sera certainement utile, bien que dans cet article je n'y prête pas attention.
• XPath est un langage de requête pour un document DOM. Il est peu probable qu'il vous soit utile, car dans la grande majorité des cas, les sélecteurs CSS sont plus pratiques, mais il est utile de connaître son existence. Maintenant, il est principalement utilisé pour tester ou analyser de grandes quantités de données.
• L'une des principales différences par rapport au développement d'il y a une douzaine d'années - il est désormais d'usage d'utiliser ce que l'on appelle. les gestionnaires de packages ( gestionnaires de dépendances) issus du monde UNIX. J'en parlerai plus en détail ci-dessous. L'idée principale est de supprimer des épaules du programmeur le souci d'observer les dépendances et de mettre à jour les bibliothèques et frameworks utilisés. Auparavant, pour démarrer un projet, vous deviez copier manuellement tous les fichiers et bibliothèques nécessaires aux bons endroits, enregistrer tous les chemins, vous assurer qu'ils sont compatibles les uns avec les autres, etc., maintenant tout cela se fait avec quelques commandes dans la console (oui, sans la console nulle part, hélas).
• Précompilateurs Cela peut sembler étrange, car nous parlons de langages interprétés, mais oui, très souvent, nous utilisons des programmes distincts qui permettent, par exemple, de collecter tous les styles utilisés dans un fichier avant de les mettre en production, et également d'utiliser toutes sortes de choses pratiques dans votre code, qui ne sont pas dans la norme (par exemple, les variables en CSS). Les précompilateurs sont particulièrement populaires dans le front-end - puisque le backend utilise le plus souvent des langages OOP à part entière, les précompilateurs n'y sont pas si courants et sont principalement utilisés pour l'accélération et la mise en cache (par exemple, PHP Zend OPcache).
• Pour simplifier le déploiement du développement, il est désormais d'usage d'utiliser ce que l'on appelle conteneurs (Docker, Kubernetes). Il s'agit d'un concept relativement nouveau dans le développement moderne, je ne l'examinerai pas en détail, mais j'ai besoin d'avoir une idée - la technologie est très puissante et certainement utile.
• Les tests sont un grand sujet distinct. Le plus souvent, cela signifie ce qu'on appelle. tests unitaires. L'essence de l'idée est facile à comprendre avec un exemple simple. Lors de la création d'un test, vous écrivez une sorte de wrapper qui exécutera l'une de vos fonctions et vérifiera le résultat attendu. Ensuite, lorsque vous modifiez quelque chose dans une autre fonction, dont dépend la première fonction, pour vérifier que la modification n'a rien cassé, il vous suffit d'exécuter les tests créés précédemment. J'espère qu'il est clair à quel point cela peut être utile dans un grand projet.

• La toute première et la plus simple option consiste à ce que le serveur Web analyse la demande et émette simplement un fichier HTML correspondant à cette demande. Maximum, une sorte de SSI peut être utilisée. En fait, ce n'est qu'un site statique classique, et le backend dans ce cas est le serveur web lui-même. De toute évidence, pour un projet dans lequel il peut y avoir plusieurs pages, cette approche est désagréablement gênante - si vous devez changer quoi que ce soit, vous devrez apporter des modifications dans tous les fichiers. Il est également évident que rien que des sites statiques est pratiquement impossible à mettre en œuvre ici. Maintenant, cela est utilisé au maximum pour certaines pages de destination très simples, puis le développement du frontend pour elles est toujours en cours, principalement à l'aide de frameworks js modernes, et dans la plupart des cas, ils sont utilisés via la fonctionnalité Node.js.
• Le développement de la version statique est l'utilisation de langages interprétés côté serveur. Ensuite, il est devenu possible d'écrire des modèles dans l'une des langues interprétées dans lesquelles les données sont substituées en fonction de la demande, et il est également devenu possible de stocker des données non pas dans des fichiers, mais dans la base de données. Nous pouvons supposer qu'à partir de ce moment, il y a une séparation claire:
  
  1. En fait, le serveur Web lui-même. Maintenant, ce n'est plus nécessairement une application monolithique, par exemple, une option courante - lorsque Nginx agit comme un équilibreur de charge et qu'Apache traite les demandes elles-mêmes. Bien qu'il puisse y avoir de nombreuses options (merci de clarifier prijutme4ty ).
  2. Le langage et le cadre dans ce langage, qui sont utilisés pour traiter la demande et marcher par URL. Ce ne serait peut-être pas une erreur de dire que dans le contexte du développement fullstack, le concept de «backend» est juste cette couche le plus souvent et est destiné, bien qu'à proprement parler, à tous les logiciels serveur qui prennent en charge le serveur web est, bien sûr, également un backend. Il est important que le langage et le cadre du backend puissent être presque tous. Par exemple, dans le cas de Ruby et Ruby on Rails, l'ERB intégré peut être utilisé comme moteur de modèle, dans le cas de PHP et de Laravel, Blade est le plus souvent utilisé comme moteur de modèle, etc.
  3. Le code qui s'exécute directement sur le client est ce qu'on appelle communément un frontend. Ici, en fait, cela revient à JS.
  
  Pendant longtemps, cette approche a été la principale et la seule dans le développement Web, jusqu'à ce que les technologies cloud commencent à se développer et que le concept de SPA apparaisse.
• Lorsque le cloud computing a commencé à se développer, différents modèles de leur utilisation sont apparus (SaaS, PaaS, IaaS). Parmi eux, je voudrais noter le soi-disant Approche sans serveur AWS. L'essentiel est que le serveur Web du paragraphe précédent est remplacé par un cadre spécial à travers lequel l'application principale interagit avec le cloud. Les nuages ​​se développent à pas de géant, de nombreuses nouvelles technologies et approches de leur utilisation apparaissent, il n'est donc pas possible de tout décrire brièvement. Si vous êtes intéressé par ce domaine, vous pouvez voir la plupart des technologies cloud actuellement utilisées avec un tri par catégories ici: landscape.cncf.io (merci à KonstantinSpb ).
  
• Avec le développement du concept SPA et l'émergence de composants HTML rendus à l'aide de JS, le problème est apparu de s'afficher trop longtemps - le chargement et le rendu de JavaScript sur le client peuvent prendre un certain temps. À cet égard, il existe une autre approche de la génération HTML, qui est généralement généralement associée aux applications SPA: le rendu côté serveur (SSR). L'essentiel est que nous pouvons exécuter le premier rendu des composants en HTML sur le serveur, puis le donner au client, avec le même code qui a généré ce HTML, puis ne pas envoyer le code d'application entier sur le réseau à chaque fois, mais simplement dessiner les composants nécessaires immédiatement dans le navigateur, en ne transmettant que les données nécessaires pour changer l'état du système (c'est-à-dire REST). Vous devez comprendre que dans certains cas, ils ne peuvent pas le faire en décomposant le système en blocs fonctionnels indépendants (par exemple, le regroupement par formulaires, chacun fonctionnant avec sa propre zone du système), alors ce ne sera plus SPA au sens classique. Dans ce cas, les composants sont rendus une fois avant d'être envoyés à l'aide d'un moteur de modèle JS directement sur le serveur - puis, conceptuellement, cela n'est pas différent de l'utilisation du moteur de modèle dans tout autre langage principal, et, bien que, essentiellement, le rendu à partir de JS Le HTML se produira toujours côté serveur, ce n'est plus un SSR, car ce concept a historiquement été utilisé précisément dans le contexte du SPA. Pour une clarification de ce moment, merci aux camarades staticlab , napa3um et justboris .

Backend

• Java
• .NET
• Python
• Node.js (ambigu ici, mais plus à ce sujet plus tard),
• Ruby on Rails
• Et bien sûr PHP

À propos de Python ...

Ceux qui, pour une raison quelconque, ne le connaissent pas encore, et peut-être même le contournent, je voudrais néanmoins conseiller de mieux regarder cette langue. Moi-même, je ne voulais pas l'étudier depuis très longtemps, et la raison n'était pas comme celle de beaucoup ("ouf, tout y est indenté"), mais parce qu'ils donnent les avantages du python (pardonnez-moi les gens qui disent "Python"), ils appellent généralement le laconicisme la langue.

Souvent, ils citent dans l'esprit: «qu'en C, il faut 100 lignes de code, dans un bordel, il en faut 10». Cette "simplicité" a fait peur, surtout après C ++ et C # bien-aimé. Il semblait que la langue était plus pour les «femmes au foyer» et les personnes qui ne savaient pas comment programmer dans des langues normales avec une typification normale, et en effet la langue est uniquement pour les scripts. Je ne me suis jamais trompé! :) La langue est très puissante, incroyablement pratique, qui peut être appliquée dans de nombreux domaines. Je ne connais pas une seule personne qui soit passée de PHP à python, et qui après cela voudrait encore revenir à PHP. C’est tout ce que je veux dire: python est un excellent langage pour créer un backend dessus.

Eh bien, maintenant directement sur les frameworks ... Vous devez d'abord décider: quel serveur avons-nous besoin de bloquer ou de ne pas bloquer. Chacun a ses avantages et ses inconvénients. Un serveur non bloquant est le plus souvent utilisé pour les sockets Web, mais vous pouvez y écrire des sites réguliers pouvant traiter simultanément un grand nombre de connexions. Mais lorsque vous travaillez avec de tels serveurs, vous devez vous rappeler que toutes les connexions tournent dans un «cycle commun» et bloquer ce «cycle» bloquera complètement toutes les connexions, à cet égard, toutes les bibliothèques utilisées doivent être non bloquantes. Parmi les frameworks non bloquants, aujourd'hui je recommanderais d'utiliser aiohttp, il y en a d'autres assez populaires comme Tornado, mais ils sont tous inférieurs à aiohttp. Quant au framework de blocage, Django se démarque ici. Il convient aux personnes qui aiment que tout soit dans une seule bouteille et de préférence immédiatement. Django déjà prêt à l'emploi comprend un moteur de modèle, ORM et de nombreuses autres bibliothèques pratiques. Mais si vous, comme moi, souhaitez choisir des bibliothèques pour la tâche, je vous conseille d'utiliser Flask, et toutes les autres bibliothèques sont déjà personnalisées. Le moteur de modèle est le plus souvent utilisé par Jinja2, c'est un moteur de modèle assez pratique et commun, avec lequel si vous avez des questions, vous pouvez google la réponse très rapidement. Quant à ORM, sqlalchemy règne dans le monde python. Ceci, comme l'écrit le créateur de peewee (un concurrent de sqlalchemy): «SQLAlchemy est l'étalon-or pour ORM dans le monde Python» - et je suis entièrement d'accord avec lui. C'est un outil polyvalent et puissant. Mais vous devez tout payer, dans ce cas, vous devez «payer» la complexité de ce cadre. Cependant, vous pouvez commencer à travailler avec lui très rapidement et vous plonger dans les difficultés déjà en cours.

Il existe de nombreuses autres bibliothèques utiles utiles pour travailler avec le Web, telles que wtforms, beautifulsoup, Pillow, etc., mais ici tout dépend du projet spécifique et des tâches auxquelles le développeur est confronté.

J'ajouterais également la bibliothèque de requêtes (je l'ai vraiment aimé directement). Pour un backend sans serveur sans cloud, regardez les frameworks Chalice et SAM. Bien sûr, pipenv, black et flake8 sont les nôtres.

Php

<?php
function test($param){}
test();
?>

Cadres PHP modernes

• Laravel — . , « »: «Blade» ( ), Eloquent ORM ( MVC), PHP include, ( ), , Composer Laravel. . , , . — , . , — Symfony, .
• Symfony — , , . ORM-: Propel Doctrine.
• Zend — , . (enterprise). , Zend PHP, , , PHP Zend Engine.
• Yii — , (, , , . tnsaturday ). Yii . , Sphinx. «» — Gii, .
• CodeIgniter — , . , ( SQL), . .
• , , . , , . Kohana(RIP) — (Koseven). CodeIgniter, PHP5. Kohana , - PHP7 — Koseven. ORM, Minion Cron-, , ( Blade SCSS). - Laravel.

Frontend

<script type="text/javascript" src="/jquery.js"></script>

<script type="text/javascript">
console.log($); // function n() -    

//           $,
// , ,      
var $ = 'Not jquery';
console.log($); // Not jquery
</script>

//         
<script type="text/javascript" src="/new.js"></script>
//          $  jquery,
//           

var moment = require('moment');
console.log("Hello from JavaScript!");
console.log(moment().startOf('day').fromNow());

Framework Javascript

• React — , , , SPA .. «» JSX, JS. , , , «» ( , , ). , Redux (Redux , «» Flux). React Facebook.
• Angular — , , «» SPA, . , MVC, , , , . , . 2.0. — AngularJS Angular ( ), .
• Vue — . , , . , React — React DOM, JSX. , React Backbone, , , , (Vuex), . , , , - .

CSS-

• LESS est un métalangage imbriqué: un CSS valide sera un programme LESS valide avec une sémantique similaire. LESS est conçu pour être aussi proche que possible de CSS, ils ont donc la même syntaxe. Par conséquent, le CSS existant peut être utilisé en tant que code MOINS.
• SASS est un métalangage basé sur CSS conçu pour augmenter le niveau d'abstraction du code CSS et simplifier les fichiers de feuilles de style en cascade.

• SASS - plus concis, caractérisé par l'absence d'accolades, les éléments imbriqués sont mis en œuvre à l'aide de retraits;
• SCSS (Sassy CSS) - utilise des accolades, tout comme CSS lui-même.

Node.js

1. Le client envoie la requête au serveur (qui est implémentée sur le nœud) sous la forme de l'adresse de la page demandée.
2. Noda analyse la demande et la transmet au "point d'entrée" de votre application JS.
3. L'application analyse l'adresse demandée et forme la page souhaitée à partir des composants décrits à l'aide du moteur de modèle du framework utilisé.
4. , JS- , SASS/LESS, ( , ) HTML (JS CSS).

Quelques packages Node.js populaires pour les développeurs

• Babel — JS «» ( ..). , . .
• Grunt — (, , , , ). , Gruntfile.
• Node.JS: Webpack Browserify. Webpack NPM, , Bower Gulp/Grunt.
• Yarn — , NPM, , . package.json , NPM.
• Bower — JS CSS . , NPM, . , , , — Bower , Yarn Webpack.
• Jade — HTML, , JS. , . — , . , JS- , , Jade .

Stackshare.io - pour être au courant de ce qui est utilisé dans les grandes entreprises et pas très.
Libhunt.com est une excellente liste catégorisée d'un grand nombre de technologies avec des statistiques comparatives.