Creating Full-Stack project (MERN)

Get Started. It's Free
or sign up with your email address
Creating Full-Stack project (MERN) by Mind Map: Creating Full-Stack project (MERN)

1. Code Writing Rules

1.1. Этапы создания проекта:

1.1.1. 1. Определение проблемы.

1.1.2. 2. Выработка требований.

1.1.3. 3. Проектирование архитектуры.

1.1.3.1. Паттерны проектирования

1.1.3.1.1. Зачем знать паттерны?

1.1.3.1.2. Классификация паттернов

1.1.3.1.3. Видео-курс

1.1.3.1.4. Примеры в коде

1.1.3.2. Желательные характеристики проекта

1.1.3.2.1. 1. Минимальная сложность

1.1.3.2.2. 2. Простота сопровождения ( чтение )

1.1.3.2.3. 3. Слабое сопряжение (loose coupling)

1.1.3.2.4. 4. Расширяемость

1.1.3.2.5. 5. Возможность повторного использования

1.1.3.2.6. 6. Высокий коэффициент объединения по входу

1.1.3.2.7. 7. Низкий или средний коэффициент разветвления по выходу

1.1.3.2.8. 8. Портируемость

1.1.3.2.9. 9. Минимальная, но полная функциональность

1.1.3.2.10. 10. Стратификация

1.1.3.2.11. 11. Соответствие стандартным методикам

1.1.3.3. Ключевые моменты

1.1.3.3.1. * Главным Техническим Императивом Разработки ПО является управление сложностью. Управлять сложностью будет гораздо легче, если при проектировании вы будете стремиться к простоте. 


1.1.3.3.2. * Есть два общих способа достижения простоты: минимизация объема существен- ной сложности, с которой приходится иметь дело в любой конкретный момент времени, и подавление необязательного роста несущественной сложности. 


1.1.3.3.3. * Проектирование — эвристический процесс. Слепое следование какой􏰀либо единственной методологии подавляет творческое мышление и снижает качество ваших программ. 


1.1.3.3.4. * Оптимальный процесс проектирования итеративен; чем больше вариантов проектирования вы попробуете, тем удачнее будет ваш окончательный проект.

1.1.3.4. Принципы

1.1.3.4.1. Резюме эвристических принципов проектирования

1.1.3.5. Уровни проектирования программы: Систему (1) следует разделить на подсистемы (2), подсистемы — на классы (3), а классы — на методы и данные (4); методы также необходимо спроектировать (5)

1.1.4. 4. Конструирование.

1.1.4.1. 4.1 Подготовка к конструированию.

1.1.4.2. 4.2 Контрольный список: Проектирование при конструировании

1.1.4.2.1. Методики проектирования * Выполнили ли вы несколько итераций проектирования, выбрав самую лучшую попытку, а не просто первую? 
 * Попробовали ли вы выполнить декомпозицию системы несколькими способами с целью нахождения наилучшего варианта? 
 * Использовали ли вы для решения проблемы и нисходящий, и восходящий способы проектирования? 
 * Выполнили ли вы прототипирование сомнительных или плохо известных частей системы, создав абсолютный минимум подлежащего выбрасыванию кода, нужного для ответа на отдельные вопросы? 
 * Был ли выполнен формальный или неформальный обзор вашего проекта другими разработчиками? 
 * Довели ли вы проектирование до той точки, в которой реализация проекта кажется очевидной? 
 * Выполнили ли вы регистрацию проекта уместными способами, такими как Wiki, электронная почта, плакаты, цифровые фотографии, UML, карточки CRC или комментарии в самом коде? 
Цели проектирования 
 * Адекватно ли проект решает проблемы, которые были определены и отложены на этапе разработки архитектуры? 
 * Разделен ли проект на уровни? 
 * Удовлетворены ли вы тем, как выполнена декомпозиция программы на под- 
системы, пакеты и классы? 
 * Удовлетворены ли вы тем, как выполнена декомпозиция классов на методы? 
 * Достигнуто ли минимальное взаимодействие классов между собой? 
 * Спроектированы ли классы и подсистемы так, чтобы их можно было ис
пользовать в других системах? 
 * Будет ли программа легкой в сопровождении? 
 * Является ли проект полным, но минимальным? Все ли его части действи
тельно необходимы? 
 * Подразумевает ли проект использование только стандартных методик? 
Смогли ли вы избежать применения экзотических, трудных для понимания 
элементов? 
 * Помогает ли проект в целом минимизировать и несущественную, и суще- 
ственную сложность?

1.1.5. 5. Тестирование и гарантия качества.

1.1.6. 6. Внедрение приложения.

1.1.7. 7. Будущие улучшения.

1.2. Принципы проектирования

1.2.1. SOLID

1.2.1.1. Single Responsibility Principle

1.2.1.2. Open-Closed Principle

1.2.1.3. Liskov Substitution Principle

1.2.1.4. Interface Segregation Principle

1.2.1.5. Dependency Inversion Principle

1.2.1.6. Код должен быть: 1. Деструктуризирован по принципу: объект должен иметь 1 ответственность и эта ответственность должна быть полностью инкапсулирована в класс. 2. Написан таким образом, чтобы его можно было дополнять, но нельзя было изменять. 3. Необходимо разделять слои абстракции по типу. К примеру, user и guest это люди, но разные, нужно разделять. 4. Те классы, которые наследуют от базового класса, если не использую методы базового класса, то они не должны от них зависить. 5. Модули верхних уровней не должны зависеть от модулей нижних уровней.

1.3. Модели проектирования

1.3.1. MVC

1.3.1.1. Model View Controller, where: Model - Business Logic; View - UI logic. Controller - Request & relay data.

1.3.1.1.1. Проще говоря. MVC разбивается на M-VC (четко разделяя на бизнес-логику и UI), где: M - весь бэкенд, реализующий паттерн Observer; VC - весь UI, где View занимается отображением Model, а Controller реагирует на действия пользователя и вызывает методы Model.

1.3.2. MVVM

1.3.2.1. Назначение

1.3.2.1.1. Используется для разделения модели и её представления, что необходимо для их изменения отдельно друг от друга. Например, разработчик задаёт логику работы с данными, а дизайнер работает с пользовательским интерфейсом.

1.3.2.2. Использование

1.3.2.2.1. MVVM удобно использовать вместо классического MVC и ему подобных в тех случаях, когда в платформе, на которой ведётся разработка, есть «связывание данных». В шаблонах проектирования MVC/MVP изменения в пользовательском интерфейсе не влияют непосредственно на Mодель, а предварительно идут через Контроллер (англ. Controller) или Presenter. В таких технологиях как WPF и Silverlight есть концепция «связывания данных», позволяющая связывать данные с визуальными элементами в обе стороны. Следовательно, при использовании этого приёма применение модели MVC становится крайне неудобным из-за того, что привязка данных к представлению напрямую не укладывается в концепцию MVC/MVP.

1.3.2.3. Описание

1.3.2.3.1. Шаблон MVVM делится на три части: Модель (англ. Model) (так же, как в классической MVC) представляет собой логику работы с данными и описание фундаментальных данных, необходимых для работы приложения. Представление (англ. View) — графический интерфейс (окна, списки, кнопки и т. п.). Выступает подписчиком на событие изменения значений свойств или команд, предоставляемых Моделью Представления. В случае, если в Модели Представления изменилось какое-либо свойство, то она оповещает всех подписчиков об этом, и Представление, в свою очередь, запрашивает обновлённое значение свойства из Модели Представления. В случае, если пользователь воздействует на какой-либо элемент интерфейса, Представление вызывает соответствующую команду, предоставленную Моделью Представления. Модель Представления (англ. ViewModel) — с одной стороны, абстракция Представления, а с другой — обёртка данных из Модели, подлежащиx связыванию. То есть, она содержит Модель, преобразованную к Представлению, а также команды, которыми может пользоваться Представление, чтобы влиять на Модель.

1.3.3. БЭМ

1.3.3.1. Информация о БЭМ, из чего он состоит и примерами кода можно почитать по ссылке (в github gist)

1.4. Эффективность

1.4.1. SDLC

1.4.2. CI/CD

1.4.2.1. Continuous Integration & Continuous Delivery (Непрерывная интеграция и доставка софта) CI (Continuous Integration или Непрерывная интеграция) – это автоматическая сборка программного обеспечения и его тестирование на корректность. CD (непрерывная доставка или Continuous Delivery) – это автоматическая установка изменения кода на серверах компании.

1.4.2.1.1. Весь цикл CI & CD в абстракции:

1.4.3. waterfall

1.4.3.1. Каскадная модель

1.4.3.2. Каскадная модель — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.

1.4.3.3. Минусы Waterfall:

1.4.3.3.1. - При waterfall-подходе можно быстро вносить изменения в код, но без постоянных проверок выявление багов потребует гораздо больше времени и может произойти уже после начала коммерческой эксплуатации, причем таких «отложенных» багов в одном релизе может оказаться несколько. - Чем больше ошибок накапливается, тем сложнее тестировать и находить их, что в результате может привести к неприятным последствиям.

1.5. Книги

1.5.1. you-dont-know-js-ru

1.5.2. JavaScript Style Guide (airbnb)

1.5.3. Algorithms

1.5.4. игры

1.6. Способы сократить код ( Мой github ) :

1.7. Моя версия лучшего стека

1.7.1. Frontend: React-native typescript graphql Backend: NodeJs Golang Python Docker

1.8. SDLC

1.8.1. Фазы SDLC

1.8.1.1. 1. Requirements Analysis Анализ требований

1.8.1.1.1. 1. Формируются цели и задачи проекта 2. Определяются сроки и стоимость разработки ПО 3. Анализ и формирование требований заказчика 4. Формируется и подписывается техническое задание на разработку ПО

1.8.1.2. 2. Design Проектирование/Архитектура

1.8.1.2.1. 1. Выбор технологий и языка программирования 2. Назначаются требования к пользовательскому интерфейсу 3. Определяв наиболее подходящую СУБД 4. Определяем требования к аппаратному обеспечению (Hardware) 5. Выбирается архитектура системы

1.8.1.3. 3. Development Разработка и реализация

1.8.1.3.1. 1. Разработка ПО с помощью технологий и языков программирования (которые определили на 2й фазе) 2. Создание прототипа и рабочей версии продукта

1.8.1.4. 4. Testing Тестирование

1.8.1.4.1. 1. Разрабатывать планы, графики, методики и описания тестирования. 2. Моделировать ситуации, которые могут возникнуть в условиях эксплуатации программного обеспечения. 3. Работать в связке с разработчиком. 4. Создавать тест-планы, тест-кейсы. 5. Выполнять тестирование программных продуктов. 6. Выполнять нагрузочные тестирования. 7. Анализировать результаты, полученные во время прохождения тестов. 8. Классифицировать выявленные ошибки и заносит их в базу данных для текущего программного продукта. 9. Контролировать процесс ликвидации выявленных ошибок разработчиком ПО. 10. Общаться с разработчиками. 11. Консультировать клиентов. 12. Составлять документацию для проведения функционального тестирования. 13. Участвовать в проведении опытных эксплуатаций программных продуктов. 14. Заполнять таблицы баз данных тестовыми данными. 15. Проверка продукта на соответствие требованиям и нуждам заказчика 16. Поиск и регистрация дефектов

1.8.1.4.2. STLC

1.8.1.5. 5. Release Выпуск/Релиз и внедрение

1.8.1.5.1. 1. Установка системы (Install, Deployment) 2. Эксплуатация (Определение и тестирование все ли ок, на стороне заказчика)

1.8.1.6. 6. Maintenance Поддержка

1.8.1.6.1. 1. Поддержка пользователей 2. Исправление дефектов (Warranty - это определенный период, когда компания обязуется исправлять дефекты, бесплатно) 3. Реализация нового функционала 4. Изменение существующего функционала

2. Something to add

2.1. JSON

2.2. WebSockets

2.3. ref

2.4. React With ASP.NET

2.5. Асинхронность

2.6. Synthetic events

2.7. Unidirectional data flow

2.8. EventSource

2.9. LongPolling

2.10. Performance and optimization

2.10.1. PWA (progressive web apps)

2.10.1.1. Service Worker

2.10.1.1.1. Сердце PWA — Service Worker. Это проксирующий слой между фронтэндом и бэкэндом, находящийся в браузере. Все запросы браузера идут через него. Данное разделение на два независимых слоя позволило сделать переход обычного веб сайта в PWA максимально простым. Из хранилищ у Service Worker'a есть доступ к Cache Storage для web ресурсов, и IndexDB для данных. Но, самое главное, полная свобода для реализации бизнес логики.

2.10.1.2. HTTPS

2.10.1.2.1. PWA требует, чтобы все ресурсы сайта передавались по HTTPS протоколу. SSL сертификат можно получить бесплатно, некоторые хостеры это делают за вас. Но критично, чтобы на сайте не было ссылок на незащищенные ресурсы — некоторые браузеры просто не будут отображать сайт в этом случае. Основная встречаемая в таких случаях проблема — картинки.

2.10.1.3. Application Shell

2.10.1.3.1. App shell — это просто скелет графического интерфейса, шаблон. Для примера, возьмем средний сайт c хидером, двумя колонками и прочим. Грубо говоря, вырежем из него контент текущей страницы и всю динамическую информацию, оставшаяся статика — app shell. Суть в том, что app shell хранится на клиенте и загружается при запуске приложения, а затем уже в него грузится из сети динамическая информация. И пока она грузится, app shell должен выглядеть красиво («лоадеры» на местах и т.п.)

2.10.1.4. Web App manifest

2.10.1.5. Web App manifest

2.10.1.5.1. JSON файл, декларативно определяющий для браузера название приложения, иконку, как будет выглядеть PWA (fullscreen, standalone и др.) и некоторые другие параметры. Позволяет «установить» PWA как отдельное приложение на домашний экран смартфона.

2.10.1.6. Push Notifications

2.10.1.6.1. Пока что это самая популярная и самая злоупотребляемая технология PWA — за последние несколько месяцев число сайтов, заходя на которые первым делом ищешь «мышкой» кнопку «Блокировать» на предложение получать самые свежие новости, выросло, такое ощущение, многократно, а само желание навязать свой Push похоже на Spam.

2.10.2. AMP (Google's preferred mobile content format)

2.11. object.keys

2.11.1. object.keys

2.11.2. object.assign

2.11.2.1. Нужен для того, чтобы менять предыдущий state

2.11.2.1.1. const state = { values: { name: 1, age: 2 } } /* this.setState(prevState => ({ values: { [event.target.name]: event.target.value } })) */ console.log(state) const newState = Object.assign({}, state, { values: { ...state.values, name: 2 } }) console.log(newState)

2.11.3. object.is()

2.12. Haxe

2.13. ESLINT

2.14. Reflect

3. Front-end

3.1. React

3.1.1. Virtual DOM

3.1.1.1. Компоненты написанные на JSX преобразуются в чистый JS с помощью CLI инструмента Babel. После чего преобразует их в VDOM дерево. И наконец, VDOM алгоритм создает реальный DOM.

3.1.2. Lifecycles

3.1.2.1. В процессе работы компонент проходит через ряд этапов жизненного цикла. На каждом из этапов вызывается определенная функция, в которой мы можем определить какие-либо действия

3.1.2.1.1. Монтирование

3.1.2.1.2. Обновление

3.1.2.1.3. Размонтирование

3.1.2.1.4. Обработка ошибок

3.1.2.1.5. Другие методы API

3.1.2.2. "Шпаргалка"

3.1.3. State Management

3.1.3.1. Mobx

3.1.3.2. Redux 2.0

3.1.3.2.1. npm i redux react-redux

3.1.3.2.2. src

3.1.3.2.3. index.js

3.1.3.2.4. термины

3.1.3.3. redux

3.1.3.3.1. 1/ import createStore from redux

3.1.3.3.2. 2.1/ create reducer

3.1.3.3.3. 2.2/ midleWare

3.1.3.3.4. 3/ create store

3.1.3.3.5. import logger from 'redux-logger'

3.1.3.3.6. dispatch Async using promise-redux

3.1.3.3.7. dispatch Async

3.1.3.3.8. Redux React

3.1.3.4. Context API

3.1.3.5. Unstated-next

3.1.3.6. Recoil

3.1.3.7. Baobab

3.1.3.8. Flux

3.1.3.9. Reflux

3.1.4. Libraries

3.1.4.1. React Hooks

3.1.4.1.1. example

3.1.4.1.2. React Hooks — это функции, которые позволяют определять категорию состояния и жизненный цикл (state, lifecycle) React-компонента без использования ES6-классов. И позволяет использовать в приложении только лишь функциональные компоненты. При этом весь функционал остается.

3.1.4.2. classnames

3.1.4.2.1. Эта библиотека для простого условного объединения имен классов.

3.1.4.3. React Navigation

3.1.4.4. Роутинг

3.1.4.4.1. React-Router

3.1.4.4.2. History api

3.1.4.5. Формы

3.1.4.5.1. Redux Form

3.1.4.5.2. Formik

3.1.4.5.3. Final Form

3.1.5. Task-managers

3.1.5.1. Webpack

3.1.5.2. Gulp

3.1.5.2.1. Gulp - это инструмент для автоматизации рутинных задач, которые возникают при веб-разработке. Это может быть не только frontend разработка, это может быть и backend разработка.

3.1.5.3. Grunt

3.1.6. Layout

3.1.6.1. UI frameworks

3.1.6.1.1. bootstrap

3.1.6.1.2. antDesign

3.1.6.1.3. CSS Grid

3.1.6.1.4. Material UI

3.1.6.1.5. Rebass

3.1.6.1.6. Rsuitejs

3.1.6.1.7. Materializecss

3.1.6.1.8. Elemental UI

3.1.6.1.9. Semantic UI

3.1.6.2. Templates

3.1.6.2.1. NextJS Material Kit.

3.1.6.2.2. Argon

3.1.6.2.3. vuexy-react-admin-dashboard-template

3.1.6.2.4. Gull - React Redux & HTML Admin Dashboard Template

3.1.6.3. CSS

3.1.6.3.1. SASS/SCSS

3.1.6.3.2. LESS

3.1.6.4. Конструктор UI

3.1.6.4.1. storybook

3.1.6.5. Для слайдов

3.1.6.5.1. Spectacle

3.1.6.6. Icons

3.1.6.6.1. icons8.com

3.1.7. SSR

3.1.7.1. Изоморфные React-приложения: производительность и масштабирование

3.1.7.1.1. Gatsby

3.1.7.2. Code splitting

3.1.7.2.1. Next.js

3.1.7.2.2. used-styles

3.1.7.2.3. Prerender

3.1.7.2.4. React-Imported-Component

3.1.7.2.5. React Loadable SSR

3.1.7.2.6. React.Lazy

3.1.8. Solution Patterns

3.1.8.1. input

3.1.8.1.1. Валидация

3.1.8.1.2. реш.1 Универсальное решение для большенства инпутов.

3.1.8.1.3. реш. 2. Создаем middleWare ( для redux) который будет фильтровать определенные слова.

3.1.8.2. Loader

3.1.9. Strongly-typed

3.1.9.1. TypeScript

3.1.9.2. Reason

3.1.9.3. Flow

3.1.9.3.1. npm

3.1.9.4. Kotlin

3.1.9.4.1. Kotlin — это язык со статической типизацией, разработанный в JetBrains. Он нацелен на платформы работающие на основе JVM, Android, LLVM и JavaScript.

3.1.9.5. Hegel.js

3.1.10. Constructors

3.1.10.1. JAMStack (burn your wordpress/drupal apps to the ground!)

3.1.10.1.1. Jekyllrb

3.1.10.2. bit.dev

3.1.10.3. appian.com

3.1.10.4. Webiny.com

3.1.11. Testing

3.1.11.1. Enzyme

3.1.11.1.1. Инструкция

3.1.11.2. JEST

3.1.11.3. Mocha

3.1.11.4. Karma (run Jest or Mocha in browsers)

3.1.11.5. Storybook - documentation, component development

3.1.11.6. Selenium

3.1.12. SDK

3.1.12.1. Electronjs

3.1.13. Admin

3.1.13.1. Marmelab.com/react-admin

3.1.14. Terms

3.1.14.1. For Optimization

3.1.14.1.1. Code splitting

3.1.14.1.2. Suspense

3.1.14.1.3. PureComponent

3.1.14.1.4. Хуки жизненного цикла shouldComponentUpdate(…) {…}

3.1.14.1.5. React.memo()

3.1.14.2. Promise

3.1.14.3. Замыкание / Closures

3.1.14.4. Fetch

3.1.14.5. Event Loop

3.1.14.6. Immutable

3.1.14.6.1. Что такое иммутабельность: Неизменяемым (англ. immutable) называется объект, состояние которого не может быть изменено после создания. Результатом любой модификации такого объекта всегда будет новый объект, при этом старый объект не изменится.

3.1.14.7. DI ( Dependency Injection)

3.1.14.7.1. Внедрение зависимостей — это стиль настройки объекта, при котором поля объекта задаются внешней сущностью. Другими словами, объекты настраиваются внешними объектами. DI — это альтернатива самонастройке объектов.

3.1.14.8. Observables

3.1.14.9. Scope

3.1.14.10. this .apply() call() и bind

3.1.14.10.1. this

3.1.14.10.2. Чтобы передавать какой-либо контекст и вызывать функцию с нужным указанным контекстом, существуют встроенные методы, которые есть в JavaScript: call(), apply() и bind(). Все эти функции применяются для явного указания значения this в функции: при заимствовании метода, при передаче функции обратного вызова. С помощью методов Function.prototype также можно использовать такие приемы как каррирование или функции от произвольного числа параметров.

3.1.14.10.3. .bind()

3.1.14.10.4. .call()

3.1.14.10.5. .apply()

3.1.14.10.6. Example

3.1.14.11. Рекурсия

3.1.14.11.1. Простыми словами, рекурсия – определение части функции (метода) через саму себя, то есть это функция, которая вызывает саму себя, непосредственно (в своём теле) или косвенно (через другую функцию)

3.1.14.12. v8

3.1.14.12.1. Его ограничения

3.1.14.12.2. Движек V8 - транслирует JavaScript в машинный код. Превращает JavaScript из узкоспециализированного языка в язык общего назначения

3.1.14.13. Типы программирования

3.1.14.13.1. ООП

3.1.14.13.2. ФП ( Функциональное программирование )

3.1.14.14. serviceWorker

3.1.14.15. Контекст ( Context API )

3.1.14.15.1. Example

3.1.14.15.2. API

3.1.14.16. Object.assign

3.1.14.17. LocalStorage

3.2. React Native

3.2.1. Библиотеки

3.2.1.1. React Navigation

3.2.1.1.1. уроки

3.2.2. Готовые решения

3.2.2.1. Tabbar Component For React-Native

3.2.2.2. TabStackNavigatorRedux

3.2.2.3. React-native-motion

3.2.2.4. Покупные

3.2.2.4.1. React Native Multi Vendor UI Template

3.2.3. SDK

3.2.3.1. Expo

3.2.3.2. Ionic

3.2.3.2.1. Ionic + React - Tutorial for Beginners 2020

3.2.4. Books

3.2.4.1. Awesome React Native

3.2.4.2. jondot/awesome-react-native

3.3. Vue

3.4. Ember

3.5. Angular

3.5.1. SSR

3.5.1.1. angular universal

3.5.2. angular universal

4. Back-end

4.1. db

4.1.1. SQL ( Реляционные базы данных ) Relational Databases

4.1.1.1. PostgreSQL

4.1.1.2. MySQL

4.1.1.3. PL/SQL

4.1.1.3.1. Oracle Database

4.1.1.4. MS SQL

4.1.2. No SQL ( Нереляционной базы данных ) Nonrelational database

4.1.2.1. Caching ( Кэшированные )

4.1.2.1.1. Redis

4.1.2.1.2. Cassandra

4.1.2.1.3. Bagri

4.1.2.1.4. ?memcached

4.1.2.2. Document Databases Документоориентированная СУБД

4.1.2.2.1. Couchbase

4.1.2.2.2. RethinkDB

4.1.2.2.3. MongoDB

4.1.2.3. Graph Databases Графовая база данных

4.1.2.3.1. ArangoDB

4.1.2.3.2. Neo4j

4.1.2.3.3. OrientDB

4.1.2.4. Message Brokers ( also Message Queues ) Брокер сообщений

4.1.2.4.1. NATS

4.1.2.4.2. RabbitMQ

4.1.2.4.3. Kafka

4.1.2.4.4. ZeroMQ

4.1.2.5. Database search engine Поисковая система базы данных

4.1.2.5.1. ?AWS

4.1.2.5.2. ElasticSearch

4.1.2.5.3. Solr

4.1.2.5.4. Sphinx

4.1.2.5.5. Эллластиик

4.1.3. Термины:

4.1.3.1. CRUD

4.1.3.2. deadlock

4.1.3.3. race condition

4.2. Server

4.2.1. HTTP

4.2.1.1. Это договоренность между отправителем и получателем о том, как именно нужно обмениваться данными.

4.2.1.2. Виды HTTP запросов:

4.2.1.2.1. POST

4.2.1.2.2. GET

4.2.1.2.3. PUT

4.2.1.2.4. PATCH

4.2.1.2.5. DELETE

4.2.1.3. HTTP/2

4.2.1.3.1. Возможности HTTP/2 сводят к минимуму задержки и заметно повышают производительность ресурсов.

4.2.1.3.2. Преимущества:

4.2.1.3.3. Иструкция подключения

4.2.2. Web-серверы

4.2.2.1. Apatch

4.2.2.2. Nginx

4.2.3. unix linux

4.3. API

4.3.1. GraphQL

4.3.1.1. Apollo

4.3.1.1.1. Apollo GraphQL client

4.3.1.1.2. apollo-link-rest

4.3.1.1.3. apollo-link-state

4.3.1.2. Prisma

4.3.1.3. Relay

4.3.1.4. SOAP

4.3.2. REST

4.3.2.1. ?RESTful API

4.3.3. СПРАВОЧНИК API

4.3.3.1. ReactDOM

4.3.3.2. ReactDOMServer

4.3.3.2.1. Объект ReactDOMServer позволяет отрендерить компоненты в статическую разметку. В основном, он используется на Node-сервере.

4.3.4. Глубокое понимание API (ws, REST, JSON, CORS, Security)

4.4. Media (audio & video)

4.4.1. FFmpeg

4.5. Machine Learning and AI

4.6. Scripting Languages

4.6.1. NodeJS

4.6.1.1. Библиотеки

4.6.1.1.1. Socket.IO

4.6.1.1.2. Puppeteer

4.6.1.2. frameworks

4.6.1.2.1. Express

4.6.1.2.2. NestJS

4.6.1.2.3. MeteorJs

4.6.1.2.4. Hapi.js

4.6.1.2.5. KoaJS

4.6.1.2.6. Lodash

4.6.1.3. Auth

4.6.1.3.1. OAuth

4.6.1.3.2. Basic authentication

4.6.1.3.3. Token authentication

4.6.1.3.4. JWT

4.6.1.3.5. OpenID

4.6.1.4. API

4.6.1.5. Термины

4.6.1.5.1. cookie

4.6.1.5.2. DNS

4.6.1.5.3. Изучить

4.6.1.6. методы

4.6.1.7. knowledge

4.6.1.7.1. Timur Shemsedinov

4.6.1.8. Testing

4.6.1.8.1. WebdriverIO

4.6.1.8.2. Selenium

4.6.1.9. Deploy

4.6.1.9.1. Heroku

4.6.2. Java

4.6.2.1. Spring Boot

4.6.2.2. Jenkins

4.6.3. Python

4.6.3.1. frameworks

4.6.3.1.1. Django

4.6.4. Ruby

4.6.5. .Net

4.6.6. GOlang

4.6.7. PHP

4.6.7.1. cms

4.6.7.1.1. Drupal

4.6.7.2. frameworks

4.6.7.2.1. Laravel

5. Dev Ops

5.1. Docker

5.1.1. What is it?

5.1.1.1. Images

5.1.1.1.1. Образы (Только для чтения). Образы используются для создания CONTAINER.

5.1.1.2. Registries

5.1.1.2.1. Хранит в себе IMAGES . Публичные и приватные реестры, с которых можно скачать либо загрузить Images (Образы). Публичные образы - это hub.docker.com. Registries - это компоненты распространения.

5.1.1.3. Containers

5.1.1.3.1. Контейнеры похожи на дериктории. В них содержится все, что нужно для работы приложения (различные файлы типа NodeJs, компоненты и тд.). Контейнер создается из IMAGES

5.1.2. Small Scale: Just run containers on DigitalOcean Docker servers

5.1.3. Medium Scale: Rancher, AWS Fargate

5.1.4. Big Scale: Kubernetes

5.2. CI Pipelines

5.2.1. Hosted solutions

5.2.1.1. Github Actions

5.2.1.2. CircleCI

5.2.1.3. Codeship

5.2.2. Internal solutions

5.2.2.1. Jenkins

5.2.2.2. DroneCI (Docker native YAY)

5.2.2.3. GitLab

5.3. Server Management (configuration management or CM)

5.3.1. Docker

5.3.2. Terraform

5.3.3. Ansible

5.3.4. Salt

5.3.5. Puppet

5.3.6. Chef

5.4. Infrastructure Platforms

5.4.1. Google Cloud

5.4.2. Digital Ocean (simpler infrastructure)

5.4.3. AWS

5.4.4. Azure

5.5. Operational Visibility

5.5.1. Monitoring (NewRelic, DataDog, Sentry, CloudWatch)

5.5.2. Logging (Elk Stack, Sematext)

6. Netlify

6.1. Gatsby

6.1.1. Prismic

6.1.2. Shopify

6.1.3. image