Я фронтендер, но хочу начать писать фулстек. Что делать?

Придётся разобраться с тремя вещами:
— Язык программирования для бекенда
— Базы данных
— Инфраструктура

Популярные бекендовые языки — это Ruby, Pyhon, JS (Node.js), Java и PHP. Если вы фронтендер, то берите Node.js — будет проще.

Про базы данных и инфраструктуру позднее.

Окей, я установил Node.js. Что это такое?

Node.js позволяет писать сервера на JavaScript-е. Это движок для JavaScript-а вроде того, что в Chrome; вы передаёте в него JavaScript-файл, и движок его запускает:

// index.js
console.log('42');

// Shell
$ node ./index.js
42

Чтобы сделать реальный сервер, вам надо вызвать какой-нибудь метод, встроенный в Node.js (например, createServer() из модуля net — документация). На практике это мало кто делает — почти все используют высокоуровневые обёртки.

А что за колбеки?

Главное, что нужно знать про Node.js — это то, что она основана на колбеках. Это значит, что, чтобы отправить запрос к базе данных, вы делаете не вот так:

const data = sql.query('SELECT name from users');
console.log(data);

а вот так:

sql.query('SELECT name from users', (error, data) => {
 console.log(data);
});

Под капотом Node.js отправляет запрос к базе данных и сразу же продолжает выполнение JS-кода. А когда запрос завершается, она вызывает колбек, передавая в него данные. Это позволяет писать сервера, которые обслуживают кучу запросов одновременно.

По теме: Why Asyncronous? · Understanding Node.js Event Loop

А можно без колбеков?

Можно.

— Можете использовать промисы вместо колбеков. Нативные АПИ с колбеками превращаются в АПИ с промисами с помощью util.promisify.

— Вдобавок к промисам, есть ещё async/await. Он доступен с Node 7.6+.

У нативных АПИ вроде fs.readFile есть ещё синхронные варианты вроде fs.readFileSync. В реальных серверах их использовать не стоит, а то сервер будет умирать от пяти одновременных клиентов. Зато они полезны в консольных скриптах.

Так, а как мне сделать сервер?

Возьмите Express:

const express = require('express');
const app = express();

// ↓ Определяем REST-запрос
app.get('/api/user', (req, res) => {
 res.json({ name: 'Jason Bourne' });
});

// ↓ Просим сервер отдавать статические файлы
// из папки public (если это не REST-запрос)
app.use('*', express.static('public'));

app.listen(3000, () => {
 console.log('Server is listening on port 3000')
});

Express помогает делать простые сервера и REST API.

А как написать что-то реальное?

В реальном приложении, кроме Express-сервера, вам понадобятся:
— Для авторизации — Passport.js. Работает с логином-паролем, соцсетями, OAuth и ещё кучей способов логина.
Либо возьмите готовое решение вроде Auth0: https://t.me/iamakulov_channel/209

— Для валидации запросов — express-validator. Умеет нормализовывать и проверять запросы от клиента

— Для отправки почты — nodemailer. Работает с SMTP, есть упрощённые настройки для AWS SES

— Для хеширования паролей — bcrypt. Главное — прочитайте, как их правильно хешировать: https://t.me/iamakulov_channel/203

— Для логгирования — loglevel, debug или winston. Идеального для меня решения я так и не нашёл

— Для работы в продакшене — pm2. PM2 перезапускает приложение при падении, делает деплой без даунтайма, умеет распределять нагрузку и деплоить удалённо

+ Почитайте посты по хештегу #учу_nodejs_в_продакшене — там тоже полезные ссылки.

Скоро продолжим.

Хороший старый доклад про Редакс: https://iamakulov.com/talks/redux-in-real-life/

(Транслитерация терминов в этом докладе бесит примерно половину читателей. Если вы открыли доклад, и она вас тоже взбесила, можете добавить огня под моим будущим транслитерационным котлом в аду ↓)

Продолжаем.

Где мне хранить данные в бекенде?
Храните их в базе данных.

База данных — это отдельный процесс, с которым общается ваш бекенд. Общение с базой зависит от её вида, но часто выглядит вот так:

Бекенд → базе данных:
SELECT name, email FROM users;

БД → бекенду:
+----------------------+--------------------------+
| name                 | email                    |
+----------------------+--------------------------+
| John Foo             | john.foo@gmail.com       |
| Fohn Joo             | fohn.joo@gmail.com       |
+----------------------+--------------------------+


Фронтенд-приложения часто хранят данные в локальных переменных (например, в редаксовском сторе). Делать так на бекенде — плохо:
— если сервер вдруг умрёт, вы всё потеряете;
— масштабировать бекенд на несколько машин (или stateless-инфраструктуру вроде AWS Lambda) будет гораздо сложнее.

А как выбрать подходящую базу данных?
Если не особо разбираетесь в движках (как я), берите MySQL: https://www.quora.com/Should-a-newbie-learn-SQL-or-NoSQL

— Данные в MySQL хранятся в виде таблиц, связанных между собой
— Она поддерживает SQL (т.е. запросы вида SELECT * FROM users)
— Она должна быть ок для большинства задач

Если разбираетесь, расскажите, что используете вы (и почему) → @iamakulov_channel_chat

Окей, я настроил MySQL. Мне теперь напрямую SQL-запросы писать?
Нет, напрямую писать запросы не нужно.

Вместо этого вы:
1. берёте библиотеку вроде Sequelize,

2. описываете данные в виде классов:
const User = sequelize.define('user', {
 username: Sequelize.STRING,
 birthday: Sequelize.DATE
});

3. и работаете с ними как с объектами:
await User.create({
 firstName: 'John',
 lastName: 'Hancock'
});

Такой подход называется ORM (Object-relational mapping). Он лучше, чем сырые запросы, потому что:
— код получается очевиднее,
— переехать на другую БД становится проще (например, Sequelize сглаживает различия между диалектами SQL),
— уязвимости вроде SQL Injection становятся невозможными.

У меня случайно создалось два пользователя с одинаковой почтой. Можно что-то сделать, чтобы этого не происходило?
Да, для этого есть ограничения — constraints.

Ограничения — это условия, которые накладываются на колонки и поддерживают базу данных корректной. Если при выполнении какой-то операции условие нарушится, MySQL выдаст ошибку.

В MySQL есть ограничения:
— UNIQUE (проверяет, что все значения в колонке уникальны)
— PRIMARY KEY (как UNIQUE, но используется для ID-шек и имеет несколько отличий)
— FOREIGN KEY (проверяет связи между таблицами — например, что заказ ссылается на корректного пользователя)
— ENUM/SET (указывает фиксированный список значений для колонки)

Ограничения указываются при создании таблицы или добавляются позднее. В Sequelize они задаются в параметрах колонки (например, есть опции unique: true и primaryKey: true).

Документация описывает ограничения подробнее: https://dev.mysql.com/doc/refman/5.7/en/constraints.html

А как сделать, чтобы всё работало быстро?
— Использовать индексы. Индексы — это дополнительные структуры данных, которые помогают движку искать данные быстрее. Они или создаются вручную, или добавляются автоматически, когда вы помечаете колонку как PRIMARY KEY или UNIQUE.

С индексами важно не переусердствовать: они ускоряют поиск, но замедляют изменение/вставку и требуют дополнительного места на диске.

— Кешировать данные локально. Или просто в каком-нибудь объекте, или в Redis, если доступ к кешу нужен из нескольких процессов.

Если знаете, что добавить, расскажите → @iamakulov_channel_chat

А как повысить надёжность?
— Использовать транзакции. Транзакции — это когда вы объединяете несколько операций в одну, чтобы отменить их, если что-то пойдёт не так.

Транзакции полезны для операций вроде «перевод денег» — первой операцией вы вычитаете сумму из одной записи, второй операцией добавляете в другую. Если в середине транзакции пропадёт питание или связь с клиентом, то транзакция просто не применится.

— Использовать репликацию. Репликация — это дублирование данных БД в другой экземпляр БД, запущенный в другом месте. В MySQL есть встроенная репликация, но её надо настраивать. Amazon RDS предоставляет репликацию из коробки.

Если знаете, что добавить, тоже расскажите → @iamakulov_channel_chat

Окончание — скоро.

​​В прошлом году помог Комитету (vc.ru, tjournal.ru, dtf.ru) сделать большие ветки комментариев быстрее. FPS скроллинга повысился в 4 раза на мощных устройствах и в 10 на слабых.

Илья Чекальский (CTO Комитета) написал отзыв:

Вам тоже помогу разобраться с производительностью (и, например, повысить этим конверсию): iamakulov.com/pages/perf-consulting

Кстати, для подписчиков канала скидка 10%. Просто скажите, что вы отсюда :–)

🎉 Сделал гайд для Google по оптимизации фронтенда с вебпаком: https://developers.google.com/web/fundamentals/performance/webpack/

В гайде:
— Как сделать фронтенд меньше
— Как улучшить кеширование
— Как следить за приложением, чтобы оно оставалось маленьким

Бонусом:
💻 Приложение, на котором можно тренироваться: https://github.com/GoogleChromeLabs/webpack-training-project

📝 Список оптимизаций для конкретных библиотек: https://github.com/GoogleChromeLabs/webpack-libs-optimizations