Aquedux

Redux през жицата

Когато започнете да използвате React (през 2017 г.), бързо научавате как да предавате подпори, как може да бъде неудобно при по-дълбок потребителски интерфейс и накрая как Redux може да ви помогне с този въпрос. Но какво точно предлага Redux на масата? Е, както се посочва в документацията:

[Redux] ви помага да пишете приложения, които се държат последователно, работят в различни среди (клиент, сървър и нативна) и са лесни за тестване.

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

Едно решение, което често се използва, е да управлявате сами вашата WebSocket връзка. Или използвайте GraphQL крайна точка или дори REST с анкета. Дори ако тези решения имат своите плюсове и минуси, все още трябва да преведете действията си за редуциране в разбираеми инструкции за библиотеката, която използвате от страната на сървъра. Често е натрапчиво и добавя много сложност към вашето приложение.

Тук се намесва Aquedux. В основата си той приема концепциите за намаляване и ги транспонира в по-широк обхват: Приложението като цяло (множество клиентски приложения, сървърни услуги, бази данни).

Повдигане на състоянието

В приложение на React можете да разделите състоянието си на много места и обикновено започва с състоянието на компонент. Брояч за изобразяване? Просто запазете число за брояч в компонента Брояч. Трябва да го увеличите? Използвайте setState. Една основна реализация би изисквала два компонента, този, който действително изобразява брояча, и друг, който съхранява и обработва данните от брояча.

Затова създадохме връзка между нашия чисто визуален компонент с компонент за управление на състоянието. Но единствената връзка, която можем да създадем, е родител към дете и само едно състояние може да се свърже с един компонент.

Какво ще стане, ако броячът се визуализира на различни места в нашето приложение и искаме да запазим едно и също състояние и за двете. Ако е така, бихме искали да споделим състоянието на брояча в цялото приложение. Това е мястото, където Redux влиза в играта. Създаваме връзка между магазин и компоненти. Redux е мениджърът на състоянието на приложението.

Отговорността за данните беше вдигната и централизирана в магазина Redux. Състоянието вече е достъпно в приложението React. Но какво ще стане, ако искате да видите брояча в множество копия на вашите приложения едновременно? Единият във вашето мобилно приложение за реакция, другият във вашето уеб табло за управление React приложение и навсякъде, където можете да използвате среда на Javascript с възможности на Redux и WebSocket. Това е мястото, където Aquedux влиза в действие.

Състоянието вече не се съхранява в едно предно приложение, а зад приложение на сървър, което го синхронизира за всички клиенти.

Aquedux е просто Redux по кабела...

И това е мястото, където постигаме нашата цел без да напускаме екосистемата на Redux! Правейки това, ние запазваме страхотните му свойства, както е посочено във въведението: последователност, крос-платформа и възможност за тестване. Съгласуваност в нашия код също, тъй като редукторите и създателите на действия, които пишете, се използват повторно от страна на клиента и сървъра.

Освен това добавя разширяемост. Приложение Aquedux ще изисква 2 компонента, клиентско приложение, използващо библиотеката aquedux-client и сървърно приложение, използващо библиотеката aquedux-server. Сървърната част е обект без състояние, който зависи от други страхотни инструменти, като Redis, разпределеното хранилище за ключ-стойност. Защо Redis? Тъй като добавя липсващото свойство, за да направи Aquedux подходящ инструмент за мащабируеми, постоянни приложения и приложения в реално време.

Нека да разгледаме как успяваме да се движим около нашите Redux действия с минимален не-Redux код или знания.

Действието първо се изпраща от един от вашите React компоненти. След това преминава през мидълуера на Aquedux, който блокира всяко действие в белия списък, което сте решили да изпратите през WebSocket връзка към сървърното приложение. В този момент действието не е достигнало до вашия локален редуктор, нито компонентът е бил уведомен за промяна на състоянието.

След това блокираното действие се изпраща през WebSocket връзката към свързания с него Aquedux сървър.

Сега се случва магията. Действието се получава от сървъра и незабавно се поставя в опашка в базата данни на Redis. Базата данни ни уведомява обратно (и всички други екземпляри на сървърното приложение) със същото действие. Защо? Защото така можем да постигнем 2 свойства:

* Мащабируемост: Всяко сървърно приложение може да обработва краен брой WebSocket връзки. Чрез механизмите за публикуване/абониране на Redis действието се предава безопасно на всички заинтересовани сървърни приложения и по този начин можете да създадете произволен брой сървърни приложения на вашия любим доставчик на облак.

* Постоянство: чрез разчитане на функциите за постоянство на Redis. Всяко поставено в опашка действие се съхранява в опашка и Redis следи всяко действие плюс може да направи моментна снимка на състоянието му в паметта. Повече за това тук.

И така, цялото състояние на приложението се съхранява в магазина на Redis под формата на всички опашки с действия. Когато сървърно приложение получи ново действие от Redis, то го изпраща в собствен поток Redux. Поради това действието е намалено и временно състояние на клиентското приложение живее в състояние Server App Redux.

След като сървърното приложение намали дадено действие, то го изпраща обратно към всички свои свързани предни приложения. Предното приложение прави същото като сървърното приложение: то намалява действието локално. И готово! Вашият брояч се увеличи за всички свързани мобилни приложения.

Едно действие е изминало, продължава и достига до всички други клиентски приложения, всичко това в реално време.

Трябва да го опиташ!

Говорихме само за повърхността на това, което може да се направи с Aquedux. Не сме говорили за това как състоянието се хидратира при първата връзка, как логиката на приложението може да се управлява най-вече с куп междинен софтуер Redux от страна на сървъра, как магазинът Redux може да бъде нарязан, за да слуша и да въздейства само на подсъстояние с помощта на каналиAqueduxи.

Но ще отнеме повече от една статия, за да обхване правилно всички тези функции. Ето защо мога само да ви препоръчам да опитате сами! Просто отидете на репозитория на Aquedux в Github и разгледайте папката с примери. Той съдържа класическия пример за Redux MVC с мощност на Aquedux върху него!