#22 Будущее фронтендовых приложений. От запросов, к движкам синхронизации / Андрей Ситник

В этом выпуске мы с Андреем Ситником. обсудили будущее фронтент разработки и большой сдвиг в сторону баз данных на клиенте с автоматической синхронизацией вместо классических апи вызовов. Или короче, поговорили о движках синхронизации. Андрей рассказал про движение Local First, которое предлагает ряд принципов создания веб-приложений, одновременно решающих задачи владения данными и совместной работой. Благодаря движкам синхронизации, Local First приложения получают возможность работать офлайн и хранить свои данные там где нужно, не завязываясь на конкретный, обычно облачный, провайдер. Это позволяет строить более быстрые, безопасные и защищенные в плане владения данными приложения. 

✅ Подписывайтесь на канал «Организованное программирование» в Telegram: https://ttttt.me/orgprog
– Список подкаст-платформ (Apple Podcast, Google Podcast, Spotify, Яндекс.Музыка и другие): https://podcast.ru/1734325321
– Смотреть на Youtube: https://youtu.be/-57r5AARRgY

Полезные ссылки:
https://x.com/andrey_sitnik
https://t.me/sitnik
https://sitnik.ru
https://localfirstweb.dev - Local-First Software
https://electric-sql.com - ElectricSQL | Postgres sync engine
https://www.inkandswitch.com/local-first/ - Local-first software
https://evilmartians.com/chronicles/recapping-the-first-local-first-conference-in-15-minutes - Recapping the first Local‑First conference in 15 minutes



00:00  Введение и анонс
00:57 Проблемы текущего фронтенда
02:48 Сокращение времени разработки — ключ к успеху стартапов.
05:38 Проблемы синхронизации - Недостаток обсуждения архитектуры взаимодействия клиента и сервера.
09:04 О том, как создание отдельного сервиса для синхронизации данных улучшает производительность.
11:52 Проблемы GraphQL и возвращение к React Query
13:44 Преимущества отдельных движков синхронизации
15:51 Взаимодействие с фреймворками и стейт-менеджментом
17:44 Про Движки синхронизации, которые ускоряют разработку и повышают удобство приложений.
22:14 О том, как декларативная работа с данными и инкапсуляция логики на сервере ускоряют разработку.
24:07 Про Использование стейт-менеджеров
28:42 Критерии качественного Sync engine
34:20 Проблемы оптимистичного UI
36:55 Преимущества REM, которые помогают быстро создавать прототипы с готовой настройкой прав доступа.
43:13 Мультимастер синхронизация баз данных
45:59 Проблемы и решения синхронизации
47:51 Сложные базы данных требуют специализированных подходов к синхронизации.
48:48 Подходы к синхронизации данных
52:11 Проблемы и решения в синхронизации данных
55:51 Проблемы с хранением больших объемов данных
59:08 Синхронизация данных между вкладками
01:04:53 Open API помогает создавать единую систему типов для синхронизации.
01:10:26 Local First и его преимущества
01:14:11 Менеджеры паролей и их будущее
01:16:19 Проблемы и решения в Local First
01:20:20 Будущее разработки и выбор фреймворков
01:24:04 Пример использования Local First
01:28:15 Пара слов о проблемах с Next.js и вариантах их решений
01:33:12 Движение за уменьшение размера баннов
01:35:55 Уменьшение зависимостей улучшает безопасность и производительность проектов.



#LocalFirst #Frontend #WebDevelopment #OfflineApps #DataSynchronization #React #JavaScript #CloudComputing #OfflineMode #Programming #WebApps #CRDT #backend 

Будущее фронтендовых приложений. От запросов, к движкам синхронизации / Андрей Ситник / #22

★ Support this podcast ★

Creators & Guests

Guest

Андрей Ситник

Создатель PostCSS, ведущий фронтендер Злых марсиан

What is Организованное программирование?

Пишем код, за который не стыдно. Разбираем базу, даем рекомендации и встречаемся с умными людьми

а возможно ли создание универсального единого слоя который удовлетворит всех не дай Бог это будет как в реакте будет одно решение для всех и типа не подходящее никому оно вообще стоит того чтобы [ __ ] ну типа это была хорошая идея была хорошая попытка там есть интересные идеи но я просто не хочу чтобы другие люди страдали там идея именно в том чтобы как раз чтобы клиента не было мне нужен только рендеринг больше ничего ребята Уберите всё остальное я не хочу писать API Я не хочу вообще ничего [музыка]

Привет друзья с вами Кирилл макевнин ведущий подкаста организованное программирование тема сегодняшнего подкаста Local First которую мы обсудим вместе с Андреем ситком фронтенде злых Марсин и создателем пост CSS который я думаю если знают и не все то точно встречались с этой библиотекой все напрямую или через крупные компании сайты с которыми мы все работаем Привет Андрей привет Спасибо что позвал я вобще коне тебя те позвать изначально тема была Мы думали про Open Source поговорить но потом ты мне сказал про Слушай Кирилл Есть такая тема с First И я такой понял что как-то немножко пропустил эту штуку и она звучит прям супер интересно Я думаю мы для большого количества наших зрителей сегодня откроем типа новый мир и некий тренд движение фронтенда и может быть даже как-то в этом поучаствую а потом через пару лет будем говорить что вот мы так сказать Ну ты и так это сделаешь я знаю без меня но я хотя бы своим подкастом тоже както в этом немножко приоб к этой штуке и мы для того чтобы перейти к этой теме давай начнём так сказать немножко порвём пуканы если они Я надеюсь порвутся про проблемы текущего фронтенда Да вот есть фрон есть фреймворки все соревнуются строгают эти стейт менеджеры кэширует там бэнды все дела и в какой-то момент вдруг пришли люди говорят вы всё делаете неправильно передаю тебе слово знаешь ня больше всего поражает современно разработки Я когда начина разработку Я верил сообществу и самое ужасное что произошло со мной вот за недавнего времени я потерял эту Веру потому что я вдруг заметил что то что раньше можно было делать за X времени Теперь стало 2 и если подумать весь Прогресс - это сокращение ресурсов что вот типа каждая Open Source библиотека которая двигает индустрию это там не знаю на 3% на 1% увеличивается эффективность то то что раньше можно было делать меньше в количеством сил теперь можно сделать ещё меньше в количеством сил и вот самые ужасно Что произошло последнее время ради моды Люди стали тратить больше сил это вот прямо жуткая вещь которую наблюдаю что типа люди типа реально то что раньше одним разработчиком делалось теперь делается двумя и в два раза дольше и багов больше и ничего не понят Да в два раза дольше правильно Да ещё и производительность сильно замедлилась любой ревик тебе это скажет да и Любой кто раньше на бэнде полноценном работал смотрит на всё это говорит ребята мы куда-то сверну не туда фундамента почему это потому чт практически всегда у нас был толстый НД А сейчас у нас стал толстый клиент но вместо того чтобы сокращение размера энда у нас на самом деле большинство приложений создаются по парадигме толстый клиент они написаны на двух разных языках очень часто и в итоге нам требуется просто два ра больше программистов чтобы писать большинство сайтов он промист для о для вотт времени чтобы это исправить но Что удивительно очень мало как-то туда тратится сил тратится внимание на то чтобы реально ускорять скорость разработки и очень много сил тратится на моду на какие-то облака которые продвигают программисты рекламщики и так далее И вот как это исправить это сложный вопрос Там много надо менять нам нужно во-первых перестать следовать моде нам нужно наконец-то подбирать фреймворки под задачи нам нужно например понимать что если у тебя толстый кнд Ты не должен делать толстый клиент А если ты делаешь толсты клиент твой бнд должен быть попроще можно адвоката дьявола поиграю адвоката дьявола пока мы далеко не ушли я просто понимаю Какой тебе вопрос сейчас зададут и скажут Ну Ребята вы такие типа вот вы там фул стейки мы вообще во-первых в них не верим и так далее То есть ты можешь для ответить для них что А как же разделение труда там вот это всё не нет Это не связано с этим вот даже если у тебя как бы тебе требуется в два раза больше людей не потому что у тебя как бы кнд на одном языке а фронтенд на другом языке и тебе требуется фронтендер и Эндер а потому что просто у тебя два приложения мы забываем что если у нас толстый фронтенд то у нас многоузловой приложение что у нас клиент у нас лён ная система в которой куча разных узлов между собой системно обмениваются данными и любой фронтенд на реакте у которого есть сильный бкд если это не простая база данных типа фабей нормальный Кэн Это по-хорошему распределённое приложение у которого есть несколько типов разных узлов которые между собой синхронизируют данные и в этом ключе никто не думает К сожалению тем не менее Короче всё стало медленнее потому что у нас толстый клиент толстый энд что с этим делать делать много что надо фундаментально это прямо какой-то Проклятие индустрии я так скажу мы как программисты мы вот это всё создаём не для того чтобы модно рассказывать какой показывать крутые примеры кода как всё это красиво двигается А мы это всё делаем для того чтобы бизнесмены стартаперы Могли сделать новый бизнес за выходные Аше короче во времена рельсы Ну типа вся революция рельсы была в том что типа бизнес можно сделать за выходные после реакта это исчезло какой смысл тогда в ЧМ на задача нам по-хорошему нужно сократить чтобы за выходные теперь можно было сделать не простую Круть систему а сложный интерактивный интерфейс Вот это уже интереснее как бы если туда мы начнём двигаться и вот как бы фундаментально там множество прин где это можно делать но есть одна очень интересная задача которой поче не замечает Я вот недавно опрашивал различных разработчиков и задавал каждому один и тот же вопрос Какие системы общения между клиентом и сервером ты знаешь не на уровне протокола А на уровне архитектуры твоего фронта То есть как вот ты организует во фронте общение с клиентами сервером Какие подходят под Какие задачи и как их выбирать и вот ни один человек не мог нормально ответить Просто у них дыра чёрная Никто об этом не обсуждает но у нас же фундаментальная Проблема в том что у нас распределённое приложение которого есть одна узел есть другой узел и соответственно общение между ними критическая штука если посмотреть на на разработку На многие проекты мы увидим что огромное количество ресурсов тратится Вот как раз на то что мы называем API на то как об этом договориться как его

рефакторинга времени и при этом мы об этом не говорим мы говорим а мы огромное количество времени говорим о том как менять дом модель ну типа это хорошо говорить об этом мы действительно должны менять дом эффективно это такая Ну кстати ещё такое я наба что оно такое более в компьютер sence алгоритмически Вот такое там да да Такое тоже обсуждаем типа но при этом вот чисто бытовую задачу Как общаться с сервером никто не говорит Потому что ну что типа берёшь фе и всё работает но нет оно не работает так дальше моя любимая тема в наме мы проверяем пром сделать самую простую ве форму авторизации и форм авторизации там множество типа вещей где можно запи Но вот одна удивительная вещь очень мало Кто думает в любых формах о том что будет если не будет интернета если вот гнёт интернет как пойдёт себ форма большинство форм просто показывают бесконечную крутилку Ну это как бы такая мелкая проблема но на показывает фундаментальную вещь что мы на самом деле качество связи клиента сервера отвратительно во всех приложениях и мы как программисты и мы как пользователи к этому привыкаем что вот типа ладно вот это как бы проблема Как гает интернет вс-таки редкая задача Ну вот фундаментально вот я сейчас пользуюсь приложением и нажимаю кнопку я вижу крутилку нажимаю вторую кнопку вижу крутилку нажимаю кнопку сохранить вижу крутилку и у меня постоянно вот этот блокиратор есть который мешает мне нормально пользоваться сайтом вместо того чтобы просто типа свою задачу Я жду и чёрт типа это как-то отвратительно Мы привыкли всем нормально Всем как бы хорошо но вот есть же ощущение от нативных приложений которые летают гово раз хотел сказать Вот именно живя в Штатах Я думаю как раз наверное тоже заметил я с этим столкнулся Может быть что-то там у нас поменялось Но я столкнулся именно здесь Потому что если ты тимолом когда-нибудь пользовался мобильные приложения какие-то вот такие вещи это просто какой-то кошмар То есть ты прямо это видишь и чувствуешь Как у них мало того что всё не нативно так Я каждый раз знаешь запускаю и думаю Ребята вы же со своим фронт эндом обещали что будет быстро Вы же обещали что всё будет то есть в этом же мы же с этого начинали мы именно на это ругались когда говорили про моргание про

ки вот когда говори зача Я согласен с тобой знаеш в каком смысле я понимаю разницу вот когда ты в браузере это действительно Ну ты к этому относишься может быть проще но на мобилках это чувствуется капец как сильно и я прям вот эти приложения этих чуваков которые на мобилках делают вот полный веб их их ты прям ненавидеть начинаешь с первой секунды как ты ставишь это приложение вот Ну да типа проблема есть о не никто не говорит это как бы проблема Ну как никто не говорит Тут есть интересная штука очень давно огромное количество людей которые думают в направлении которое вот я бы назвал это слово движок синхронизации концептуально Это идея о том что типа давайте как бы перестанем думать что у нас есть вот типа ннд приложения и приложение Дава признаемся что у

раден нормальная система синхронизации А раз у нас система синхронизации то нам по-хорошему нужно иметь нормальную как бы подсистему сервес синхронизации и S engine фундаментально что это Это идея того что у тебя есть отдельный процесс отдельный сервис отдельный там контроллер Ну как бы в зависимости от своего фреймворка который ответственен за связь клиента и сервера вот эта система она на на фронтенде в твоём фронтовом приложении есть отдельный сервис синхронизации в компонентах ты не делаешь феш напрямую Ты не работаешь с лами напрямую ты декларативное Какие данные тебе нужны и сервес синхронизации сам тебе их поставляет Ну Казалось бы идея очевидная у многих есть Папочка ipi Где собраны функции которые типа делают запросы но если мы по-настоящему серьёзно начнём думать о том что это отдельный сервис который этим занимается у нас будет революция очень похожая на революцию базу данных до того как появились mysql pog каждый разработчик свом приложении просто сам писал открывал файлы читал их закрывал так далее Это было нормально но вот как бы Когда ты один это делаешь ты делаешь самый минимум который нужен только тебе и поэтому типа качество работы с данными у тебя будет плохое Когда у нас есть отдельно выделенная система работы с данными которые мы начинаем передавать отно к другому у нас происходит взрыв потому что у нас теперь

единую систему синхронизации которая гораздо круче чем мы бы каждый написал отдельности и тоже самое происходит здесь как только мы говорим о том что это у нас распределённое приложение нам нормально нужно думать о связи клиента сервера У нас есть отдельный Для этого сервис Это не просто набор функций Это нормальный сервис синхронизации то как только мы это постулирует проект орный у нас резко происходит схо качества потому что мы начинаем просто добавлять ф синхронизации становится крутой интересной прикольной и самое прикольное что вот эта идея S andine она очень давно летает но оно как-то вот почему-то не может пробиться под софиты первый вообще проект который это предлагал - это вообще Couch db ещё до слово Local First это была база данных с которой ты работаешь на клиенте и она же в фоне синхронизируется с сервером немного в эту сторону думал gqq - это тоже система синхронизации это тоже S and Но вот почему-то наше сообщество не увидело в грали главное оно увидела язык запросов но не поняла что самое главный плюс граля - это было то что как ты забрасывает данные с сервера у тебя как бы это отдельный сервис который типа написан там ребятами за пола и работы gql сейчас идёт на спад потому что у него есть объективные проблемы скажем честно как sine он не самый лучший потому что он хорошо делает Ну типа относитель неплохо делает запрос данных но никто не продумал в нём как мы пишем данные на сервер поэтому это потом сделали через Хаки там всё это сделано Не очень хорошо и вот как сейчас бы пошёл на спад в ql но вместо этого мы к чему вернулись мы при вернулись к react query сейчас он называется Господи они переименовались Да Дада Я помню тоже да там цело причём там не один продукт а Целый набор там какой-то да Угу Это это прикольно они Молодцы для маленьких проектов это хорошо но мы забыли вот ту мы выкинули эту крутую идею того что у нас есть отдельный движок синхронизации нужно пояснение небольшое добавить потому что ты быстро прыгнул в техническую часть Я побуду нашим слушателям я правильно понимаю что когда ты имеешь в виду ты имеешь в виду всё-таки это же тоже Техническая штука Но главное - это цель и о чём мы говорим мы сказали с тобой про кружки именно потому что на каждое изменение каждый запрос тут же идёт взаимодействие с сервером то есть концепция движка синхронизации Он решает какую проблему Что у тебя приложение продолжает работать и оно взаимодействует с локальным клиентом то есть самое главное разделение на этом уровне Да вот то есть короче как это проявляется да ту смотри значит не все решают проблему крутилок потому что - это очень Широкая вещь но как только у нас это есть мы можем например в зависимости от приложения огромное количество приложений Вот например Google серс заметок мы можем просто зашивать все данные локально положить их на диск ты открываешь сайт он грузится через и нет на локально па загружает

писать такую систему сложно каждый раз но если это уже бы вынесли это в отдельный элемент то мы будем просто использовать готовую систему которой уже написано и соответственно Когда нажимаешь на заточку у тебя все данные локально прог она мгновенно открывается потому что данные уже есть ты меняешь её данные сохраняются локально и фоне сизи

ено иги туки ЕС У нас есть отдельный сер синхронизации то мы можем реально вкладывать много сил с базами данных е там реально того как работает индекс и так далее никто для одного приложения такое не написал А когда это готово всё работает

концепция у них концепция что мы по эвристика пытаемся предсказать Куда ты пойдёшь Какие данные тебе потребуется и мы их заранее каширу приме что делаются Да при делаются они обещают Ну типа понятно что конечно маркетинговое обещание но можно представить что там можно к нему дойти Они обещают что 99% случаев данные уже будут в кэше это открыты вопрос можно Дону мне каже 80% в концепту борется с крутилками и по крайней мере вот типа в каких-то демо элементах Она работает это пока не готовый проект Но это направление движения да то есть как только мы говорим о том что у нас есть сервис синхронизации у нас открывается возможность вбх туда кучу ресурсов И следовательно получить кучу фич сразу вопрос чтобы немножко это связать с реальностью то есть вот мы концептуально то есть подводим итог Да вот При таком подходе у тебя приложение работает локально и оно по сути в неком асинхронном режиме взаимодействую с делегирует эту работу На специальную штуку которая умеет классно это делать И тут возникает вопрос она с собой то есть её связь грубо говоря Вот например у меня ре или ещё что-то её связь со стейт менеджментом там это ты позыва под себя какой-то прям полный реплейс или должны быть адаптеры То есть как идёт взаимодействие с стейт менеджерами первый важный момент S - это цель а не средство поэтому как бы не все из них имеют в фоне систему синхронизации имеют локальную копию данных но большинство из них потому что это самый логичный самый правильный способ это делать но важный момент S Engine - это просто идея того что у нас есть отдельный II с которым мы декларативное действуем этот II Такой типа широкий с кучей возможностей который типа не просто набор функции А это что-то созданное нормально работать а как оно обычно интегрируется с фреймворка чаще всего это сигналы это йт менеджер какой-то который реализует паттен observable ты когда декларативного компоненте говоришь что мне нужны все пользовать начина на букву а она тебе возвращает например на который подписывается твой компонент и который рендерится в твой интерфейс всякий раз когда эти данные меняются у тебя соответственно меняется интерфейс То есть у тебя база данных локальная подключена через менеджер какой-то к твоей системе межер обычно внутри вот этой базы данных СП типа особо не замети там обычно такие функции типа такое туда передав возвращается вот знаешь с выборкой чуть сложнее потому что вот я когда думаю что если ты прямо сейчас что-то открыл Я просто начну с записи записи проще то есть вот если у тебя что-то типа Google доков в в сингл моде или замета Как ты говорил тут вот кажется это просто идеальный кейс на котором можно объяснять и пояснять то есть тут в принципе делать не в таком режиме пользоваться это будет невозможно да сразу синхронизировать Кстати ты не поверишь редактор же хта он же по сути то же самое делает Ну то есть вот ты пишешь код мы не имеем права если сервер умер никто не будет тебе там запрещ работать и что-то делать но там это реализовано немножко по-другому то есть знаешь как мы это сделали Ну опять же у нас во-первых инструмента нет как ты говоришь А во-вторых мы всё-таки коммерческая компания которая просто наши обработала там реально просто есть автосейф то есть у тебя стойт по сути это содержимое файла и оно если меняется Неважно как оно в промежутках меняется главное последнее состояние Поэтому у тебя просто на фоне есть процесс который раз в три секунды смотрит есть апдейт послал его на сервак вот ну и там отмечается вот что-то типа такого Да это такой типа на коленке я назвал на самом деле в куче компаний уже есть Уже куча есть решений просто пока вот как бы этот майндсет он не очень популярен многие его пишут но не знают как его делать тема у нас Local First Local First - это новое слово я за года до First рассказывал про свой который тоже является стом который называется соответственно я там не помню вноса рассказывал ко мне подходят двое ребят и такие Да у нас очень похожая система внутри реализована то есть вот всё что буду рассказывать это уже написано в ЧМ проблема что у нас нету понимания дискуссии слов для этого что у нас нету фрейминга чтобы описать эту систему чтобы о ней правильно думать чтобы е правильно выбирать чтобы когда ты начинаешь новый проект понимать что это она тебе нужна Давай дальше Т это какая-то штука что-то делает она может делать это правильно и в итоге у нас интерфейс Работает Круто есть конкретный пример

это супер конкурентная среда и единственный способ Ну там не очень много способов для них выжить это стать удобнее остальных И для этого они решили стать как будто нативное приложение и поэтому вот можете посмотреть есть куча интервью с ними Они начали с того что они написали хороший их приложение летает то есть реально Ты запускаешь его оно мгновенно работает это прямо совершенно другой опыт И огромное количество людей выбрали их вместо огромного Кост конкурентов только изза скорости рабо того что э крутило это руто ят Извини я должен про это сказать когда значит ушёл работал довольно неплохо всё-таки Мы перешли на российский проект я не скажу какой вот эта проблема там настолько серьёзная что вплоть до того что ребята говорят Давайте откажемся перейдём куда-нибудь ещё вот это видео которое мы сейчас делаем У нас есть чатик с их продуктом Я вырезку из этого видео отправлю Ну к тому что проблема реально серьёзная и люди которые с этим работают они задолбались вот мы задолбались соотвественно смотри как получается изза того что есть позво аккумулировать силы в один движок и потом его на куче проек использовать поэтому он становится умнее онла он работает круче и с ним работать пользователю приятнее потому что меньше крутилок круто но для программистов Такие блин снова какие-то сложности снова Надо что-то разбираться и тут самое удивительные Вот почему я так сильно верю в это всё И почему там ла писал и так далее когда я впервые столкнулся с я вдруг понял что главный плюс от этого это не то что крутилок нету пользователям удобно то что это как-то правильно и так далее самое главное плюс - это то что быстрее писать сайт потому что вот сейчас мы в любом компоненте императивно описываем как мы работаем с сервером при этом поскольку мы императивно мы описываем это Херо например Мы один раз идём на сервер Если всё упало Ну типа неудачно как жаль перезагружать страницу Да Окей это ничего страшного другая проблема что это каждый раз нужно думать это каждый раз нужно писать и приэтом каждый раз когда делаю любую форму думаю о том как я буду отправ запрос нар я понимаю сделаю это правильно что она всегда будет сделана плохо потому что у меня нету времени Ну типа на каждую форму писать это правильно и самое крутое вне это не только мои слова то же самое обнаружили line что когда ты его написал у тебя вдруг разработчики начинают писать код быстрее потому что они пишут только UI они больше не думают о работе с сервером и Мы возвращаемся к нашей первой теме что мы как программисты должны думать не о красоте а мы должны думать о том как ускорять скорость разработки чтобы мы могли сделать больше бизнесов за ограниченное время чтобы мы могли как бы больше автоматизовану типа чтобы большим людям было хорошо и вот то что у нас из-за того что у нас есть sink and Gi вдруг появляется ускоряется сильная скорость разработки это вот очень интересно Я вот недавно был на конференции Local First в Берлине прошла первая конференция Lo F там было много людей и Что удивительно там много реальных бизнесов рассказывали при фундаментально все собрались чтобы послушать о том как мы Вот боремся с систе какие мы крутые короче пот кровь но мы всё равно сопротивляется А большинство людей в первую очередь что ра сказали что стать стало быстрее писать код что мои разработчики счастливы потому что огромный Пласт работы выкинут из головы и вот это самое главное sinking J - это в первую очередь бизнес штука которая усет разработку поставку бизнес фич потому что у тебя все вся работа с сервером инкапсулированный сервис который ты как бы пере используешь между проектами звучит как правильный способ убрать случайную сложность Да и мы убирали не тем способом я правильно понимаю что когда ты говоришь про вот эту сложность во многом это связано именно с отсутствием распределённое А значит вообще в принципе ошибки их обработка и вот это всё Оно просто уходит на другой уровень тебе не надо на этом уровне думать об этом Или это не совсем так это это да это есть Но скажем честно большинство программистов в современном веб-разработке просто плют на ошибки и так о них не думают Да Да поэтому Ну типа вот есть два уровня значит если раньше писать хорошо форму это просто вот каждый раз типа стирать в кровь руки то сейчас это стало Легко но так никто не делает всем плевать на самом деле Но даже второя вещь даже вот просто программист который ни о чём не думает просто ёт фещ там типа разберётся любой сетевой запрос возвращается с ответом Да как-то на моём компе локально когда сервер запущен локально никаких проблем нету всё работает даже когда ты вот так думаешь всё равно у тебя просто куча императивного кода то есть вот С чего начинается sink and Giant что у тебя декларативная работа с данными Ну типа тут немножко напоминает Гра ql где они сделали первый шаг но на самом деле в других движках синхронизации всё ещё дальше Давай просто вот быстренько этот фантазируем в голове То есть например я редактирую текст заметку Да я поправил заметку У тебя значит Ну не на каждый символ Да мы там на с какието периодичностью мы взяли это изменения дальше я просто кладу его в свой Ну я просто сейчас фантазирую поправишь меня Да так кладу в стейт менеджер дальше там есть подписка соответственно он видит это изменение и он его утягивать к себе и сам его правильно там раскладывает в опиш шлёт на уровне кода это выглядит Так у тебя есть компонент заметки вверху ты пишешь Ну типа для реакта там например noe равно use Model и дальше там Note ID она тебе возвращает твою модель при этом эта модель может быть со специальными типами где ты должен явно проверить что модель уже загрузилась либо это ising либо это твоя твои данные модели типы заставляют тебя вспомнить что тебе крутило нужно сделать соответственно ты её рендере и когда пользователь любые изменения вводят У тебя есть какая-то функция котороя ты в эту вот заметок обновляешь А ну то есть всё-таки ты пользуешься Не стандартным US State и стеймс ты начинаешь через эту модель всё-таки у тебя свои отдельные хуки которые внутри имеют свой стт менеджер в котором есть зашивания копия данных обычно всё я понял то есть тогда получается что всё что мы ещё говорим К тому же звучит примерно так ребята все стейт менеджеры классные весёлые которые сейчас разрабатывают и будут делать Всем спасибо расходимся да Ну не совсем нет как бы во-первых важный момент в большинстве движков синхронизации используются Ну типа нормальные стет менеджеры вот у меня есть Т менеджер на астора и он создан специально чтобы использовать в моём движке синхронизации Гак тебе всё равно нужен типа стейт менеджер Да приэтом смотри как получается да У тебя же вот как бы есть тот стейт который вы шарите как бы в вашем Облаке Да ну типа в вашей репной системе Ну сервер имеется в виду ла Давайте типа обычными словами А есть Т который чисто локально который всегда локально который никогда не шарится и понятно что для него типа тоже требуется Ает менеджер мне конечно же Как автору на нарав приятно что у меня типа и локальный стоит на нарах и глобальный стоит на нарах такие штуки стати из других тоже стт менеджеров иногда они как бы дают тебе твой локальный стет менеджер но не всегда иногда типа можно комбинировать Ну это на самом деле не так важно потому что все менеджеры сейчас Ведут к сигналам Ну к тому что это observable который Ну типа понятие сигнала - это сложная концепция термин его неправильно как бы использует Но это который как-то правильно слушается ревом желательно напрямую запоминая где это в каких дох использовался этого в реакте нету но например вот сигнал он так работает но короче в любом случае неважно скоко менеджеров это ВС фигня потому что у тебя как бы вот есть данных общих серве

случае довольно значительная часть логики уходит Вот на этот специальный йт менеджер Да который правильно буду называть в s eng eng в таком случае вот эти все рас прекрасные хитрые йт менеджеры вообще имеет смысл использовать Я просто потому что кажется как будто если такой большой блок от них убирают тебе как бы встроенного в тот же самый реак йт менеджера вот выше головы будет Или я не прав да не да да иногда хватает иногда нет зависит от этого от стиля написания приложения я вот считаю что вообще вся логика приложения должна быть менеджере для того чтобы её тестировать нормальными тестами чтобы ты запускал систему UI фреймворков только для того чтобы их отрендерить То есть я вот сторонник того что у тебя как бы приложение твоё бизнес логика это менеджер ты его тестирует - это просто СНК к этим данным Вот Но это мой подход есть другие подходы разные задачи соответственно действительно очень у тебя буде этого Т за гза что Лано сказал действительно же у тебя При таком подходе в общем-то и само тестирование упрощается ведь сильно потому что в таком случае у тебе не нужно там Помнить все эти синхронизирующий штуки ты наполнил правильно стор а и и в общем-то процесс работы у тебя сильно упрощается процесс тестировани поскольку у тебя декларативное описание работы с данными тебе декларативное описание обычно не требуется тестировать по крайней мере Юни тестами и как Следовательно твои компоненты они становятся гораздо ближе к глупым компонентам которые можно тестировать просто см тестированием рибу там есть ещё одна интересная штука Ты же на самом деле когда ты описываешь свои данные в движке синхронизации Ты же очень часто описываешь ещё и ограничение этих данных То есть ты очень часто описываешь валидации и у тебя очень часто валидации исчезают потому что они один раз описаны смотри бы да ну типа вот давай так смотри закончили теперь другой вопрос Какой крутой Какое задаре роши Т смотрит первый момен желательно сквозная хороший должен обеспечивать Тебе сквозную типизацию от фронта до бка Да ну типа это круто когда так второе Желательно чтобы у тебя было Ну типа желательно должен быть один источник Правды что ты в одном файле описываешь свои типы свои ограничения и для бка и для фронта тоже круто хорошо когда так сделано Соответственно что ещё по-хорошему чтобы когда у тебя есть движок синхронизации чтобы он работал в оффлайне точнее Нет давай по-другому чтобы там была система каширования потому что Тош кэша никуда То есть у тебя есть локальная копия твоих данных локальная база данных локально работает знаешь кстати вот мне слово кэш не очень нравится кэш - это всё-таки немножко про другою вид Да это когда ты просто вот это хороший момент на самом деле смотри в вло в вообще типа в ногих реализациях у них же был кэш изначально но очень быстро этот кэш тся всё сложнее и сложнее и то что мы используем свош Да это неправильно потому что на самом деле это локальная база данных но изза того что же поняти кша наши архитектурные концепции такие отвратительные что типа сложность раст стремительно этим нельзя пользоваться ну собственно это одна из причин которая погубила как мне кажется и по-хорошему Нам нужен кэш Да ну как собственно но нам нужен кэш который умный который обновляется который ревади И бах мы переходим к тому что нам требуется локальная копия Дан чтоль копия данным она есть неизбежно потому что у нас есть кэш нам легко становится переносить оффлайн потому что как только у нас происходит офлайн ничего страшного мы типа пишем обратно в нашу локальную базу данных когда появляется связь мы синхронизирует мы возникает вопрос типа как мы это будем синхронизировать А кто-то ещё туда написал это сложно Ну в теории Но если ты уже написал один раз там на 10 на 20 проектов Теда очень легко строить такую штуку кото называется это алгоритм автоматического разрешения правок когда несколько человек редактирует один и тот же документ есть набор алгоритмов Ну точнее есть типы данных в которых есть определенные алгоритмы того как их решать как эти конфликты разрешать автоматически и соответственно в зависимости от того насколько Там какой тип у теб данных ты выбираешь по сложности нужный тип описывается в структуре и у тебя твоя локальная база данных сама автоматом решает все конфликты Не идеально там есть свои ограничения Но скажем так для mvp этого хватит за глаза и вот и получается что как только вот мы ментально всю эту модель ради того чтобы самим тратить Меньше времени у нас вдруг качество работы с этими данными начинает быстро расти потому что мы S Giant пишем один раз а используем там в двадцати проектах нам выгодно туда вкладывать больше и больше фич у меня есть несколько вопросов таких блиц достаточно чтобы вот как раз знаешь у тебя накопилось объём теории и теперь я хочу немножко к практике свести Смотри вот предположим просто тупой крут да вот нет интернета локальная база данных syn Engine Я добавляю какую-то штуку в теории она может добавиться прямо просто прямо добавилась я снова оказался в списке этой сущности котора не знаю заметки я создал я вижу что она создана и потом может произойти такое что Ну когда появляется интернет оно мне напишет Ой не получилось а я в это время создаю уже другую И честно говоря как будто бы это выходит за рамки просто Ну понимаешь да это ещё интерфейс требует это требует логики какой-то Да вот это хороший вопрос то есть давай предположим Так что у нас есть Google Но с ограничени в 50 заметок больше 50 заметок нужно зап ть Да соответственно я на телефоне сдал заметку Я на компе создал заметку Но это было всё в самолёте появилась связь Ну и как бы кто-то переполнить создать заметку и тут есть другая Офигенная штука смотри поскольку у нас централизованная система работы с данными у нас и централизованный Интерфейс Это уже не на уровне готового Сидни Это обычно вопрос их интеграции но большинство при их интеграции в систему у них такой II что они например есть отдельный р со всеми ошибками неважно откуда они пришли синхронизации и они заставляют тебя просто сделать глобальный интерфейс ошибки синхронизации что у тебя например ю вверху в футере есть как бы такой ну как бы обычна крутило если происходит ошибка там она показывается окно с ошибками и эта штука тебе интерфейсы упрощает делать потому что мы сейчас когда делаем интерфейсы Нам же что нужно сделать вот любой форме крутило туда вставить потом А что будет если типа интернета нету а что будет если какая-то ошибка так далее ну ошибку валидации нужно ещ в форме делать но все остальные штуки мы переносим туда вместо крутило в каждой форме У нас крутило вон там сверху при сохранении Да у меня есть два дополнения смотри во-первых всё-таки бывают места когда реально нужно стопа е Тогда нужно там нет такой проблемы Вот вот здесь надо пройти эту форму дальше не пойдёшь это без проблем решается обычно в движках синхронизации есть который Тебе явно возвращает проз и ты соответственно Исходя из этого всё делаешь то есть э логика называется но всегда можно вернуться в пессимистичный Кто хочет знать про все эти паттерны оптимистичные пессимистичный блокировки очень рекомендую почитать книжку фаулера она называлась раньше архитектура корпоративных приложений както сейчас по-другому называется очень прикольная штука где вот много таких вещей собрано я знаеш се что пока вот мы с тобой разговаривали Вот про обработку ошибок Мне это кое-что напомнило и у меня всё-таки есть негативные опыты с таким подходом Значит когда-то давным-давно мы уже лет п наверно не используем но мы использовали ауру для была И всё И меня знаешь что там бесило что в амазоне что в Google клауде у тебя Ну ты что-то делаешь нормальный формы то есть теб ощущение такого классического Веба Да ну сделал что-то меня как раз-таки в майкрософте именно в ажуре бесило то что ты что бы не делал У тебя всегда всё хорошо и справо в углу появляется вот ровно тоже ты говоришь и что-то там происходит и я понимаю что как будто бы либо это универсально либо это было сделано как-то неправильно Потому что ты действительно не уверен ты пытаешься дождаться и ты такой О'кей там надо периодически проверять [музыка]

у тоже не универсальная штука и Надо смотреть по ситуации да Мы возвращаемся это тоже проблема оптимистично ЮА что оптимистичный U он не подходит для всех задач Потому что есть вещи кото Мы хотим уверены что мы всё выполнили Да там например не знаю оплата мы не хотим оптимистичный U в оплате Мы хотим ждать и уверены что всё оплата про регистрация та же самая регистрация кстати интересный момент есть офигенные кейсы когда ты можешь попробовать без регистрации А потом когда тебе понравилось ты уже постфактум платишь им деньги это типа очень интересный бизнес подход но это да это немножко ты показал хороший пример настройка облака тебе когда ты настраиваешь облако ты не хочешь оптимистичны UI Потому что ты должен быть уверен когда каждое действие было выполнено чтобы перейти к следующему потому что они взаимосвязаны тебе иногда нужны какие-то данные тебе надо что-то через консоль сделать А типа консоль она не знает что у тебя там оптимистичный UI да В таком случае Мы возвращаемся в пессимистичный UI и обычно опять же Это не проблема когда ты с этим работаешь У тебя есть промисы ты делаешь всё через промисы всё по-старому тоже можно там где это нужно но вот смотри есть другой кейс вот есть веб-версия редактора презентаций Ну ладно там Google Keep Да Google kip невозможно сделать с каким-то личным интерфейсом это просто Издевательство это ну как бы ты хочешь Быстро делать свои дела а не ждать завершения операции синхронизации поэтому как бы да есть разные миры Под каждый Мы выбираем свой я бы знаешь что добавил я вот замечаю что есть прямо класс вещей помимо там именно редакторов Какие бы они ни были я бы ещё наверное даже обобщил частичное обновление это интереснее чем редактор Почему Потому что у тебя может быть сложная большая форма где ты по кускам обновляешь короче это не простая штука да Если ты это делаешь сам это ты просто обалдеешь и поэтому здесь выглядит как ОК но тогда Смотри вот здесь Следующий вопрос который хотел спросить вот действительно если такая части я вот хоте бы перейти как раз на уровень связи см и про то как проектируется вот предположим сложная форма Я частично е обновляю правильно понимаю что у тебя как бы каждый апдейт это будет некая мутация Да которая будет идти фактически неким отдельным запросом не всегда вот тут мы Пора к ситуации того что синнов много то есть ничто не мешает в сикей вернуть тебе черновик который ты потом сохраняешь То есть у тебя может быть черновик я вот нахо сделать этого пока нету но как бы запрос на это есть Да давай вот же ближе к МСУ движки синхронизации есть вот движок синхронизации который Я рекомендую начать это ль он даже на самом деле в НМ нету движка синхронизации что это такое Это движок синхронизации но ориентированный на быстрое создание бизнесов Поэтому у него есть реализация по умолчанию То есть ты когда делаешь прототип у него есть файлы описание данных схема что вот есть пользователи Есть проекты внутри проекта может быть пользователь нути всё что мы ба данных делаем а потом ты ему говоришь подними сервер и отвечай мне а я сейчас на фронте На фигачу интерфейс у тебя все эндпоинты генерирование автоматически само собой Там нет ни валидации ничего это просто абстрактная штука которая ну которая тебе позволяет быстро накидать интерфейс и после того когда накидал интерфейс ты идёшь в рель уже на сервере и там делаешь хуки которым определяешь права доступа к данным авторизацию делаешь Делаешь ограничения на на данные делаешь какие-то более сложные возможно хуки которые типа делают какие-то очень сложные проверки но на уровне прототипа у тебя REM тебе сразу даёт готовый сервер который все данные тебе в Чике сохраняет и для прототипирования супер круто но который слится до какого-то уровня дальше но это в ситуации когда у тебя нету бкн то есть это будет nodejs сервер который подключается там библиотека она гибкая Но это для нового старта это в основном для такого локального бизнеса где будет тонкий серр Да это вот одна система О'кей а перейдём как пойти дальше Вот давай Ещё раз чтобы зафиксировать то что я даже у себя чувствую у меня вот если ты спросишь чёткое отличие там разных вещей друг о друга я могу не ответить что я имею в виду Давай предположим я тебе скажу Слушай ну я же могу То же самое сделать с фаем я беру fif я беру openi и более того там есть штуки которые говорят типа прям вот фига мне полностью готовый сервак на базе этого отличие в чём будет именно у этого проекта Отличие в том что ты не привязан к конкретному облаку в том что это на самом деле локальное приложение который у тебя запущена локально опенсорс ная полностью ты контролируешь и ты потом если надо одной Командо его плоешти хочешь не я имею то же самое про fastify то есть вот если я беру fastify Open API и клей там есть адаптер знаешь который берёт Open API и делает ровно тоже самое он делает НПО и даёт колбеки Ты не поверишь я просто недавно прямо это смотрел которые вот прямо ровно Один в Один делает но я правильно понимаю что разница-то именно не в этом а именно главное здесь не то что сам сервер есть Амен что у тебя всё равно это движок у тебя есть фронт

то есть она открывает Ну и так далее там короче куча можно закрутить то что это по сути обычный рест получается да в который надо ходить но чисто технически он выглядит очень похоже потому что говорю сейчас такие штуки делаются вполне возможно в какой-то момент появится fif клиент это будет тоже самое то есть как бы вот эта концепция она как бы много где сейчас начинает использоваться Да просто такие же штуки на самом деле были для Например амазона я уже забыл както дата блоки называется не помню у них была такая готовая штука которая реализовала что-то похожее со своей базой данных но как бы систем таких много но мы вот типа вопрос в фрейминг что мы чётко говорим что это си Giant вот конкретно муль sink and Giant чтобы быстро поднять бизнес прикольный клёвый ориентированный на JavaScript знаешь что самое смешное Вот реально А прямо можно на мне это посмотреть как это работает вот я открыл му когда ты мне его прислал Да ещё до вот буквально перед тем как созвониться и вот ты не поверишь я я пытаюсь быстро понять какую Он решает проблему Я вот смотрю а и они ну не смогли до меня этого донести потому что вот я увидел от fif я увидел что он делает то же самое я думаю зачем мне брать их Если fify делает то же самое у них как-то слишком большой фокус на бке в в этом Без объяснения знаешь вот это именно этой коммуникации К сожалению рель это проект одного человека там в общем Ну типа там есть проблемы с маркетингом я как раз с ним встречался одной конференции пытался ему объяснить куда двигаться самый лучший способ понять мульт - это посмотреть его а доклад потому что это реально вот помнишь когда риса анонсировала Как написать свой блог за 15 минут то же самое Вот у него Как написать свой to лист с живыми обновлениями с пло он прямо типа там же плот Но типа за 40 минут и вот только на этом докладе наконец-то увидел вот тот старый те старые задачи которые мы решали рельсой Как быстро делать бизнес а не типа играться с технологиями Ну ладно это один это типа вот такой самый возможно стандартный последний вопрос чтобы вот прямо картинка у меня сложилась Я кстати Надеюсь ребята вот вы напишите у вас возникают ли таки вопросы по ходу дела потому что у меня вот постоянно они возникают Это буквально последний Правильно я понимаю что вот Судя по всему что ты сейчас объяснил получается что просто поешь пока мы говорили у меня всё время в голове было а там rpc А там СТ а там что-то ещё Судя потому что говоришь я делаю вывод скорее такой вообще без разницы что там потому что у тебя всё равно клиент скрыт и клиент реши То есть как вот решил человек так и будет ну создатель библиотеки Да именно конкретный протокол очень сильно отличается и очень часто он меняется в зависимости от задачи для тех где у них есть готовый сервер Вот например ult у него может быть соответственно rest А может быть websocket это всё встроено ну типа он автоматом у него сервер по твоей схеме сам тебе создают все эндпоинты там на самом деле довольно много чего создаётся там Open API спека создаётся там ре создаётся и что-то ещё и играв создаётся а но фундаментально как бы такие штуки очень часто много протоколов они не важны но мы всё равно сейчас будем о них обсуждать сравнивая конкретные решения ult ориентирован чисто на в первую очередь в там дополнительно приручены есть другой класс это движки которые являются системой синхронизации базы данных когда у тебя есть одна и та же база данных на клиенте и на сервере и соответственно на само Ну как бы вот вот знаешь у нас же есть мультимастер синхронизация базы данных так вот синхронизация сделана через мультимастер синхронизацию базы данных когда у тебя есть локальная копия данных

и они синхронизируются через прокол такое решение например как я уже называл они сейчас типа вдохнули слово начинают его развивать это firebase и это очень интересный проект SQL в SQL они пытаются сделать вот из поса они сделали PG это офигеют должен м знача потому для запустить в браузере и он будет сохранять данные в индекс ADB или на диск но он ещё интересен для н разработчиков Потому что знаешь когда ты н пишешь обычно тебе в докер нужно отдельный докер с базой данных в который поднимается огромнейший постгрес в котором настраивается пользователь Вот это всё короче а тут у тебя удобство SQ лайта Но для постгрес То есть ты локально разрабатывая без сервера просто как библиотеку из своего бэнда поднимаешь базу работаешь с ней А например в деплой уже работаешь настоящей большой баз данных как отдельный сервер Правильно я понимаю что в таком случае у тебя во фреймворка в бке новый адаптер не нужен просто его надо натравить на этот файл или там всё-таки нужен новый адаптер обычно это всё таки Ну типа обычно используется любой orm И для этого орма технически это разные адаптеры для обычного греса и для постгрес из файла для PG ко другой да да конект другой Но типа это обычно как бы другая функция где ты передаёшь путь а не набор вот этих типа не URL подключения иногда даже там URL типа такой же Наверно стоит в двух слова сказать почему это полезно потому что во-первых SQL не равно по возможностям Да гсу там реально даже с индексами разные фишки есть и с регистр зависимостью и так далее плюс просто банально одно и то же да ну и видишь слайм у тебя есть скейлинг то есть ты на сервере можешь не использовать вот как бы sqlite как отдельный как процесс внутри твоего А ты можешь реально понять базу данных нормальную Со всеми преимуществами понять е на отдельном сервере где там у тебя огромный SSD то есть у тебя вот для поса огромный скейлинг от супер требовательных до локального запуска можно сделать с лайтом при этом самый прикольный момент с PG лайтом там работают расширение То есть можно туда загрузить PG Вектор при этом запустив его в браузере через web assembly То есть это прямо Супер Круто слушай интересно какая матрёшка получается но при этом Несмотря на то что он база вроде как по факту получается в браузере это интерфейс к ИКС db Ой Господи Нет это это база это база это нормальная база а и он просто синка умеет ещё и с базами пря в браузере Да чтобы вот дальше интересный момент как синхронизировать данные мульт он просто посылает текущий стейт Но мы же понимаем что вот если мы посылаем текущий стейт мы далеко с этим не уйдём Почему Потому что теория относительности у нас на самом деле задержка неизбежна между любыми операциями это просто следствие ограничения хотя бы этого скорости света но если у нас есть задержка Значит у нас будут конфликты и по-хорошему возможность конфликта вопрос просто Нако большая и поэтому кидать не вариант потому что мы можем перетереть и мы приходим очень быстро к тому что по-хорошему хороший синхронизирует ней а он синхронизирует операции Он синхронизирует что ты делаешь баз данных Ну опять же тут всё сложно тут есть такие половинчатые подходы есть подходы Ну неважно В общем на самом деле любой базы данных уже есть операци для чего для мультимастер синхронизации данных и собственно вот этот оло из нормальной базы данных ну типа из нормального по нормального берётся и отправляется по серверу тебе на твой сервер в SQL всё пока ещё не идеально всё готово они всё разрабатывают но фундаментально у них будет небольшой прокси между твоей нормальной пом и клиентским который будут решать задачи авторизации данных проверки типо ДОУ и

далел сказали о ребята вын сорсинг переизбрали ну это на самом деле Да это это он и есть и второе конечно А я чуть сразу об этом не подумал действительно Я просто думал сейчас ты мне будешь рассказывать что поверх этого есть система синхронизации а получается что она наоборот на на более Нижнем уровне это прикольно да то есть ты получается работаешь с базой полностью как с базой А вот дальше она внизу уже она использует обычный улок тот же самый который мультима блин Гениально это просто гениально просто легко и Гениально ты там очень быстро упр в то что по-хорошему тебе нужно типа сложнее вещи делать тебе требуется типа ну как бы оло более с детальными операциями но как бы для каждой базы данных там есть свой подход собственно firebase тоже самая штука У тебя есть какие-то особый конфиг в котором ты определяешь хуки на сервере которые Ну типа обрабатывают вот этот олог синхронизации и таких систем много вот как раз на амазоне тоже она делалась как база данных То есть у нас есть другой кластер сив - это базы данных которые синхронизируются между собой но есть ещё третий подход Вот это подход который я использую в лага который Давайте делаем не базу данных потому что очень часто вот мы как бы разработчики нам иногда хочется иметь нормальный контроллер который обрабатывает события нормальные события но у нас у нас на клиенте есть локальная база данных которое происходят какие-то операции мы их синхронизирует в лага как мы сделали Мы вот это операции Измени им такое-то

направляем не в базу данных сразу а мы их направляем в контроллеры и ты для каждой операции должен ты определяешь операции и для каждой операции ты определяешь контроле или ты можешь пойти на уровень выше определить структуру данных говоря что это типа да ну и типа и мы тебе сразу гнем набор операций и тебе нужно описать как их сохранить данных Но фундаментально что у нас есть контроллер У нас есть обычные операции те же самые экшены вре у тебя локально есть про структура кото меня заголовок но на сервере у тебя появляется экшн события изменился типа Поле заголовок на такое-то и ты у тебя есть хук в котором ты что угодно делаешь то есть это вот третий подход где у тебя он немножко ближе к тому как мы в рельсе работаем но вместо hctp запросов Мы синхронизируют у нас не по hctp запросам а для операций для операций я понял да что просто Новая мутация Неважно Что ты делаешь Новая мутация Слушай я сразу просто спрошу а у меня в голове Просто нарисовалась картинка количество таких изменений если у тебя много сущности какая-то более-менее гигантская Ну ты ты же не предлагаешь описывать мутацию Под каждый вообще причём даже например сущность у тебя может одно измениться два три поля пять сразу 10 100 Ты же не будешь комбинаторику тут генерить как это делается я так скажу для тех задач где я решал этого было достаточно потому что там не было Вот типа слинга по такому параметру но смотри В чём главная фишечка гакс в отличие от базы данных это вот именно просто коры синхронизируется с сервером что туда помещать это ты определяешь и ты соответственно можешь придумать такую систему операций в которых у тебя происходит схлопывание СХ объединение Ты можешь в любой момент сам на клиенте прийти в лог и почистить типа и как бы объединить операцию Создать новые и удалить старые Короче делаем та скрипте интерфейс с дю полями все и да как-то ВМ

Мы у нас есть огромное количество разных клиентов нам для каждого клиента Нужно было Вот создавать по-своему и как раз поэтому у нас система мы не могли пойти с базой данных потому что база данных всё-таки она предполагает очень строгое взаимодействие с таблицами Ну типа с какими-то конкретными у тебя строго определены Какие конкретные операции ты можешь сделать ты туда не вхн например оплату которая должна быть по определению пессимистично Да и так далее У тебя есть просто Лог в который ты помещаешься

а в сервере У тебя есть просто хуки на эти операции Ну и тоже куча магии скрыта Ну понятно да то есть ты у тебя грубо говоря не делается никаких дополнительных предположений ты можешь навесить любую логику и воспринимаешь это просто таким образом а синхронизация базы всё-таки навешивается на тебя ограничения что это база и тебе надо пытаться типа в линуксе всё есть файл Тебе надо каждый раз думать так как эту штуку поместить в эту концепцию да Вот соответственно идёт другим подходом типа более открытым но зато гораздо больше низко уровне работы ну ня А уже используют сокеты типа там опять же без разницы и типа ты можешь заменить на любой протокол но не было проще сокетов Это чисто типа вопрос MP Слушай Понятно Вот мы разобрали эти типы Правильно я понимаю что сейчас как будто знаешь выглядит как Дикий запад мы находимся в состоянии когда нет победителя и более того это только Ведь ты же наверно народ продолжает экспериментировать и продолжат всякое разное делать Окей можеш немножко расказать тогда ну собственно есть момен что очень долго не было нормального фрейминга народ создавал какието инструменты но было очень сложно было объяснить клиентам в ЧМ плюс использования этого все знают что такое знают что такое там не знаю но никто не понимал А зачем вот эти базы данных систе тянуть к себе на Клин и сейчас ребята в сообществе придумали фрейми

придумали сейчас внутри комьюнити родился другой фрейминг S and Gi соответственно как под множество ЛФ но мы сейчас КФУ попозже перейдём и в этом контексте у нас уже есть Как сравнивать у нас уже есть какой-то ментальная модель по которой мы можем понимать вообще как бы что это такое А чем оно отличается А чем оно отличается от других вариантов А где оно будет нужно и так далее да решения пока нету вариантов куча вот опять же как я говорил вот уже большие игроки подключаются потому что у трип кэша довольно крупные ребята и у них очень хорошая система которая явно ориентирована вот не на эксперименты а прямо на захват рынка потому что система мощная интересная но пока не почу поть она закрытая сорян Слушай а хорошо тогда получается просто чтобы не складывалось впечатление то что это вот всё новое совсем-совсем понятное дело уже давно существует Да огромное количество приложений которые в принципе по-другому жить особо и не могли просто проблема была в том что им приходится всё реализовывать самим и почему я про это сейчас говорю ну берём Google доки те же у да там да И вот возникает вопрос а возможно ли создание универсального единого слоя который удовлетворит всех или всё равно это разобьётся на много маленьких мирков не скорее всего это разобьётся потому что ну типа я надеюсь потому что не дай Бог это будет как в реакте будет одно решение для всех и типа неподходящее никому а потому что ну типа у нас есть разные очень разные задачи и типа под разным задачам нуж разные решение например вот есть синн джай которые созданы для того чтобы интегрироваться в существующим н когда кн уже есть то ты хочешь его как бы ну улучшить развить добавить с до слой синхронизации тебе требуется принципиально другая архитектура чем движки синхронизации которые пишутся типа для стартапов для mbp для того чтобы быстро накидать mvp вот та такая разница второй момент Ну ладно может быть холивар между базами данных синхронизация улога он там в какой-то момент разрешится потому что такой Мне кажется политически больше синхронизация но размер знаешь вот типа есть тебе иногда хочется движок синхронизации который будет работать в приложении пря пользователь туда заходит прям поработать и тебе поэтому без разницы сколько он весит потому что польз раз решил то всё как бы ему нужно дать все возможности поэтому тебе нужен лучши сини это офигенно работа а с другой стороны у На Кейс тиба на очень частоты просто на ссылку Кликаешь и тебе не нужно кэшировать все

данные все возможные твои репозитории хочешь чтобы он быстро открылся чтобы там какой-то очень маленький движок синхронизации быстро всё загорова сразу показал тебе страницу Ну и Мо може быть там фоне что-нибудь синхронизирован то есть вот типа кейс между страницами и приложениями это тоже должно быть два разных движка синхронизации Мне кажется там вряд ли решится универсально вот ну и таких уровней могу много придумать Вот ещё объём данных Дело в том что если у тебя мало данных например меньше 50 ГБ то ты можешь хранить их Ну типа в очень простых структурах данных в памяти Но если у тебя данных много Ну типа сотни мегабат гигабайт то тебе требуется принципиально другой движок сохранения этих данных такие системы есть то есть сейчас например вот для если у тебя много данных то для этого используется SQ который поднимается который хранит свои данные либо в индекс либо файло системе есть дофа сае смешное вфо

и всякий раз когда ты используешь который хранит свои данные скидывай их в индек у тебя все эти данные фо кидаются в е раз тебя ти два слоя Но самое смешное что такая Как зная конструкция гораздо быстрее чем напрямую использовать индек нар

индек никогда им не пользовался он как-то появился как-то прошёл оно вообще стоит того чтобы Нет это типа знаешь при этом типа это была хорошая идея была хорошая попытка там есть интересные идеи но я как человек который пишу под индек db Я просто не хочу чтобы другие люди страдали это типа там самое безумное там её сделали до промисов весь её API построен ближе на событиях Дома чем на промеса При этом при попытке завернуть это в промеса всё очень легко ломается потому что очень интересно событийная модель Короче это просто Проклятая база данных вот типа если вам нужно сохранить настолько много данных что они не помещаются в Local storage Я бы Вам сильно рекомендовал использовать SQ lite из We assembly это по-моему сейчас ну типа она весит серьёзно Но если вам нужно если у пользователя больше чем 10 Мб данных скорее всего ну как бы Это серьёзное приложение Куда приходит поработать польз подождёт пока скачивается база данных ну она прямо физически кладётся на диск да то есть её браузер кладёт сам то есть всё хорошо есть два варианта вот тут мы приходим к дикому западу К сожалению Почему движки синхронизации начали сейчас развиваться так сильно потому что появилось много новых II браузеров Но вот мы пока подошли на 95% чтобы по-настоящему хранить локально например 1 гиб данных сейчас это сложновато и работать с кучей разных вкладок это пока сложновато потому что нам нужно ещ од для доступа файловой системе поэтому сечас есть два способа хранения бого количества данных использования индекса db но индекс db используется тупо как хранилище страниц синхронизации То есть как хранилище ога базы данных а второй вариант это хорошая система но у неё есть проблемы с производительностью Потому что всё-таки эти страницы базы данных они скидываются не как файлы А как записи внутри для фаф это будет SQ а для Хрома это будет но есть другой более интересный есть возможность у браузера паку временную не временную типа анонимную папку браузерную папку и даст тебе туда писать и читать как угодно вот и это идеальный для того чтобы поднять нормальную большую базу данных типа потому что он будет тупо писать на диск писать на диск супер эффективно как это умеют делать баз данных правильно организуя страницы скидываю думая о фрагментации и так далее ноб в

томного читали один и тот же файл в один и тот же момент потому что мы когда думаем про Ну типа мы же когда работаем в браузере это отличается от локального приложения Потому что ты в браузере Можешь открыть несколько копий приложений Ну типа вкладок когда мы начинаем думать про синхронизации Мы же можем сразу заранее продумать как эти вкладки будут синхронизироваться и все движки синхронизации у них это обычно очень продумано очень круто у тебя единый стейт между вкладками если ты что-то сделал в одной вкладке Он мгновенно оказывается в другой даже без серве Ну типа вспоминаем интернет-магазины где ты значит открыл кучу этих товаров потом типа изучаешь закрываешь какие-то какие-то добавляешь а потом оказывается что там переписывалась и у тебя добавился тако последний товар все остальные товары переписали Потому что ты когда нажимаешь купить у тебя тий код записывает типа текущий т в вот движками синии такого нету когда на что ВНО ти мгновенно обновилось другой но из-за этого нужно думать о том как вот каждая вкладка работает и там используются всякие интересные техники например крутая идея была бы чтобы база данных тупо Ну как в каждой вкладке писали бы в один файл и синхронизировались но есть другой подход это провести выборы и выбрать главную вкладку которая будет держать соединение с сервером и держать соединение с базой данных так такой вариант тоже можно это легко делается сейчас есть готовы I pii для этого в брау У нас знаешь а я могу про свой редактор добавить Да вот представ вот открыва чек редактор Да есть ском и он может открыть его в соседней вкладке и честно говоря поддерживать нам Ну и там и там учитывая что мы работаем всё-таки больше там по классике Да ну там через сокеты понятное дело нуно в общем короче и там и там поддерживать Ну просто нет такой задачи и мы знаешь как сделали У нас очень тупое решение то есть новая вкладка становится типа главной А у тебя старая рвётся и старая прямо пишет что типа закры меня где-то ты ещё откры Да ну Собственно как как в телеграме было и так далее Ну это нормально когда мы пишем сами шки синхронизации но и тут Мы возвращаемся к идее того что один раз написать синхронизации мы Ну типа нам не нужно использовать грязные способы мы посколько пишем его один раз можно писать красиво правильно И надолго вот поэтому такой проблемы в лизации Обычно нет ну прям самых типа начинающих Угу Слушай вообще конечно Я такой думаю Смотрю на это блин как будто бы вот в нашем в нашем мере вот эта вся история Она довольно Прикольно у нас там В каком-то смысле не то что движок всех Нет наверное Слушай наверное Похоже мы же юзаем этот а соке у тебя всё асинхронно у тебя просто как фактически вот такие Диф отправляются Я думаю если чуть-чуть ещё добить получится практически тоже уже ближе к этому хороший движе синхронизации его минимальное определение - это иметь хороший прокаченный локальный кэш и декларативный API вот Обычно вот если эти две вещи есть это движок синхронизации можно смело называть его так да ну и соответственно мы бак вырубаем можем проверить даем в принципе должно плюс-минус

рать короче Давай затронем тему кэндо потому что бэнды могут быть на разном языке фактически эта штука приводит опять к очередном то есть в этом плане ре Pi кстати никогда не сдастся при всех преимуществах всего остального там ничего не надо Ты просто берёшь и делаешь поэтому что бы мы не говорили да у тебя всё равно Львиная доля будет там всегда А вот здесь у нас происходит следующее то есть две проблемы первое во-первых тебе БК надо Под каждый язык фреймворк даже какой-то адаптер видимо А второе что тоже очень важно типы потому что вот тут уже весело

да Что скажешь по этому поводу Да соответственно Есть несколько вариантов Первый вариант - это пойти по пути базы данных в таком случае ты на бке просто подключаешься к постгрес постгрес магическим образом обновляется когда пользователь работает а ты соответственно например этими Господи как называется функциями реагируешь на то когда изменяется таблица и вызываешь какой-то свой код то есть у тебя больше не веб интерфейс у тебя уже приложение которое напрямую работает с базой данных и ожидает кто-то эту базу данных изменит это вот звучит опасно не находишь не Не ну типа не опасно звучит по-другому так скажу что это уже не веб-сервер это уже типа у тебя наружу смотрит база данных ну типа через прокси само собой она типа не сама смотрит а а твой сервер он просто слушает эту базу данных чтобы не изменилось это по-другому так скажу у него на самом деле огромное количество плюсов во-первых тебе не нужно думать на бке о проблеме нагрузки потому что у тебя вот эти как бы воркеры вот смотри мы когда делаем У нас очень часто есть большая разница между контроллерами htp запросов и системой очередей это два очень разных паттерна очень два разных Как бы как бы это два разных приложения фактически это Чита два разных бэнда и фундаментально ситуации синхронизации базы данных у нас Мы выкидываем контроллер htp и оставляем только систему очередей у нас получается вся логика будет дела На сист очередей кото три из это один похо

они такие да Не давайте дальше там у тебя не будет единая систе типизации уних вс-таки криптос подразумевается поэтому там как бы своё решение Но вот в этой категории систем решений мы можем просто использовать как дальше и команда энда дальше создаёт обычный а клиент У него есть НГ типа и сам ходит вот такой ри

времена но мы на клиенте больше пишем нам нужно синхронизации есть другой вариант как вот мы использовали сксом У нас есть соответственно JavaScript приложение JavaScript backend но этот backend - это просто Проси который всякий раз когда через websocket меняется какой-то ключ в объекте мы идём по API и для того чтобы у нас были сквозные типы мы берм и используем схему Open API от энда по ней гением типы и эти типы передаём в лакс и создаём вот эту единую систему связывания где у нас от бэнда до фронта Единая система типов но она берётся из rest API из Open API схемы сейчас не хватает хорошего решения как готовый энд развивать в сторону Син джайна вот с прокси движком на лага мы типа пробовали нормально всё работает но как-то вот есть ощущение чтото немножко странно мне кажется вот как раз тот же Z кэша он куда-то туда смотрит но к сожалению не могу пощупать не могу понять и мне кажется там будет больше решений Ну вот пока вот такие решения к сожалению пока движ Синхронизация это чуть-чуть больше Фронтовая схема но не настолько хардкорная как была в grq то есть движ синхронизации больше думают о кнте но есть вторая штука Дело в том что очень часто например гле кипе нам не требуется Кэн Нам же очень часто когда мы делаем приложение есть куча кейсов Где на самом деле логику никакую не имеет и эта логика ограничивается валидации и так далее синии с разные устройства и очень часто в таком случае даёт тебе готовый из коробки и у нас просто нету команды в проекте что тоже нормально в ситуациях где у нас тонкий как я говорил у нас проблема в том что у нас и толстый клиент и тол давайте сделаем ситуацию у на толстый Клин и то очень часто в этой ситуации У нас ки backend но это мы поговорим в следующем секции про Local First я знаешь какую ещё штуку хотел уточнить перед тем как пойдём дальше про API вообще глобально то есть Правильно ли я понимаю что по факту это всё-таки речь идёт про приложение То есть когда мы говорим про API для подрядчиков Ну в смысле внешних каких-то консьюмер это там всё не используется там поняш что у тебя как правило rest API и погнали Ну или какие-то вариации Но вот эту задачу решает мульт и вот системы вокруг существующего пи то есть там это всё готово то есть он гнет схему которая ему не нужна типа просто чтобы ты типа мог своим там пользователям дать gql типа то есть вот у системы такая система есть но все остальные системы которые типа он строится на синхронизации й и поэтому в него легко интегрируется связь с сервером через потому что вс-таки это он строится нации состояния а системы которые синхронизируют операций очень типа из них плохо сделать API тебе в лучшем случае требуется какой-то прокси писать вручную который будет типа ре конвертировать операций Слушай я ещё понял Какую вещь хотел спросить вот когда мы говорили про разные энды что под них надо писать Давай обозначим связь с ффм потому что вот разные люди говорят типа ребят Ну и не надо это тащить ваше приложение на рельсе Да и там энд это отписать bff только bff мы выносим это всегда в ноду соответственно у тебя ty И вообще не паримся вот Ну вот мы такое сделали с ксом когда подключали КС к питонов скому скрипту там самое главное преимущество было из-за бфф потому что мы могли очень быстро накидать прототип именно вот интерфейс у нас был редактор диаграмм где ты рисуешь архитектуру своего приложения супер сложный фронтенд и у нас была проблема с коммуникациями с бэнда они как бы медленнее делали те которые нам нужно было и за счёт ффа мы сделали готовое приложение которое не сохраняло данные никуда Ну типа сохраняло в а потом мы уже его интегрировать с готовым эндом в котором была очень хитрая аналитика которая искала узмо в этой архитектуре соответственно вот эта система идеально легла на вот этот кейс а соответственно да такие штуки есть такие штуки можно использовать но опять же ну как бы есть ограничения Где их можно использовать потому что всякий раз пилить bff Мы оказываемся в ситуации где мы стали разрабатывать медленнее потому что у нас есть два приложения сейчас циг нас Я тебя понял Да но опять же есть кейсы где backend реально делают сложную работу которая никогда не окажется на фронте и вот в этом случае Действительно это Хорош и и мы хотим использовать какие-то свои языки программирования Особенно это хорошо ложиться на всякий Machine Learning где вот знаешь вот типа Machine Learning backend он прямо такой Волшебный по особому ему надо заворачивать на особых серверах и в этом случае как раз всё это идеально ложится на нодов ский движок синхронизации как отдельный bff frontend и отдельный сервис для там машин ёнинга либо какой-то вот странной фигни в странных типа закрученных штуках Окей Ты мы всё это время говорили синхронизация синхронизация синхронизация А теперь мы переходим Local First который мы много раз упоминали давай sine - это Инженерная составляющая это как вот эту штуку штуку там магическую штуку X сделать с точки зрения инженера Local First - это Зачем её делать А это политическая составляющая S и тут интересное явление что ну у нас есть объективные причины давайте так скажем программисты сломали интернет весь интернет умирает это просто жест типа куда мы его завели Давайте Так значит ну типа проблем куча главная проблема - это слежка потому что мы всё типа мы после того как появился iPhone стало понятно что локальные приложения не вариант потому что тебе нужно синхронизировать между ноутбуком типа телефоном и ответом на это были облака но из-за того что мы все данные вка за нами супер следить И поэтому очень оза ситуаци мы все под колпаком там неважно в какой строне это плохо Ну мы опять же мы про политику говорим Да второй момент что из-за того что всё в облаках как только облако выключается всё выключается вот когда венам перестали развивать мы могли продолжать слушать музыку через венам когда Google закрыл Google Reader мы остались без Google ридера потому что облака - это Ключевая точка Как только ты убираешь всё всё типа плохо соответственно таких проблем ещё много вот такие две Это мои любимые проблемы наполняющий болью и ребята из лаборатории и и swch они в какой-то момент работая вокруг вот этих всех прото идей движков синхронизации работа crdt это автомати чение конфликтов они вдруг поняли что на самом деле это всё ну и действительно вот я тогда же делал КС И вот во всём вот этом комьюнити которая создавала движки синхронизации данных и так далее было понимание инструмент разработки А это политическое вызывание и они это ВС оформили в конкретное тко политическое высказывание которое называется ти Да это есть с это и пошло всё это 10 принципов о том как мы хотим делать приложение концептуально это как бы можно так представить что вместо того чтобы выбирать между облаком и локальным приложениям втом пни обычно через То есть у нас есть то есть у нас есть набор операций У нас есть локальная база данных это локальная база данных синхронизируется с сервером сам сервер очень тонкий просто синхронизирует данные между клиентом и на каждом клиенте У тебя есть либо полная копия либо слепок е небольшой и всё это желательно но не обязательно можно завернуть в ту шифрование Так что сервер не знает чем синхронизируется А есть очень хороший пример как вотже и э технологическая концепция выглядит в реальности есть соответственно notion Все любят notion Ну давайте говорить про notion для базового пользователя без автоматизации да типа как набор заметок это клёво это прикольно но н знает все ваши заметки он типа обучил свою Нейрон на неё и скажем честно это местами кринжово и крипово во-вторых нет интернета нету заметок он закроется ну всё ты приехал Ну типа таких проблем много и есть другой альтернатива это приложение obsidan а опять же мы не сравниваем с ном для бизнесов сравниваем сном для типа обычных пользователей что это такое обси обси работает Это приложение которое работает с папкой на вашем диске все ваши заметки - это Mar файлы в этой папке И как вы синхронизируется эту папку без разницы у обсидиана есть бизнес-модель они продают готовый сервер синхронизации Если вы хотите синхронизировать через них вы платите там 5 баксов в месяц но если не хотите синхронизируйте через Google Cloud синхронизируйте Через что угодно и получается что когда там обсидиан разорится кроется и так далее У тебя есть локальная приложение которое щк которые ты скачал и у тебя есть синхронизация через любую файловую систему через resing через git и так далее и ты сможешь пережить существование их сервиса и при этом это мадаун ты можешь перейти на любую другую приложение Знаешь ты меня натолкнул на одну важную мысль А знаешь я недавно о чём думал вот менеджера паролей Да существует большое количество разных менеджера паролей которые можно себе поставить у в вспоминаю време когда я пользова и у тебя Файлик просто его клал вбо Да и соответственно окал по там интерфейс стрёмный там много чего нет и так далее но я просто думаю что блин а ведь по идее в таком случае должны появиться инструменты Потому что если будет использоваться там же проблема главная начинается когда у тебя много клиентов то есть вот для команды это ты используешь да у тебя соответственно если ты кипа положишь Скорее всего он покатит файл насмерть Там же ещё вопрос того как собственно Вот это рает дропбокс в Google драй всём можно реализовать такую систему вот так потому что я просто сейчас думаю если бы такая штука была мы бы наверно для компании Очень вероятно на неё спрыгнули потому что вот например ставить там себе полноценный сервак Вот это всё честно говоря тоже это вопрос большой Надо ли и хочется ли тут Офигенно Смотри значит во-первых поскольку у тебя Local First приложение То есть у тебя есть локальная база данных на клиенте Это означает что на самом деле ты всю логику приложения может принести на клиента сервер только синхронизирует данные поэтому сервер уже получается Лем это это кстати открывает офигенные преимущества с точки зрения бизнеса Потому что ты можешь написать прототип Невер на самом деле у тебя как бы ты пишешь приложение Так что оно будет работать в оффлайне и ты можешь написать прототип показать его инвесторам получить деньги делая полностью локальную версию а потом уже получив деньги нанять разработчика и сделать низации но

сам выступает вообще интересная мысль важный момент мы не можем использовать силицию через файлы всегда потому что действительно конфликт чтобы шать конфликты намм нужна сиза через ло операции и внутри Local First Community сейчас буквально год назад один из создателей этого термина клеман объявил нашу фундаментальную цель Как коммьюнити как политического движения договориться о протоколе синхронизации его пока нету Есть только саевы прототипы Например у этого Никиты есть хорошая идея там нету правда чистки Лога но ЕС не зада чист ло У него есть идея как на разных файлах это сделать но тем не менее короче вот сейчас Local First Community думают про единый протокол синхронизации на которой можно делать любое приложение это будет очень интересно потому что ты как бизнес можешь сделать свой приложение а пользователь сам выбирает движок синхронизации локальный там что-нибудь типа нужно для своей страны и так далее То есть Очень интересный мир открывается когда мы начинаем думать об этом Ну как обычно в таких всегда есть недостаток О чём можно сразу думать Это всё что касается перформанса объёма данных и так далее скорее всего будут ограничения но наверное большинство приложений бизнесов 99% будет работать прекрасно Да нет такого объёма данных Ну тем более видишь пока пока нет этих протоколов пока вот как бы э цель как у типа она была объявлена в этом году и поэтому типа статья выла чуть заранее Но вот прямо фундаментально тако типа это наша следующая цель была объявлена на Красном конференции в Берлине хорошая конферен супер да посмотрите наверное видео где-нибудь есть в блоге марсиан есть краткий пересказ всех докладов чтобы знаешь быстро вкатиться в коммьюнити с ссылками на все видео Я кстати вот хочу добавить Вот мы сейчас с тобой записываемся через мрд мрд в какой-то момент как раз давай так я объясню глобальную проблему которую ты точно знаешь все кто работал где-то выступал знает всегда была проблема Zoom что-то Ты ещё используешь у тебя была проблема в том что это видео интернет тормоза задница И соответственно поэтому все писали локально используя обс или что-то ещё и потом вот это вот я больше всего этого ненавидел потому что я много такого записывал кому-то этот файл через какой-то файлообменник скинуть да Господи боже задрала и сейчас вот это за последний год наверное два массовое появление инструментов Вот мы сейчас с тобой записываемся да и у нас по сути параллельно оно не только сохраняется на диск но оно ещё и параллельно алоди поэтому когда мы с тобой стапон запись ему понадобится секунд 10 наверное чтобы ну если проблем не будет котом чтобы он написал что всё загрузилось всё хорошо при этом локальная копия ещё остаётся Забавно Да как вот эти вещи они так или иначе вокруг нас просто повсеместно повсеместно это решает очень большое количество проблем Конечно есть ещё например этот Local First редактор презентаций он типа не Local First поне того что ты можешь как угодно синхронизировать Это скорее больше sine но тем не менее Он работает в оффлайне Ты можешь в самолёте делать презентации но делать это в браузере и типа когда появится связь Ну типа ты можешь выключить компьютер закрыть браузер все сесть на самолёте открыть ноутбук включить его Включить браузер он достанет твоё локальный Лок изменений из файловой системы и отправить их на сервер это Господи ну сечас не вспомню Ну как бы на конференции в Берлине как раз все большинство презентаций были Сделано в этом редакторе самое прикольное конференции было что вот я прихожу на конференцию и ну там ощущение что я среди чужих людей потому что мы на самом деле с ними шарим принципиально разные идеи нас объединяет что желание денег мы пришли в эту индустрию Потому что много платим

это конференция которая объединяет людей по схожим ценностям потому что у всех была вот единая ценность того что мы не хотим чтобы продолжал быть облачным мы хотим чтобы он был Local First это было супер Офигенно что снова разработка Она имеет какой-то смысл что ты наконец-то делаешь что-то полезна а не там помогаешь зарабатывать этим акционерам деньги у меня в голове сразу картинки хакеров восьмидесятых почему-то возникли которые Да идея свобода равенство упячка А вот слушай всё равно давай интересно про рек мы в начале с тобой затрагивали эту историю Да вот это вот движение а Куда идёт мейнстрим Слушай я вот даже не хочу думать потому что я потерял веру я я потерял веру в comity оно типа то что мы выбрали Один реакт на всех рек хороший Ну в же много Слушай а в то же самое фундаментальная проблема что мы выбрали SP приложение и на них делаем все типы приложений Но эти фреймворки хорошо подходят для SP приложений Сейчас слава богу есть HTML htmx Да вот я до сих пор считаю что куча бизнесов им не нужен react приложения им можно сделать рельсовое приложение они бизнес сделают в два раза быстрее больше денег за работат у них всё будет лучше у них поставка фич будет в два раза больше лучше с приложением у нас был реаль такой кейс к нам пришли ребята у них была админка для там докумен оборота которы ти Ну как бы менеджеры сидят локально заполняют документы это было сделано на реакте мы переписали на рельсу Ну мы тоже Нати пишем просто вот именно в этом кейсе мы вдруг увидели что это не нужно было делать у них энд был уже на рельсе и мы просто некоторые интерфейсы начали переносить на Ну типа ресу чтоб реса давала hml и в этом кейсе скорость поставки фи стало больше два раза я не просто в это верю Те кто меня слушают регулярно постоянно от меня это слышат о том что вот этот классический рендеринг это конечно по скорости несопоставимы вещи насколько это быстро удобно слушай вспомнил есть е два раз ты сказал про htmx не могу тебя не спросить все современные фреймворки кэндо вые так или иначе придумали о ва Live viw там ещё 500.000 названий ты считаешь ли эту ветку вот этих интегрированных решений тупиковой нормаль Тема да типа ну видишь у нас главная проблема что будущее разработки определяется не инженерно она определяется hpe D development мы всё Типа управляем хайпом люди выбирают зависимости исходя из хайпа и поэтому я не могу ответить на вопрос потому что толпа глупа так скажем и типа куда она пойдёт непонятно это может быть очень плохое решение то есть фундаментально так скажу а коллективное решение долгосрочное перспективе всегда конечно же ведёт к улучшению ситуации мы все все проблемы решим но я кучу раз видел когда мы возвращались назад теряли крутые направления кучу раз потому что качество толпы оно очень разное бывает и если вот эта толпа не само осознаёт себя не начинает вкладывать ресурсы в своё качество то её навык принятия решений может быть довольно плохим и её путь развития в какой-то цели будет идти сильно дольше и сильно типа теряя крутые наработки Угу Ну если короче делать вывод про вот эти штуки то в целом Вот это направление Оно просто своё по себе но ты его не считаешь как бы именно неправильным то есть оно наоборот Просто локально оно оно супер крутое на самом деле есть куча кейсов где они очень хорошо типа решают свою задачу У меня есть кейс в котором я познакомился с одной штукой которая мне немножко знаешь тоже такой сдвинула вот это понимание фронтенда того как я увижу Что я могу делать сейчас небольшую историю расскажу история там была примерно такая я для нам надо было написать одно приложение связанное с подачей документов довольно сложное там большая стоит машина много документов туда-сюда пинг-понг проверили не проверили визуальные всякие штуки ну в общем такое классическое бизнесов приложение и там была я выбрал для него Равель А у равеля есть свой собственный по-моему как раз называется Аля ха отвара Я очень быстро упёрся в то что там есть проблемы с динамическими формами Ну просто конкретно штука не доработана под какие-то сложные кейсы но мне очень то есть у меня было всего 2 месяца на разработку и мне совершенно не хотелось знаешь вот типа сейчас я тут API State менеджмент То есть я понимал что я этим путём идти не могу но при этом там есть фронтенд часть которая всё-таки классические круд чаще но там скорее логики много да и мне В каком-то смысле повезло что оказывается в лавеле конкретно для него было создан такой инструмент который называется инерция и мы с тобой по-моему даже е обсуждали да Или по крайней мере Точно вы Ну давай так ты не пользовался Я просто сейчас прикол в том что Видимо Вы у вас много в злых марсиана и вы не всегда общаетесь потому что марсиане в Твиттере было видно после того как я это написал я увидел что они инерцию Дже как бы продвигают я такой О во-первых я не один во-вторых реб то поняли я просто расскажу концепцию и для остальных тоже будет полезно там идея В чём а что это некая знаешь попытка использовать react но в формате вот классического серверного рендеринга там идёт история в том что а давайте сделаем так что у нас не будет API и стейт менеджмента то есть мы как бы на выходе рендерит react шаблон а то есть шаблонизатор верная знаешь как передача данных идёт как в гоне у тебя просто прозрачно от тебя сразу ты себе не представляешь я с таким кайфом написал приложение там конечно обвязки не хватает как В Рес но после знаешь месяца пыркакайского

[музыка]

я Слушай можно сказать что это S and Но с другой стороны это and для Толстого бэнда потому что у тебя есть готовая система когда как ты данные закинешь на на фронтенд дадада то есть там идея именно в том чтобы как раз чтобы клиента не было мне нужен только рендеринг больше ничего ребята Уберите всё остальное я не хочу писать API Я не хочу вообще ничего он есть просто скрыт он типа как библиотека готовая потому что там по-моему да ну типа вот я критикую ре я его критикую только в контексте того что нам не надо всегда что у нас есть несколько разных типов приложений есть там где большой есть там где большой Н И типа вот там где большой НН там лучше использовать там Local First там сфм работают только рек подобной системы потому что там невозможно использовать чтото другое Да есть мир где большой и проблема с реактором что мы его начали пихать туда или на статичные сайты которые нужно делать сейчас с помощью Астра качество нашей толпы деградировала до ситуации мы берм толь единое популярное решение только самое популярное решение и в итоге наша как бы толпа наша коммьюнити приходит к неправильным решением Когда у нас нету удобного инструмента потому что он удобен только для одной задачи из примерно п причём получается Смотри я ведь с одной стороны тоже использую react но по большому счёту я использую именно в том каноническом виде чистого viw и в таком смысле он не является для меня например проблемой потому что Вот 90% его функциональности я просто не использую оно мне не нужно мне нуже я бы там сл включил Потому что всё-таки большева для этой задача 100 КБ д скрипта 100 КБ Ну да да типа ну тут вопрос в том что я пользуюсь тем инструментом этоже вос Немного это кстати редкий случай когда используется вот в том назначени в котором он изначально предполагал приложение тоже норм потому что они как бы вс-таки писали его для Фейсбука когда у тебя есть отдельное приложение которое работает и общается см Проблема в том что мы типа хаем его куда не нужно типа статичный сайт это просто это ягда вот в принципе мы тогда по этому поводу проговорили про инерцию тоже если кто не слышал обязательно посмотрите док сделать сде в тте об этом пишут и они тоже прямо пишут Мы специально реализовали какие-то проекты использую её чтобы её популяризировать вот она отвели от вязана её можно использовать и с рельсой и со спринг бутом и много ещё с чем то есть они адапторы под это пишут знаешь что хотел тебя спросить последний наверное вопрос потому что ты говорил про клады я Мне кажется что как будто имел в виду Next JS и можешь пару слов сказать у меня негативный опыт использования некста Я очень радостно в него пошёл а потом я в это всё упёрся думаю да нахрен вы м нужны от вас проблем больше чем польз статичные сайты делать на нее это проклято Нет не делайте для этого есть Astra гораздо лучше это просто архитектурно лучшее решение у неста главная проблема - Это неправильный набор инструментов для статичных сайтов и в итоге это приводит к тому что у тебя перес стек который может спеть тебя кучу вещей но как только начинаются проблемы Ты не знаешь куда идти потому что он пере

усложнённые Неру HTML ровно это он и должен делать это супер крутая штука при этом динамические штуки туда можно добавить тоже но Next J сейчас хочет пойти в другую сторону есть ряд кейсов когда у тебя например есть и формы сложные и Ну типа где требуется много валидации и на бэнде вся логика и поэтому они сейчас идут в очень интересное направление которое ну типа то что называется сервер сайт рендеринг ощущение такое что nextjs всё-таки не вывезет потому что у них очень всё сложно переу сложено мне вот больше нравится как у квика это работает но я не уверен Кто там победит Вот именно в этом направлении а Серви сайт рендеринг То есть у некста есть какой-то кейс но Серви сайт рендеринг - это какие приложения Это например там какие-нибудь А интернет-магазины с кучей интерактивности Вот таких типа e-commerce где у тебя с одной стороны есть куча логики но которую ты не хочешь сделать на сервере которая должна делаться на фронте но одновременно с этим у тебя куча логики на бкн то есть где нам нужно делать и большой кнд и большой frontend там такое ощущение что вот у Севе Сай типа у Севе Господи react Server components есть хотя бы видение и концепция но тут упирается версии потому что это просто странная бизнес-модель Ну типа в ЧМ их бизнес-модель бизнес-модель наркомании мы как бы даём тебе бесплатно первую дозу ты поешь на неё у нас все сервисы построены как и когда ты вдруг резко взлетаешь мы тебе придём приходим с предложением кото ты не можешь отказаться потому что ты не можешь съехать Вех били

ного ни есть тариф бесплатный тариф немножко типа небольшого размера а среднего размера Нет почему Потому что ты договаривать с ними Они называют ту цену которую они хотят это просто опасно сделать бизнес таким ребятами при этом честно говоря в моём опыте у гораздо лучше сервера чтобы генерить статичные чтобы запускать сборку статичного контента у

них понят что я скорее неправильное приложение для него выбрал Да я знаешь я именно редактор пытался на нём сделать думаю дай-ка попробую как тол ский клиент У меня естественно весь Ну какой нафиг редактор с серверной генерацией Да там Монако эдитор там всё просто То есть мне во-первых пришлось это везде вырубать во-вторых там были нужны веб сокеты там это не работает нормально Они переходят на новый роутер он тоже там половина функциональности не работает и Я что-то почитал посмотрел и люди тоже все очень сильно плюются и плюс логов Нет дебага нет я банально Не смог серверный Лог включить я та ребят Ну что такое в общем в моей жизни Next J наверное для них есть Рынок но Этот рынок гораздо меньше чем компания Вель создаёт потому что у них офигенный маркетинг один из лучших технических маркетингов в мире и они искажают типа у нас очень большая проблема самосознанием нашего коммьюнити и они этим пользуются и у нас очень странно перекошенный мир где все говорят про верси все говорят про nextjs притом что он подходит очень специфичной группе приложени да Дада потому что опять же повторюсь я последние годы много не пишу код то есть эпизодический и поэтому действительно знаешь я когда вот сел такой надо написать редактор снова там у нас там обновить тайпскрипт уже все дела И когда я сел это делать я такой Ну как же вот вот все про говорят как энд вот вот это вот это оказалось что Да они очень крутые в маркетинге это правда но вот с точки зрения того куда они идут это очень узкая ниша Да согласен Ну вот как бы нашем коммьюнити нужно стать себя я много об этом говорю но это ничего не меняется поэтому типа будем ждать чуда либо да либо что начнёт себя само осознавать и как-то более осознанно подходить к выбору инструментов к Ну типа к тому чтобы у нас было нормальное распределение 820 а не 991 пока ты здесь Я тебя поймал прямо последний вопрос который я тебе задам но просто я знаю что ты активно этим занимаешься это очень важно расскажи пожалуйста про движение связанные с уменьшением размера баннов Да дада да есть соответственно Ну как бы в чём проблема что в жава скрипте есть библиотеки Это не проблема Проблема в том что никто никогда не думал об их размере и они разрастаясь разрастанию другие зависимости То есть ты очень часто ставишь одну маленькую зависимость а ставится 20 зависимостей и ладно они иногда попадают в jasp bandle а иногда это просто твой No Модус увеличивается и соответственно во-первых началось движение чтобы сам размер JavaScript бала был меньше типа вот как бы один из таких важных шагов был на ID библиотека которая генерирует уникальный ID типа это супер простая штука но У меня получилось его уменьшить до 200 байт и это был знаешь ти фишка была не в 200 байтах а в вот политическом движени что мы устали от огромны библиотек Дайте нам минималистичные подходы это запустило и сейчас есть очень крутой проект который называется е18 В общем это набор ребят которые идут попко системе и выпиливают кучу

зависимо для делают Чтобы ещё НОД Мос уменьшить но они например в стори Буке они очень большую работу сделали они по-моему там чуть ли не до 2/3 уменьшили размер то есть это на самом деле очень неско вещающий фрукты очень легко сократить количество зависимостей потому что у нас просто типа очень неправильно коммьюнити было как мы всё это неправильно делали и вот сейчас вот эти ребята создают аналоги зависимости приходят в большие проекты заменяют огромные аналоги на маленькие форсят рассказывают супер коммьюнити Подписывайтесь они есть там в бска в моста Доне в общем крутые Ребята в Твиттере крутые ребята очень интересно коммьюнити Я просто ещё раз сформулирую для себя Ну те то же самое могу сказать Ну и что это происходит Да мы здесь говорим именно о том что в дсе всё-таки есть Огромно какой-то вот перебор что ли с этим Да overuse когда очень даже мелкий или ты имеешь то что в браузере как бы отдаётся слишком много джеса там где можно уме на самом деле фундаментально Проблема была везде просто в крипте это запустили сильнее и мы раньше об этом увидели когда вот был и так далее То есть у нас в два скрипте изначально был очень маленькая и поэтому был в библиотеках и поэтому была куча зависимостей и когда они появились эти библиотеке народ пошёл по пути когда Давайте вместо одной зависимости которая всё делает мы сделаем кучу маленьких и поэтому у нас получалось огромное дерево но в чём проблема сейчас чем больше зависимости тем больше риск того что одна из зависимой будет взломана чем больше зависимо тем медле у тебя работает потому что тебя очень долгое время установки тик зависимостей и уменьшение зависимости сейчас важно в любом проекте и на самом деле мне кажется что эндос языки они в своём высокомерии насмешками над жава скриптами очень пропустили момент того что там были здравые идеи И на самом деле это это же движение нужно запускать и в Руби и в других проектах потому что скажем честно Руби сейчас чаще взламывают чем JS было гораздо больше взломов в зависимости через в ru проектах взломы да да последнее время было много громких дел а при этом кстати про скорость Ты знаешь вот опять же я недавно разговаривал с одним из разработчиков пайтона и мы знаешь какую штуку обсуждали современный пакетный менеджер если ты слышал нет короче глобально знаешь какой тренд тоже есть переписывание всего этого добра на раст и он просто рассказывал как пример какая там Скорость вообще работы это коне чудеса в пне сеть А если у нас кэш то вот это ВС зависимости нужно Ну типа заархивировать чтобы положить в кэш один файл и у нас будет типа у меня сейчас на сие большая часть времени это разархивация кэша то есть мы всё равно убираем типа скорость установки даже в ме она очень быстрая всё упирается в то что у нас огромная тоже верно огромная папка зависимо стати нельзя ли сказать что это камень не то чтобы в огород А вот э вот история когда микросервис всё меньше меньше всё больше распределяем это не того же уровня проблема того же уровня нам нужно поддерживать определённый баланс типа Размер должен быть соответствовать задачи и вот тогда всё будет хорошо это отдельная большая тема на которую я с кем-нибудь в будущем скоро поговорю Андрюх большое спасибо что ты пришёл вот ой очень хорошо записались Мне кажется типа очень много хороших тем подняли Спасибо посмотрим что скажут ребята Обязательно оставляйте свои комментарии Потому что Андрей мне кажется порвал пуканы И мне очень хочется почитать и посмотреть что вы на эту тему думаете Да не забудьте подписаться на подкаст в юбе и ВК а также на мой канал организованное программирование в телеграме где я регулярно рассказываю про эффективную разработку

[музыка]