Cómo abordar el desarrollo de pila completa hoy si dormiste diez años

Como introducción ...

Conceptos basicos

• En primer lugar, actualice su conocimiento sobre los estándares modernos utilizados para el diseño (HTML5, CSS3 y eso es todo). También será útil leer sobre la evolución de ECMA Script (JS, de hecho, es una implementación de este estándar en particular) y actualizar sus conocimientos sobre JSON y JWT.
• Un enfoque orientado a objetos para la programación . Si si! Muchos de los que parecen entender de qué se trata esto no son plenamente conscientes de la idea, aunque apareció hace 50 años. Por lo tanto, es aconsejable familiarizarse de nuevo, si hay al menos una pequeña duda.
• Sistemas de control de versiones . Esto es un error absoluto, conocerlos hoy es simplemente necesario para todos los que trabajan en el desarrollo de cualquier software. Incluso si trabaja solo, los sistemas de control de versiones son muy útiles, e incluso un equipo sin ellos es simplemente un infierno. Anteriormente, usaban principalmente SVN o CVS para esto, simplemente porque casi no tenían competidores serios. Ahora el estándar de facto es GIT (gracias a Linus Torvalds). Recomiendo comenzar estudiando la versión de la consola (incluso para Windows), tomará un par de días, pero cuando tenga la idea, comprenderá todos los chips (como el flujo de git) muy rápidamente, y allí puede colocar algún cliente GUI . Y puede ser realmente genial, por ejemplo, si domina los git hooks y configura el envío de datos al servidor de batalla cuando se compromete con la rama maestra del repositorio del proyecto.
• El concepto de MVC (no sería una exageración decir que en casi todos los software web modernos funciona según este principio, por lo que definitivamente tendrá que leer).
• Concepto RestAPI .
• Tipos, características y diferencias de bases de datos y fundamentos de SQL (no estoy diciendo que necesite aprender esto directamente, pero definitivamente necesita tener una presentación, al menos para hacer al menos las consultas más simples). Lea sobre las bases de datos NoSQL, en particular MongoDB y Redis.
• Metodologías BEM . No soy partidario de este enfoque, pero muchos trabajan con su uso para comprender lo que es recomendable leer al menos brevemente.
• Metodologías de desarrollo de Agile y Scrum (no hay nada particularmente complicado, lo más probable para el desarrollo general).
• El concepto de aplicación de página única (SPA) no siempre es aplicable, pero por alguna razón se usa cada vez más incluso para proyectos muy voluminosos. Leer definitivamente.
• Lea sobre Web Sockets , una tecnología que le permite crear una conexión interactiva entre un cliente (navegador) y un servidor para la mensajería en tiempo real. Los sockets web, a diferencia de HTTP, le permiten trabajar con un flujo de datos bidireccional. Propongo verlo como una nueva generación de AJAX. El principal beneficio es la falta de la necesidad de solicitar constantemente nuevos datos del servidor. Si es necesario, el servidor mismo enviará los datos y el navegador los recibirá.
• Otro estándar que es probable que cambie significativamente el desarrollo front-end en el futuro cercano es Web Components . Una herramienta muy poderosa y definitivamente será útil para usted, aunque en este artículo no le prestaré atención.
• XPath es un lenguaje de consulta para un documento DOM. Es poco probable que le sea útil, ya que en la gran mayoría de los casos los selectores CSS son más convenientes, pero es útil saber acerca de su existencia. Ahora se usa principalmente en pruebas o para analizar grandes cantidades de datos.
• Una de las diferencias clave, en comparación con el desarrollo de hace una docena de años, ahora se acepta generalmente usar el llamado. gestores de paquetes ( gestores de dependencias) que provienen del mundo UNIX. Hablaré sobre algunos de ellos con más detalle a continuación. La idea principal es eliminar de los hombros del programador la preocupación por observar las dependencias y actualizar las bibliotecas y los marcos utilizados. Anteriormente, para iniciar un proyecto, tenía que copiar manualmente todos los archivos y bibliotecas necesarios en los lugares correctos, registrar todas las rutas, asegurarse de que sean compatibles entre sí, etc. Ahora todo esto se hace con un par de comandos en la consola (sí, sin la consola en ninguna parte, por desgracia).
• Precompiladores Puede sonar extraño, ya que estamos hablando de lenguajes interpretados, pero sí, muy a menudo usamos programas separados que permiten, por ejemplo, recopilar todos los estilos utilizados en un archivo antes de subirlos a producción, y también usar todo tipo de cosas convenientes en su código, que no están en el estándar (por ejemplo, variables en CSS). Los precompiladores en el front-end son especialmente populares, ya que los lenguajes OOP de tiempo completo se usan con mayor frecuencia para el back-end, los precompiladores no son tan comunes allí y se usan principalmente para la aceleración y el almacenamiento en caché (por ejemplo, PHP Zend OPcache).
• Para simplificar la implementación del desarrollo, ahora es costumbre usar el llamado contenedores (Docker, Kubernetes). Este es un concepto relativamente nuevo en el desarrollo moderno, no lo consideraré en detalle, pero necesito tener una idea: la tecnología es muy poderosa y definitivamente útil.
• Las pruebas son un gran tema aparte. Muy a menudo, esto significa lo que se llama. pruebas unitarias. La esencia de la idea es fácil de entender con un simple ejemplo. Al crear una prueba, usted escribe una especie de contenedor que realizará una de sus funciones y verificará el resultado esperado. Luego, cuando cambia algo en otra función, de la cual depende la primera función, para verificar que el cambio no haya roto nada, solo necesita ejecutar las pruebas creadas anteriormente. Espero que quede claro cuán útil puede ser esto en un proyecto grande.

• La primera y más simple opción es que el servidor web analiza la solicitud y simplemente emite un archivo HTML que coincide con esta solicitud. Máximo, se puede utilizar algún tipo de SSI. De hecho, este es solo un sitio estático clásico, y el backend en este caso es el servidor web en sí. Obviamente, para un proyecto en el que puede haber muchas páginas, este enfoque es desastrosamente inconveniente: si necesita cambiar algo, deberá realizar modificaciones en todos los archivos. También es obvio que nada más que sitios estáticos es prácticamente imposible de implementar aquí. Ahora, esto se utiliza al máximo para algunas páginas de destino muy simples, y luego, el desarrollo de la interfaz para ellas todavía se lleva a cabo ahora, principalmente con la ayuda de los marcos de trabajo modernos, y su aplicación en la mayoría de los casos se practica a través de la funcionalidad Node.js.
• El desarrollo de la versión estática es el uso de idiomas interpretados en el lado del servidor. Luego fue posible escribir plantillas en uno de los idiomas interpretados en los que se sustituyen los datos según la solicitud, y también fue posible almacenar datos no en archivos, sino en la base de datos. Podemos suponer que a partir de este momento hay una separación clara:
  
  1. En realidad, el servidor web en sí. Ahora, esto ya no es necesariamente una aplicación monolítica, por ejemplo, una opción común, cuando Nginx actúa como un equilibrador de carga y Apache procesa las solicitudes ellos mismos. Aunque puede haber muchas opciones (gracias por aclarar prijutme4ty ).
  2. El idioma y el marco en este idioma, que se utilizan para procesar la solicitud y marchar por URL. Quizás no sería un error decir que, en el contexto del desarrollo fullstack, el concepto de "back-end" solo esta capa significa, aunque estrictamente hablando, todo el software de servidor que proporciona el servidor web es, por supuesto, también un back-end. Es importante que el lenguaje y el marco para el backend puedan ser casi cualquier. Por ejemplo, en el caso de Ruby y Ruby on Rails, el ERB incorporado se puede usar como un motor de plantillas, en el caso de PHP y Laravel, Blade se usa con mayor frecuencia como un motor de plantillas, y así sucesivamente.
  3. El código que se ejecuta directamente en el cliente es lo que comúnmente se llama una interfaz de usuario. Aquí, de hecho, todo se reduce a JS.
  
  Durante mucho tiempo, este enfoque fue el principal y único en el desarrollo web, hasta que las tecnologías en la nube comenzaron a desarrollarse y apareció el concepto de SPA.
• Cuando la computación en la nube comenzó a desarrollarse, aparecieron varios modelos de su uso (SaaS, PaaS, IaaS). Entre ellos, me gustaría señalar el llamado. Enfoque sin servidor de AWS. La conclusión es que el servidor web del párrafo anterior se reemplaza con un marco especial a través del cual la aplicación de fondo interactúa con la nube. Las nubes se están desarrollando a pasos agigantados, aparecen muchas nuevas tecnologías y enfoques para su uso, por lo tanto, no es posible describir todo brevemente. Si está interesado en esta área, puede ver la mayoría de las tecnologías de nube utilizadas actualmente con clasificación por categorías aquí: landscape.cncf.io (gracias a KonstantinSpb ).
  
• Con el desarrollo del concepto SPA y la aparición de componentes HTML que se procesan con JS, surgió el problema de mostrar demasiado tiempo: JavaScript puede tardar bastante tiempo en cargarse y procesarse en el cliente. A este respecto, existe otro enfoque para la generación de HTML, que históricamente suele estar asociado con las aplicaciones SPA: la representación del lado del servidor (SSR). La conclusión es que podemos ejecutar la primera representación de componentes en HTML en el servidor, luego entregarla al cliente, junto con el mismo código que generó este HTML, y luego no enviar todo el código de la aplicación a través de la red cada vez, sino simplemente dibujar los componentes necesarios. inmediatamente en el navegador, transmitiendo solo los datos necesarios para cambiar el estado del sistema (es decir, REST). Debe comprender que, en algunos casos, es posible que no lo hagan dividiendo el sistema en bloques funcionales independientes (por ejemplo, agrupando por formas, cada una de las cuales funciona con su propia área del sistema), entonces esto ya no será SPA en el sentido clásico. En este caso, los componentes se procesan una vez antes de enviarlos utilizando algún motor de plantillas JS directamente en el servidor; luego, conceptualmente, esto no es diferente de usar el motor de plantillas en cualquier otro lenguaje de back-end y, aunque, en esencia, renderizar desde JS HTML seguirá sucediendo en el lado del servidor, esto ya no es un SSR, porque este concepto históricamente se ha utilizado precisamente en el contexto de SPA. Para aclarar este momento, gracias a los camaradas staticlab , napa3um y justboris .

Backend

• Java
• .NET
• Pitón
• Node.js (ambiguo aquí, pero más sobre eso más adelante),
• Ruby on Rails
• Y por supuesto PHP

Sobre Python ...

Aquellos que por alguna razón aún no lo conocen, y tal vez incluso lo ignoran, me gustaría aconsejar, sin embargo, que eche un vistazo más de cerca a este idioma. Yo mismo no quise estudiarlo durante mucho tiempo, y la razón no fue como la de muchos ("uf, todo está sangrado allí"), sino porque dan las ventajas de python (perdóneme a las personas que dicen "Python"), generalmente llaman laconicismo idioma

A menudo citan en el espíritu: "que en C toma 100 líneas de código, en un burdel toma 10". Esta "simplicidad" ahuyentó, especialmente después de C ++ y amado C #. Parecía que el idioma era más para “amas de casa” y personas que no sabían programar en idiomas normales con tipificación normal, y de hecho el idioma es solo para guiones. ¡Nunca me he equivocado tanto! :) El lenguaje es muy poderoso, increíblemente conveniente, que se puede aplicar en muchas áreas. No conozco a una sola persona que haya cambiado de PHP a Python, y que después de eso quisiera volver a PHP. A eso es a lo que me dirijo: python es un gran lenguaje para crear un back-end en él.

Bueno, ahora directamente sobre los marcos ... Primero debes decidir: qué servidor necesitamos bloquear o no bloquear. Cada uno de ellos tiene pros y contras. Un servidor sin bloqueo se usa con mayor frecuencia para los sockets web, pero en él puede escribir sitios regulares que puedan procesar simultáneamente una gran cantidad de conexiones. Pero cuando trabaje con dichos servidores, debe recordar que todas las conexiones giran en un "ciclo común" y el bloqueo de este "ciclo" bloqueará por completo todas las conexiones, en este sentido, todas las bibliotecas utilizadas deben ser sin bloqueo. Entre los marcos sin bloqueo, hoy recomendaría usar aiohttp, hay otros bastante populares como Tornado, pero todos son inferiores a aiohttp. En cuanto al marco de bloqueo, Django se destaca aquí. Es adecuado para personas a las que les gusta que todo esté en una botella y preferiblemente de inmediato. Django ya listo para usar incluye un motor de plantillas, ORM y muchas otras bibliotecas convenientes. Pero si, como yo, le gusta elegir bibliotecas para la tarea, le aconsejo que use Flask, y todas las demás bibliotecas ya están personalizadas. El motor de plantillas es el más utilizado por Jinja2, es un motor de plantillas bastante conveniente y común, con el que si tiene preguntas, puede buscar en Google la respuesta muy rápidamente. En cuanto a ORM, las reglas de sqlalchemy en el mundo de Python. Esto, como escribe el creador de peewee (un competidor de sqlalchemy): “SQLAlchemy es el estándar de oro para ORM en el mundo de Python”, y estoy completamente de acuerdo con él. Es una herramienta versátil y potente. Pero tiene que pagar por todo, en este caso tiene que "pagar" la complejidad de este marco. Sin embargo, puede comenzar a trabajar con él muy rápidamente y profundizar en las dificultades que ya están en el proceso.

Hay muchas otras bibliotecas útiles útiles cuando se trabaja con la web, como wtforms, beautifulsoup, Pillow, etc., pero aquí todo depende del proyecto específico y las tareas que enfrenta el desarrollador.

También agregaría la biblioteca de solicitudes (realmente me gustó directamente). Para un servidor sin servidor sin nubes, mira los marcos de Chalice y SAM. Bueno, pipenv, black y flake8 son nuestros, por supuesto.

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.

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

• LESS — : CSS LESS- . LESS CSS, . CSS LESS .
• SASS — CSS, CSS .

• 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 — , .
Libhunt.com — .