Wie Sie sich heute der Fullstack-Entwicklung nähern, wenn Sie zehn Jahre geschlafen haben

Als Einführung ...

Grundbegriffe

• Aktualisieren Sie zunächst Ihr Wissen über die modernen Standards für das Layout (HTML5, CSS3 und das ist alles). Es wird auch nützlich sein, über die Entwicklung von ECMA Script zu lesen (JS ist tatsächlich eine Implementierung dieses speziellen Standards) und Ihr Wissen über JSON und JWT aufzufrischen.
• Ein objektorientierter Ansatz zur Programmierung . Ja Ja! Viele, die zu verstehen scheinen, worum es geht, sind sich der Idee nicht voll bewusst, obwohl sie vor 50 Jahren erschien. Daher ist es ratsam, sich im Zweifelsfall erneut vertraut zu machen.
• Versionskontrollsysteme . Dies ist ein absoluter Fehler, sie heute zu kennen, ist einfach für jeden notwendig, der an der Entwicklung einer Software arbeitet. Selbst wenn Sie alleine arbeiten, sind Versionskontrollsysteme sehr nützlich, und selbst ein Team ohne sie ist die Hölle. Bisher verwendeten sie hauptsächlich SVN oder CVS, einfach weil sie fast keine ernsthaften Konkurrenten hatten. Jetzt ist der De-facto-Standard GIT (dank Linus Torvalds). Ich empfehle, mit dem Studium der Konsolenversion (auch für Windows) zu beginnen. Es wird einige Tage dauern, aber wenn Sie auf die Idee kommen, werden Sie alle Chips (wie z. B. den Git-Flow) sehr schnell verstehen und dort können Sie einen GUI-Client platzieren . Und Sie können wirklich cool werden, wenn Sie beispielsweise Git-Hooks beherrschen und das Senden von Daten an den Battle Server konfigurieren, wenn Sie sich für den Hauptzweig des Projekt-Repositorys engagieren.
• Das Konzept von MVC (es wäre keine Übertreibung zu sagen, dass in fast allen modernen Web-Software nach diesem Prinzip funktioniert, so dass Sie auf jeden Fall lesen müssen).
• RestAPI- Konzept.
• Typen, Funktionen und Unterschiede von Datenbanken und SQL-Grundlagen (ich sage nicht, dass Sie dies direkt lernen müssen, aber Sie müssen auf jeden Fall eine Präsentation haben, um zumindest die einfachsten Abfragen zu stellen). Lesen Sie mehr über NoSQL-Datenbanken, insbesondere MongoDB und Redis.
• BEM- Methoden. Ich bin kein Befürworter dieses Ansatzes, aber viele arbeiten mit seiner Verwendung, um zu verstehen, was es ratsam ist, zumindest kurz zu lesen.
• Entwicklungsmethoden von Agile und Scrum (es gibt nichts besonders Kompliziertes, höchstwahrscheinlich für die allgemeine Entwicklung).
• Das Konzept der Single Page Application (SPA) ist nicht immer anwendbar, wird jedoch aus irgendeinem Grund auch für sehr umfangreiche Projekte zunehmend verwendet. Auf jeden Fall lesen.
• Lesen Sie mehr über Web Sockets - eine Technologie, mit der Sie eine interaktive Verbindung zwischen einem Client (Browser) und einem Server für Echtzeitnachrichten herstellen können. Mit Web-Sockets können Sie im Gegensatz zu HTTP mit einem bidirektionalen Datenstrom arbeiten. Ich schlage vor, es als eine neue Generation von AJAX zu betrachten. Der Hauptvorteil ist das Fehlen der Notwendigkeit, ständig neue Daten vom Server anzufordern. Bei Bedarf sendet der Server selbst die Daten und der Browser empfängt sie.
• Ein weiterer Standard, der die Front-End-Entwicklung in naher Zukunft wahrscheinlich erheblich verändern wird, sind Webkomponenten . Ein sehr mächtiges Werkzeug, das sich auf jeden Fall als nützlich für Sie erweisen wird, obwohl ich in diesem Artikel nicht darauf achten werde.
• XPath ist eine Abfragesprache für ein DOM-Dokument. Es ist unwahrscheinlich, dass es für Sie nützlich sein wird, da CSS-Selektoren in den allermeisten Fällen bequemer sind, aber es ist nützlich, über seine Existenz Bescheid zu wissen. Jetzt wird es hauptsächlich zum Testen oder Parsen großer Datenmengen verwendet.
• Einer der Hauptunterschiede gegenüber der Entwicklung vor einem Dutzend Jahren - heute ist es allgemein anerkannt, das sogenannte zu verwenden. Paketmanager (Abhängigkeitsmanager), die aus der UNIX-Welt stammen. Ich werde unten auf einige von ihnen näher eingehen. Die Hauptidee besteht darin, dem Programmierer die Sorge um die Beobachtung von Abhängigkeiten und die Aktualisierung der verwendeten Bibliotheken und Frameworks von den Schultern zu nehmen. Früher mussten Sie zum Starten eines Projekts alle erforderlichen Dateien und Bibliotheken manuell an die richtigen Stellen kopieren, alle Pfade registrieren, sicherstellen, dass sie miteinander kompatibel sind usw. Jetzt erfolgt dies alles mit ein paar Befehlen in der Konsole (ja, ohne Konsole) nirgendwo, leider).
• Precompiler Es mag seltsam klingen, da es sich um interpretierte Sprachen handelt, aber ja, sehr oft verwenden wir separate Programme, mit denen Sie beispielsweise alle in einer Datei verwendeten Stile sammeln können, bevor Sie sie in die Produktion hochladen, und alle möglichen praktischen Dinge in Ihrem Code verwenden können. die nicht im Standard enthalten sind (z. B. Variablen in CSS). Precompiler sind im Front-End besonders beliebt - da das Backend am häufigsten vollwertige OOP-Sprachen verwendet, sind Precompiler dort nicht so verbreitet und werden hauptsächlich zum Beschleunigen und Zwischenspeichern verwendet (z. B. PHP Zend OPcache).
• Um die Entwicklungsbereitstellung zu vereinfachen, ist es heute üblich, das sogenannte zu verwenden Container (Docker, Kubernetes). Dies ist ein relativ neues Konzept in der modernen Entwicklung, ich werde es nicht im Detail betrachten, aber ich muss eine Idee haben - die Technologie ist sehr leistungsfähig und definitiv nützlich.
• Testen ist ein separates großes Thema. Meistens bedeutet dies das sogenannte. Unit-Test. Das Wesentliche der Idee ist anhand eines einfachen Beispiels leicht zu verstehen. Wenn Sie einen Test erstellen, schreiben Sie eine Art Wrapper, der eine Ihrer Funktionen ausführt und das erwartete Ergebnis überprüft. Wenn Sie dann etwas in einer anderen Funktion ändern, von der die erste Funktion abhängt, um zu überprüfen, ob durch die Änderung nichts beschädigt wurde, müssen Sie nur die zuvor erstellten Tests ausführen. Ich hoffe, es ist klar, wie nützlich dies in einem großen Projekt sein kann.

• Die allererste und einfachste Option besteht darin, dass der Webserver die Anforderung analysiert und einfach eine HTML-Datei ausgibt, die dieser Anforderung entspricht. Maximal kann eine Art SSI verwendet werden. Tatsächlich ist dies nur eine klassische statische Site, und das Backend ist in diesem Fall der Webserver selbst. Für ein Projekt, in dem möglicherweise viele Seiten vorhanden sind, ist dieser Ansatz natürlich katastrophal unpraktisch. Wenn Sie etwas ändern müssen, müssen Sie alle Dateien bearbeiten. Es ist auch offensichtlich, dass nichts als statische Sites hier praktisch unmöglich zu implementieren ist. Jetzt wird dies für einige sehr einfache Zielseiten maximal genutzt, und dann wird die Entwicklung des Frontends für diese noch immer hauptsächlich mit Hilfe moderner js-Frameworks durchgeführt, und in den meisten Fällen werden sie über die Node.js-Funktionalität verwendet.
• Die Entwicklung der statischen Version ist die Verwendung interpretierter Sprachen auf der Serverseite. Dann wurde es möglich, Vorlagen in einer der interpretierten Sprachen zu schreiben, in die Daten je nach Anforderung eingesetzt werden, und es wurde auch möglich, Daten nicht in Dateien, sondern in der Datenbank zu speichern. Wir können davon ausgehen, dass es ab diesem Moment eine klare Trennung gibt:
  
  1. Eigentlich der Webserver selbst. Dies ist nicht mehr unbedingt eine monolithische Anwendung, beispielsweise eine häufige Option - wenn Nginx als Load Balancer fungiert und Apache die Anforderungen selbst verarbeitet. Obwohl es viele Optionen geben kann (danke für die Klarstellung von prijutme4ty ).
  2. Die Sprache und das Framework in dieser Sprache, die zur Verarbeitung der Anfrage und zum Marschieren per URL verwendet werden. Vielleicht wäre es kein Fehler zu sagen, dass im Kontext der Fullstack-Entwicklung das Konzept des „Backends“ nur dieser Schicht meistens bedeutet, obwohl streng genommen jede Serversoftware, die den Webserver bereitstellt, natürlich auch ein Backend ist. Es ist wichtig, dass die Sprache und der Rahmen für das Backend nahezu beliebig sein können. Beispielsweise kann im Fall von Ruby und Ruby on Rails der integrierte ERB als Vorlagen-Engine verwendet werden, im Fall von PHP und Laravel wird Blade am häufigsten als Vorlagen-Engine verwendet und so weiter.
  3. Code, der direkt auf dem Client ausgeführt wird, wird üblicherweise als Frontend bezeichnet. Hier kommt es tatsächlich auf JS an.
  
  Dieser Ansatz war lange Zeit der wichtigste und einzige in der Webentwicklung, bis sich Cloud-Technologien zu entwickeln begannen und das Konzept des SPA auftauchte.
• Als sich Cloud Computing zu entwickeln begann, erschienen verschiedene Modelle ihrer Verwendung (SaaS, PaaS, IaaS). Unter ihnen möchte ich das sogenannte erwähnen. AWS Serverless-Ansatz. Unter dem Strich wird der Webserver aus dem vorherigen Absatz durch ein spezielles Framework ersetzt, über das die Backend-Anwendung mit der Cloud interagiert. Wolken entwickeln sich sprunghaft, es erscheinen viele neue Technologien und Ansätze für ihre Verwendung, daher ist es nicht möglich, alles kurz zu beschreiben. Wenn Sie sich für diesen Bereich interessieren, können Sie die meisten derzeit verwendeten Cloud-Technologien mit Sortierung nach Kategorien hier sehen: Landschaft.cncf.io (danke an KonstantinSpb ).
  
• Mit der Entwicklung des SPA-Konzepts und dem Aufkommen von HTML-Komponenten, die mit JS gerendert werden, trat das Problem auf, dass die Anzeige zu lange dauerte. Es kann eine Weile dauern, bis JavaScript auf dem Client geladen und gerendert ist. In dieser Hinsicht gibt es einen anderen Ansatz für die HTML-Generierung, der in der Vergangenheit normalerweise mit SPA-Anwendungen verbunden ist - Server Side Rendering (SSR). Unter dem Strich können wir das erste Komponenten-Rendering in HTML auf dem Server ausführen, es dann zusammen mit demselben Code, der diesen HTML-Code generiert hat, an den Client weitergeben und dann nicht jedes Mal den gesamten Anwendungscode über das Netzwerk senden, sondern einfach die erforderlichen Komponenten zeichnen Sofort im Browser werden nur die Daten übertragen, die zum Ändern des Systemstatus erforderlich sind (dh REST). Sie müssen verstehen, dass sie dies in einigen Fällen möglicherweise nicht tun, indem sie das System in unabhängige Funktionsblöcke aufteilen (z. B. Gruppierung nach Formularen, von denen jedes mit seinem eigenen Bereich des Systems arbeitet). Dann ist dies kein SPA mehr im klassischen Sinne. In diesem Fall werden die Komponenten einmal gerendert, bevor sie mit einer JS-Vorlagen-Engine direkt auf dem Server gesendet werden. Konzeptionell unterscheidet sich dies nicht von der Verwendung der Vorlagen-Engine in einer anderen Backend-Sprache und im Wesentlichen dem Rendern von JS HTML wird weiterhin auf der Serverseite verwendet, dies ist keine SSR mehr, da dieses Konzept in der Vergangenheit genau im Kontext von SPA verwendet wurde. Zur Verdeutlichung dieses Moments dank der Genossen staticlab , napa3um und justboris .

Backend

• Java
• .NET
• Python
• Node.js (mehrdeutig hier, aber dazu später mehr),
• Ruby on Rails
• Und natürlich PHP

Über Python ...

Diejenigen, die ihn aus irgendeinem Grund immer noch nicht kennen und vielleicht sogar umgehen, möchte ich dennoch raten, diese Sprache genauer zu betrachten. Ich selbst wollte es lange nicht studieren, und der Grund war nicht der vieler („Puh, dort ist alles eingerückt“), aber weil sie die Vorteile von Python bieten (verzeihen Sie mir, Leute, die „Python“ sagen), nennen sie normalerweise Lakonismus Sprache.

Oft zitieren sie im Geiste: „In C werden 100 Codezeilen benötigt, in einem Bordell 10“. Diese "Einfachheit" machte Angst, besonders nach C ++ und dem geliebten C #. Es schien, dass die Sprache eher für „Hausfrauen“ und Menschen gedacht war, die nicht wussten, wie man in normalen Sprachen mit normaler Typisierung programmiert, und tatsächlich ist die Sprache nur für Skripte. Ich habe mich noch nie so geirrt! :) Die Sprache ist sehr mächtig, unglaublich praktisch und kann in vielen Bereichen angewendet werden. Ich kenne keine einzige Person, die von PHP zu Python gewechselt ist und danach wieder zu PHP zurückkehren möchte. Das ist alles, wozu ich führe: Python ist eine großartige Sprache, um ein Backend darauf zu erstellen.

Nun, direkt zu den Frameworks ... Zuerst müssen Sie entscheiden: Welchen Server müssen blockiert oder nicht blockiert werden? Jeder von ihnen hat Vor- und Nachteile. Ein nicht blockierender Server wird am häufigsten für Web-Sockets verwendet. Auf diesem Server können Sie jedoch reguläre Sites schreiben, die gleichzeitig eine große Anzahl von Verbindungen verarbeiten können. Wenn Sie jedoch mit solchen Servern arbeiten, müssen Sie berücksichtigen, dass sich alle Verbindungen in einem „gemeinsamen Zyklus“ drehen und das Blockieren dieses „Zyklus“ alle Verbindungen vollständig blockiert. In dieser Hinsicht sollten alle verwendeten Bibliotheken nicht blockieren. Unter den nicht blockierenden Frameworks würde ich heute die Verwendung von aiohttp empfehlen, es gibt andere sehr beliebte wie Tornado, aber alle sind aiohttp unterlegen. In Bezug auf das Blockierungs-Framework fällt Django hier auf. Es ist für Leute geeignet, die alles in einer Flasche und vorzugsweise sofort haben möchten. Django enthält bereits eine Vorlagen-Engine, ORM und viele andere praktische Bibliotheken. Wenn Sie jedoch wie ich Bibliotheken für die Aufgabe auswählen möchten, empfehle ich Ihnen, Flask zu verwenden, und alle anderen Bibliotheken sind bereits angepasst. Die Vorlagen-Engine wird am häufigsten von Jinja2 verwendet. Es handelt sich um eine recht praktische und häufig verwendete Vorlagen-Engine, mit der Sie bei Fragen die Antwort sehr schnell googeln können. Was ORM betrifft, so herrscht in der Python-Welt die SQLalchemie. Dies, wie der Schöpfer von Peewee (ein Konkurrent von sqlalchemy) schreibt: "SQLAlchemy ist der Goldstandard für ORM in der Python-Welt" - und ich stimme ihm vollkommen zu. Es ist ein vielseitiges und leistungsstarkes Werkzeug. Aber Sie müssen für alles bezahlen, in diesem Fall müssen Sie die Komplexität dieses Frameworks „bezahlen“. Sie können jedoch sehr schnell mit ihm arbeiten und sich mit den bereits vorhandenen Schwierigkeiten befassen.

Es gibt viele andere nützliche Bibliotheken, die für die Arbeit mit dem Web nützlich sind, wie z. B. wtforms, beautifulsoup, Pillow usw., aber hier hängt alles vom spezifischen Projekt und den Aufgaben ab, denen sich der Entwickler gegenübersieht.

Ich würde auch die Anforderungsbibliothek hinzufügen (es hat mir direkt sehr gut gefallen). Schauen Sie sich für ein Cloudless Serverless Backend die Frameworks Chalice und SAM an. Pipenv, Black und Flake8 gehören uns natürlich.

PHP

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

PHP-

• 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());

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-

• WENIGER ist eine verschachtelte Metasprache: Gültiges CSS ist ein gültiges WENIGER-Programm mit ähnlicher Semantik. LESS ist so konzipiert, dass es CSS so nahe wie möglich kommt, sodass sie dieselbe Syntax haben. Infolgedessen kann vorhandenes CSS als WENIGER Code verwendet werden.
• SASS ist eine CSS-basierte Metasprache, mit der die CSS-Code-Abstraktion verbessert und das Kaskadieren von Stylesheet-Dateien vereinfacht werden soll.

• SASS — , , ;
• SCSS (Sassy CSS) — , CSS.

Node.js

1. ( ) .
2. « » JS-.
3. , .
4. , JS- , SASS/LESS, ( , ) HTML (JS CSS).

Node.js

• 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 - um zu wissen, was in Top- und nicht sehr Unternehmen verwendet wird.
Libhunt.com ist eine ausgezeichnete kategorisierte Liste einer Vielzahl von Technologien mit vergleichenden Statistiken.