Stateless и stateful что это
Stateful vs stateless
Overview
The state of an application (or anything else, really) is its condition or quality of being at a given moment in time—its state of being. Whether something is stateful or stateless depends on how long the state of interaction with it is being recorded and how that information needs to be stored.
Stateless
A stateless process or application can be understood in isolation. There is no stored knowledge of or reference to past transactions. Each transaction is made as if from scratch for the first time. Stateless applications provide one service or function and use content delivery network (CDN), web, or print servers to process these short-term requests.
An example of a stateless transaction would be doing a search online to answer a question you’ve thought of. You type your question into a search engine and hit enter. If your transaction is interrupted or closed accidentally, you just start a new one. Think of stateless transactions as a vending machine: a single request and a response.
Stateful
Stateful applications and processes, however, are those that can be returned to again and again, like online banking or email. They’re performed with the context of previous transactions and the current transaction may be affected by what happened during previous transactions. For these reasons, stateful apps use the same servers each time they process a request from a user.
If a stateful transaction is interrupted, the context and history have been stored so you can more or less pick up where you left off. Stateful apps track things like window location, setting preferences, and recent activity. You can think of stateful transactions as an ongoing periodic conversation with the same person.
The majority of applications we use day to day are stateful, but as technology advances, microservices and containers make it easier to build and deploy applications in the cloud.
Containers and state
As cloud computing and microservices grow in popularity, so too has containerization of applications, whether stateful or stateless. Containers are units of code for an application that are packaged up, together with their libraries and dependencies, so that they’re able to be moved easily and can run in any environment, whether on a desktop, traditional IT infrastructure, or on a cloud.
Originally, containers were built to be stateless, as this suited their portable, flexible nature. But as containers have come into more widespread use, people began containerizing (redesigning and repackaging for the purposes of running from containers) existing stateful apps. This gave them the flexibility and speed of using containers, but with the storage and context of statefulness.
Because of this, stateful applications can look a lot like stateless ones and vice versa. For example, you might have an app that is stateless, requiring no long-term storage, but that allows the server to track requests originating from the same client by using cookies.
Stateful и Функциональные stateless компоненты в React
Russian (Pусский) translation by Marat Amerov (you can also view the original English article)
Несмотря на то, что многие важные концепции должны быть покрыты, компоненты, несомненно, являются сердцем и душой React. Хорошее понимание компонентов должно сделать вашу жизнь легкой, как React разработчика.
Необходимые условия
Этот урок предназначен для начинающих, которые начали изучать React и нуждаются в лучшем понимании компонентов. Мы начнем с основ компонентов, а затем перейдем к более сложным концепциям, таким как шаблоны компонентов и когда использовать эти шаблоны. Рассмотрены различные классификации компонентов, такие как классы по сравнению с функциональными компонентами, компоненты с изменяемым состоянием и без, а также контейнерные и презентационные компоненты.
Прежде чем приступить к работе, я хочу представить вам фрагмент кода, который мы будем использовать в этом уроке. Это простой счетчик, построенный с помощью React. Я вернусь к некоторым частям этого примера на протяжении всего урока.
Что такое компоненты?
Компоненты являются самодостаточными независимыми микрообъектами, которые описывают часть вашего пользовательского интерфейса. Пользовательский интерфейс приложения можно разделить на более мелкие компоненты, где каждый компонент имеет свой собственный код, структуру и API.
Например, у Facebook есть тысячи функциональных возможностей, взаимодействующих друг с другом, когда вы просматриваете их веб-приложение. Вот интересный факт: Facebook состоит из 30 000 компонентов, и их число растет. Компонентная архитектура позволяет вам рассматривать каждую часть отдельно. Каждый компонент может обновлять все в своем скопе, не беспокоясь о том, как он влияет на другие компоненты.
Если в качестве примера использовать пользовательский интерфейс Facebook, панель поиска будет хорошим кандидатом для компонента. Новостная лента Facebook может создавать другой компонент (или компонент, на котором размещено много подкомпонентов). Все методы и вызовы AJAX, связанные с панелью поиска, будут находиться внутри этого компонента.
Компоненты также могут использоваться повторно. Если вам нужен один и тот же компонент в нескольких местах, это легко. С помощью синтаксиса JSX вы можете объявлять свои компоненты, чтобы они отображались везде, где хотите.
Props и State
Компонентам нужны данные для работы. Существует два разных способа объединения компонентов и данных: либо в виде props, либо в виде state. props и state определяют, что делает компонент и как он себя ведет. Начнем с props.
props
Хотя данные в props доступны для компонента, философия React заключается в том, что props должен быть неизменным и сверху вниз. Это означает, что родительский компонент может передавать любые данные, которые он хочет своим детям, в качестве props, но дочерний компонент не может изменять свои props. Итак, если вы попытаетесь изменить props, как я сделал ниже, вы получите «Cannot assign to read-only» TypeError.
State
С другой стороны, State является объектом, принадлежащим компоненту, где он объявлен. Его область ограничена текущим компонентом. Компонент может инициализировать свое состояние и обновлять его, когда это необходимо. Состояние родительского компонента обычно становится props дочернего компонента. Когда состояние передается из текущей области, мы называем его prop.
Теперь, когда мы знаем основы компонентов, давайте посмотрим на базовую классификацию компонентов.
Класс Компоненты и Функциональные компоненты
Компонент React может быть двух типов: либо это компонент в виде класса, либо функциональный компонент. Разница между ними очевидна из их имен.
Функциональные компоненты
Компоненты в виде классов
Синтаксис state =
Компоненты класса могут существовать и без state. Ниже приведен пример компонента класса, который принимает на вход props и отображает JSX.
Мы определяем метод конструктора, который принимает props в качестве входных данных. Внутри конструктора мы вызываем super(), чтобы передать все, что унаследовано от родительского класса. Вот несколько деталей, которые вы, возможно, пропустили.
В качестве наилучшей практики я рекомендую использовать конструктор для всех компонентов в виде класса.
Компоненты с состоянием и компоненты без состояния
Это еще один популярный способ классификации компонентов. И критерии классификации просты: компоненты, которые имеют состояние и компоненты, которые не имеют его.
Компоненты имеющие состояние
Компоненты имеющие состояние всегда являются компонентами в виде класса. Как упоминалось ранее, компоненты с состоянием имеют состояние, которое инициализируется в конструкторе.
Мы создали объект state и инициализировали его с числом 0. Существует альтернативный синтаксис, предлагаемый для упрощения называемый class fields. Это еще не входит в спецификацию ECMAScript, но если вы используете транспилер Babel, этот синтаксис должен работать из коробки.
В целом вы можете избежать использования конструктора с помощью этого нового синтаксиса.
Ключевое слово this ссылается к экземпляру текущего компонента.
SetState() принимает объект как входной параметр, и мы увеличиваем предыдущее значение count на 1, которое работает как ожидалось. Однако есть улов. Когда есть несколько вызовов setState, которые читают предыдущее значение state и записывают в него новое значение, мы можем столкнуться с состоянием гонки. Это означает, что конечные результаты не будут соответствовать ожидаемым значениям.
Вот пример, который должен дать вам понимание. Попробуйте это в приведенном выше сниппете codeandbox.
Мы хотим, чтобы setState увеличивал счет на 100, а затем обновлял его на 1, а затем удалял 100, которые были добавлены ранее. Если setState выполняет переход состояния в приведенном порядке, мы получим ожидаемое поведение. Тем не менее, setState является асинхронным, и несколько вызовов setState могут быть собраны вместе для лучшего поведения и производительности UI. Таким образом, приведенный выше код дает поведение, отличное от ожидаемого.
Поэтому вместо прямой передачи объекта вы можете передать функцию обновления, имеющую сигнатуру:
SetState() перерендеривает компонент, и у вас есть работающий stateful компонент.
Компоненты без состояния
Недостатком является то, что вы не можете использовать хуки жизненного цикла. Метод жизненного цикла ShouldComponentUpdate() часто используется для оптимизации производительности и для ручного управления тем, что получает рендеринг. Вы не можете использовать это с функциональными компонентами. Refs также не поддерживаются.
Контейнерные компоненты и Презентационные компоненты
Это еще один паттерн, который очень полезен при написании компонентов. Преимущество такого подхода заключается в том, что логика поведения отделена от презентационной логики.
Компоненты презенторы
Презентационные компоненты сочетаются с представлением или отвечают за отображение. Эти компоненты принимают props из своего контейнера и рендерят их. Все, что связано с описанием пользовательского интерфейса, должно быть здесь.
Презентационные компоненты могут повторно использоваться и должны оставаться отделенными от поведенческого слоя. Презентационный компонент получает данные и коллбеки исключительно через props, и когда происходит событие, например нажатие кнопки, он вызывает коллбек к компоненту контейнера через props для вызова метода обработки событий.
Функциональные компоненты должны быть вашим первым выбором для написания презентационных компонентов, если не требуется состояние. Если презентационный компонент требует состояния, он должен быть связан с состоянием пользовательского интерфейса, а не с фактическими данными. Презентационный компонент не взаимодействует с хранилищем Redux и не выполняет вызовы API.
Компоненты контейнера
Компоненты контейнера будут иметь дело с поведенческой частью. Компонент контейнера сообщает презентационному компоненту, что нужно рендерить с помощью props. Он не должен содержать ограниченные DOM разметки и стили. Если вы используете Redux, компонент контейнера содержит код, который отправляет действие в хранилище. В качестве альтернативы, это место, где вы должны поместить свои вызовы API и сохранить результат в state компонента.
Обычная структура состоит в том, что в верхней части находится компонент контейнера, который передает данные дочерним презентационным компонентам в качестве props. Это работает для небольших проектов; однако, когда проект становится больше, и у вас много промежуточных компонентов, которые просто принимают props и передают их дочерним компонентам, это будет неприятно и трудно поддерживать. Когда это произойдет, лучше создать компонент контейнера, уникальный для листового компонента, и это облегчит нагрузку на промежуточные компоненты.
Итак, что такое PureComponent?
Однако с PureComponent он выполняет поверхностное сравнение объектов. Поверхностное сравнение означает, что вы сравниваете непосредственное содержимое объектов, а не рекурсивно сравниваете все пары ключ/значение объекта. Таким образом сравниваются только ссылки на объекты, и если state/props мутированы, это может работать не так, как предполагалось.
React.PureComponent используется для оптимизации производительности, и нет причин, по которым вы должны использовать его, если не столкнулись с какой-либо проблемой производительности.
Заключение
Надеемся, что в этом уроке вы получили обзор на уровне компонентной архитектуры и различные паттерны компонентов в React. Что вы думаете об этом? Поделитесь мыслями в комментариях.
За последние пару лет React стал популярным. Фактически, у нас есть ряд материалов на рынке Envato, которые доступны для покупки, просмотра, реализации и т. д. Если вы ищете дополнительные ресурсы вокруг React, не стесняйтесь ознакомится с ними.
Назад, к технологиям верхнего палеолита, от любимых всеми REST, STATEless, CRUD, CGI, FastСGI и MVC
«Только со смертью догмы начинается наука.»
// Галилео Галилей
«Я начал завидовать рабам. Они всё знают заранее. У них твёрдые убеждения.»
// х/ф Марка Захарова «Убить дракона» по мотивам пьесы Евгения Шварца
Уже пару лет и дня не проходит, чтобы я не услышал (или не прочитал) от людей, начинающих новые проекты, фразу типа «Возьмем серверный движок для REST API и MVC, и погнали». Сначала я думал, что у этих слов есть один источник, может книжку какую завезли во все магазины или где-то в топе поисковиков лежит статья, зомбирующая разработчиков. Если же выяснять у них, что они понимают под REST и MVC, то можно повредиться умом. Ну с MVC уже все ясно, об этом я уже давно писал, ничего не изменилось, только усугубилось, стоит набрать в Google Images «mvc» и мы увидим страшное, стрелочки в любые стороны. Ну а про REST отвечают следующее: ну как же, нам нужно из браузерного GUI и мобильного приложения вызывать серверные методы, например: setUserCity(userId, cityId) или calculateMatrix(data) или startVideoConverter(options, source, destination) а потом мы столкнемся с большой нагрузкой и архитектура REST все решит. Дальше я задаю вопросы, от которых глаза округляются уже у тех, кто недавно еще горел праведной верой, рвался в бой и точно знал, что к чему в этом мире. Теперь можно перейти к рассмотрению терминологической катастрофы, в эпицентре которой мы с вами пребываем.
Вопросы по MVC
Первый вопрос: нарисуйте мне схему «что такое MVC?». Что я получаю: 
Для MVP таких пониманий и схем тоже достаточно, даже не сомневайтесь.
Второй вопрос: а как это паттерн, предназначенный для пользовательских интерфейсов может быть применен на сервере?
Я не могу перечислить тут все возможные варианты ответов. Но правильный встречается очень редко и он такой: на сервере MVC может быть только если у нас пользовательский интерфейс полностью реализован на сервере, т.е. нет браузерного кода, интерфейс генерируется на сервере, а браузер просто показывает его.
Вопросы по REST
Первый вопрос: ну, дорогие мои, а как эти ваши setUserCity, calculateMatrix и startVideoConverter могут быть реализованы на REST?
Мой вариант ответа: весь смысл REST в том, что он оперирует файлами, каждый из которых имеет свой уникальный URL и над этим файлом можно производить только HTTP методы: GET, PUT, POST, DELETE. Поэтому, все эти свои setUserCity будьте любезны заменить на HTTP POST /user/id и отправлять туда нужно целиком сериализованного пользователя. Или другой вариант, нужно для каждого параметра пользователя иметь отдельный URL. Очевидно, что CRUD методов (create, read, update, delete), вызванных через HTTP методы, хватит для манипуляции файлами или объектами в БД. Например, для ввода форм и бланков, сохранения их в таблицы с дальнейшим удалением и редактированием. Но любое современное приложение не может же быть сведено к таким примитивным вызовам. И разработчики, чаще всего, понимают под REST именно его противоположность — RPC (вызов удаленных процедур), когда мы можем сделать сколько угодно методов, а не только CRUD, и когда один URL может отдавать совершенно разные ответы, в зависимости от того, какой пользователь его вызвал, с какими параметрами и в какой последовательности. А это уже совсем не REST, например, Хабр выдает по адресу http://habrahabr.ru/tracker/ разный список для каждого из нас и такое повсеместно, в Google, Facebook, Github и т.д. Так что, уберите слово REST, вводящее в заблуждение, делайте API и все.
Второй вопрос: ладно, а что такое REST именно для вас?
Разброс мнений тут не так широк, как для MVC, но терминологическая катастрофа вот в чем: как я показал выше, под REST понимают совсем не REST, а чтобы сделать все по науке идут и изучают догматическую литературу по REST, подыскивают фреймворки с поддержкой REST, а в результате, выходит гибрид RPC и REST. И хуже всего, что все это происходит неосознанно.
Третий вопрос: вы можете объяснить, как именно REST спасет вас от больших нагрузок?
Мой вариант ответа: он STATEless, но что это значит и зачем нам отказываться от состояния на сервере — обсудим ниже.
В чем же смысл STATEless
При масштабировании современные веб-сервера порождают отдельные процессы для каждого запроса. Если эти процессы будут STATEless, то нет ни какой разницы, на одном сервере работает система или на сотне серверов. Каждый процесс получает данные запроса по протоколу CGI и должен выделить память, развернуть в ней свои структуры данных, если нужно, то создать соединения с БД, прочитать файлы или сделать вызовы к внешним модулям. Потом процесс выполнит свою логику и все это хозяйство погибает. Такие процедуры задерживают выполнение HTTP запросов, поэтому есть FastСGI, который предусматривает несколько всегда запущенных процессов и экономит время на их порождении, первичном выделении памяти, ее освобождении и завершении процессов. Еще FastСGI позволяет повторно использовать подключения к БД и другие дескрипторы. Но структуры памяти, необходимые для обработки каждого HTTP запроса, все равно живут не долго, они погибают и создаются, а при этом повторно выполняются запросы в БД, обращения к файлам и к внешним модулям. Но и в этом случае необходимо придерживаться принципа STATEless, потому, что неизвестно, в какой процесс попадает следующий HTTP запрос. А разные запросы могут относиться к разным сайтам приложениям, и даже в одном приложении могут относиться к разным сессиям или предусматривать развертывание в памяти очень отличающихся структур данных.
Настало счастье программисту из верхнего палеолита
В то время, когда складывалось мое программистское мировоззрение (1997-2002 годы), мэинстримом была трехзвенная архитектура приложений (оконный клиент, сервер приложений, СУБД). И клиенты взаимодействовали с серверами приложений по RPC. Все было STATEful, но тогда и задач то таких не было, которые бы требовали масштабирования сервера приложений на много машин. И вот, долгие годы, с 2002 по 2012 я терпел REST и STATEless, мечтая в душе про полноценное STATEful программирование и RPC для высоконагруженных систем. Теперь же, когда большинство языков и платформ имеют свои Event-Loop решения, как Node.js, Python’s Twisted и Ruby Event Machine, я чувствую себя совершенно счастливым человеком и больше не знаю, зачем нужен STATEless и откуда берутся в наше время фразы типа «Возьмем серверный движок для REST API и MVC, и погнали».
С тех пор, как появилась возможность делать высоконагруженные сервера приложений с состоянием, процессы опять стали жить долго, все структуры данных можно оставлять в памяти, остаются и соединения с БД, кеши, таймеры, можно развернуть сложную модель в памяти и она будет там сидеть месяц. И с этой моделью может взаимодействовать клиентская часть через API. А теперь немного арифметики, представьте, что состояние пользователя 32Кб, а у нас есть 16Гб памяти, этого хватит на 524288 (более полумиллиона) пользователей.
Единственное, что осталось решить, это как направлять в один и тот же процесс все запросы, относящиеся к одной сессии. То есть, нужно «приклеивать» сессию к серверу и к процессу (процесс может быть на одном из множества серверов). Для этого у нас есть аппаратные и программные балансировщики, реализующие прилипание по IP (ip-sticky) и по кукизу (cookie-sticky). Конечно, каждый процесс должен маркировать кукизом со своим идентификатором все запросы, которые не имеют такого идентификатора. Если идентификатор есть, то работает прилипание, а если нет, то round robin или более сложный алгоритм балансировки.
А с MVC мы еще не закончили
MVC научил всех разделять модель, представление и контроллер, причем бездумно, где нужно и где не нужно. Но общего понимания о каждом компоненте так и не выработалось. Кто-то оставляет в модели только параметры, а методы выносит в контроллер, а у кого-то модели умеют себя сами сохранять и восстанавливать из БД, другие же — яростные противники такого подхода и выделяют еще data access layer для доступа к БД. В любом случае, с терминологической катастрофой нужно что-то делать.
Предлагаю использовать слово «модель», как его принято использовать в науке и технике, а именно — это упрощенное представление реальной системы и/или процесса. Из этого следует, что модель может содержать параметры и методы. Но методы эти должны подходить под определение. Например, методы CRUD не могут быть частью модели объекта реального мира, потому, что ни один реальный объект не умеет себя создавать или удалять. CRUD — это не есть часть модели, а часть API слоя хранения данных, как методы отрисовки — часть API графического слоя. Модель же не должна знать ничего о своем хранении, протоколах передачи по сети, особенностях отрисовки в браузере и т.д. Хороший пример метода для модели: SteppingMotor.setSpeed(х), когда модель является драйвером физического устройства или используется для моделирования физического устройства. Другой хороший пример, это математические модели, например, Equation.calculateRoots(). И третий пример, это информационные модели, например: Patient.assignBed(bedId).
Слова же «view» и «controller» по возможности избегаю, лишь потому, что в сознании отдельных разработчиков у них могут быть совершенно непредсказуемые и странные смыслы. Вместо них лучше использовать более конкретные понятия «template», «control» (или «user interface control»), «request router» и т.д.
Советы по разработке приложений на технологиях верхнего палеолита
Из событийно-ориентированных решений я лично использую Node.js, но думаю, что они могут носить универсальный характер:
1. Разделяйте клиент и сервер (браузерное приложение и сетевое API) по принципам RPC и STATEful с приклеиванием сессий к процессам.
2. Используйте оперативную память, не лазьте в базу данных постоянно. STATEful — это великолепная возможность писать быстрые приложения, и даже не из-за того, что Event Loop фреймворки предполагают неблокирующий ввод/вывод, а из-за правильного использования памяти. Большинство операций ввода-вывода не нужно даже делать в во время обработки запросов, чтение можно делать упреждающими и параллельным, а запись ленивой (lazy). Разворачивайте данные в память приложения, стройте хеши, объекты, массивы, которые проживут долгую и счастливую жизнь в STATEful процессе.
3. Между разными процессами взаимодействуйте через ZeroMQ (и другие MQ), TCP, HTTP, IPC и еще что-угодно. Таким образом, данные разных процессов, в зависимости от того, что это за данные, могут или дублироваться в памяти (кешироваться, если это общие данные) или быть разделены на «прилепленные» сессии или синхронизироваться между собой через межпроцессовое взаимодействие.
Заключение
Каждый раз переосмысливайте шаблоны проектирования. не берите чужие решения только из-за их авторитета, они могут быть не плохими, но не для вашего случая. Брать решения можно и нужно, но только при полном их переваривании и понимании.
Всегда сверяйте терминологию со своими коллегами еще перед началом проекта и уточняйте ее вплоть до создания словарика в общем доступе. С той путаницей понятий, которая накопилась в наше время, невозможно быть уверенными, что говорите об одном и том же, даже если используете одни и те же слова.
UPD: Комментарии ниже — лучшее доказательство терминологической катастрофы. Оказывается нет общего понимания, не только в том, что такое REST и MVC, но даже в том, что такое stateless и statefull. И еще интереснее, нет общего понимания, что такое «состояние» вообще. Кто-то понимает под этим состояние процесса (его память), кто-то состояние всех серверов (тогда состояние может быть в другом процессе), а кто-то состояние системы в целом (тогда состоянием можно считать и хранимые файлы и данные в БД). В такой ситуации лучше выбрасывать старые термины, испорченные и испачканные, о смысле которых уже нет ни какой надежды договориться и вводить новые, но делая уже строгие словарные определения. Иначе, вообще не о чем говорить, нельзя построить диалога, говоря одними словами, но о совершенно разных понятиях.