Привет всем, хотел бы порекламировать свою новую библиотеку на Rust для Frontend разработки на Tauri, она называется ReaXive и вдохновлена моей любимой библиотекой MobX 😐
Это полная копия мобикса, реализованы все нужные методы для профессиональной разработки больших проектов. Даю вам слово, лучше этой библиотеки для стейт менеджмента в Tauri просто нет ;)
Выполнена на классах и имеет очччень, ну очень удобные инструменты для реактивной разработки
😊 😘
Библиотека
Репо библиотеки
Репо примера использования
Это полная копия мобикса, реализованы все нужные методы для профессиональной разработки больших проектов. Даю вам слово, лучше этой библиотеки для стейт менеджмента в Tauri просто нет ;)
Выполнена на классах и имеет очччень, ну очень удобные инструменты для реактивной разработки
Библиотека
Репо библиотеки
Репо примера использования
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
17🔥10
День 443| Разработка социальной сети
Хай гайс, сорян что не выпускал посты насссттоооольько долго. а именно 73 дня, извиняюсь за отстуствие но это время я зря не провел.
Главная новость и главная причина моей неактивности: Я нашел работу в западной компании, и сейчас работаю там Rust Backend разработчиком. Работаю удаленно фуллтайм по 8 часов в день, собственно из-за этого в основном и не оставалось сил писать что-то дальше.. И процесс разработки был ооччень медленным, да и голова в целом забита была только работой. Время от времени что-то да делал. Ладно не будем грустить давайте по новостям о соц сети;
--------------------------------
1. Добавил новые странице в настройках, страница: "Данные и память":
Теперь можно управлять абсолютно всеми кэшированными данными приложения прямо в настройках прямо как в телеграме, выполненно качественно да и с прикольной анимацией. Эта хрень еще и экономит ресурсы сервера очень сильно. А благодаря тому что я использовал везде один компонент для отображения Image и других данных, я добавил туда логику, если есть в кэше то используй кэш.
--------------------------------
2. Реализовал новый вебсокет в микросервисе файлов "file-service" а так-же загрузку видео в постах или где либо еще:
Этот вебсокет нужен чтобы получать в реал тайме статус загрузки видео. Как происходит загрузка видео?
1. Мы отправляем файл по вебсокету создав на фронтенде уникальный uploadId (мы его еще поиспользуем) наш запрос принимается бэкендом и начинается обработка видео.
2. Сначала видос на бэке сжимается до 1080x60 фпс с пониженным битрейтом, дабы снизить его размер. Это нужно для того чтобы держать как можно меньше памяти в Hetzner S3 сторейже.
3. Затем это отправляется в Kafka, чтобы гарантировать что видос загрузится 100% даже если отключатся сервера, при их включении снова всё будет работать. Это позволяет нам загружать ролики даже длинною в час (но я поставил намеренный лимит в 5 минут, да-да у нас будет что то на подобии инстаграм Reels)
4. На фронтенде подключаемся к вебсокету и слушаем канал по нашему сгенерированному из первого пункта uploadId, теперь мы слушаем прогресс загрузки видео или изображения.
5. Данные о загрузке видео приходят нам из кафки, парсятся и используются для того чтобы отправлять вебсокет сигналы о процентах загрузки с некоторой переодичностью например каждые 10 секунд если это видео, либо каждые 3 секунды если это изображение (при достижении 100% мы сразу отправляем в вебсокет прогресс 100 независимо от переодичности)
6. На фронтенде реализовал очень крутой компонент с анимацией как в телеграме который принимает резкие прогрессы и делает плавное перемещение к нему c анимацией змейки. Чем больше разница между старым прогрессом и новым прогрессом, тем быстрее анимация перехода из одного прогресса в другой. и чем меньше разница между старым прогрессом и новым, тем быстрее анимация перехода (и конечно же у них есть лимиты по скорости) Гениально и просто
--------------------------------
3. Собрал команду из мобильных разработчиков
Заранее хочу их поблагодарить за их помощь, любая помощь сейчас мне будет облегчать страдания 😂 Так как времени на разработку совсем нету и любой закрытый таск = уже счастье.
В свою очередь я даю совершенно другой опыт в разработке React приложений, моя архитектура и моя библиотека очень понравилась новым разработчикам, и они никогда не видели настолько чистой архитектуры и настолько приятных инструментов для разработки
Если вы тоже хотите вступить в команду мобильных разработчиков прошу написать мне в лс - @nics51
Хай гайс, сорян что не выпускал посты насссттоооольько долго. а именно 73 дня, извиняюсь за отстуствие но это время я зря не провел.
Главная новость и главная причина моей неактивности: Я нашел работу в западной компании, и сейчас работаю там Rust Backend разработчиком. Работаю удаленно фуллтайм по 8 часов в день, собственно из-за этого в основном и не оставалось сил писать что-то дальше.. И процесс разработки был ооччень медленным, да и голова в целом забита была только работой. Время от времени что-то да делал. Ладно не будем грустить давайте по новостям о соц сети;
--------------------------------
1. Добавил новые странице в настройках, страница: "Данные и память":
Теперь можно управлять абсолютно всеми кэшированными данными приложения прямо в настройках прямо как в телеграме, выполненно качественно да и с прикольной анимацией. Эта хрень еще и экономит ресурсы сервера очень сильно. А благодаря тому что я использовал везде один компонент для отображения Image и других данных, я добавил туда логику, если есть в кэше то используй кэш.
--------------------------------
2. Реализовал новый вебсокет в микросервисе файлов "file-service" а так-же загрузку видео в постах или где либо еще:
Этот вебсокет нужен чтобы получать в реал тайме статус загрузки видео. Как происходит загрузка видео?
1. Мы отправляем файл по вебсокету создав на фронтенде уникальный uploadId (мы его еще поиспользуем) наш запрос принимается бэкендом и начинается обработка видео.
2. Сначала видос на бэке сжимается до 1080x60 фпс с пониженным битрейтом, дабы снизить его размер. Это нужно для того чтобы держать как можно меньше памяти в Hetzner S3 сторейже.
3. Затем это отправляется в Kafka, чтобы гарантировать что видос загрузится 100% даже если отключатся сервера, при их включении снова всё будет работать. Это позволяет нам загружать ролики даже длинною в час (но я поставил намеренный лимит в 5 минут, да-да у нас будет что то на подобии инстаграм Reels)
4. На фронтенде подключаемся к вебсокету и слушаем канал по нашему сгенерированному из первого пункта uploadId, теперь мы слушаем прогресс загрузки видео или изображения.
5. Данные о загрузке видео приходят нам из кафки, парсятся и используются для того чтобы отправлять вебсокет сигналы о процентах загрузки с некоторой переодичностью например каждые 10 секунд если это видео, либо каждые 3 секунды если это изображение (при достижении 100% мы сразу отправляем в вебсокет прогресс 100 независимо от переодичности)
6. На фронтенде реализовал очень крутой компонент с анимацией как в телеграме который принимает резкие прогрессы и делает плавное перемещение к нему c анимацией змейки. Чем больше разница между старым прогрессом и новым прогрессом, тем быстрее анимация перехода из одного прогресса в другой. и чем меньше разница между старым прогрессом и новым, тем быстрее анимация перехода (и конечно же у них есть лимиты по скорости) Гениально и просто
--------------------------------
3. Собрал команду из мобильных разработчиков
Заранее хочу их поблагодарить за их помощь, любая помощь сейчас мне будет облегчать страдания 😂 Так как времени на разработку совсем нету и любой закрытый таск = уже счастье.
В свою очередь я даю совершенно другой опыт в разработке React приложений, моя архитектура и моя библиотека очень понравилась новым разработчикам, и они никогда не видели настолько чистой архитектуры и настолько приятных инструментов для разработки
Если вы тоже хотите вступить в команду мобильных разработчиков прошу написать мне в лс - @nics51
--------------------------------
4. Самая главная новость... Я начал рефакторить все свои микросервисы на Websocket + gRpc
Сейчас у нас только chat-service, message-service и file-service используют вебсокеты. Остальные микросервисы используют HTTP + gRpc. Один лишь ml-service использует онли gRpc.
Собственно я решил перейти на Вебокеты и gRpc во всех микросервисах, потому что я вдохновился телеграмом. Я и раньше примерно понимал как создан телеграм, но думал что это слишком тяжело и я не потяну. Но за все время пока я писал бэкенд приложения на расте и работал растером я получил много опыта (особенно в своей социальной сети) И как то раз сидя и смотря Network в телеграм я смотрел на эти зашифрованные Binary data и вебсокет коннекшены и я подумал, а почему я не могу сделать так-же?
В голове сразу пошли куча идей и реализаций.
В итоге создал две библиотеки, успешно перенес api-gateway микросервис на Вебсокеты и уже перенес auth-service и session-service микросервисы на gRpc. Это очень легко делается кстати.
Я еще понял что моя имплементация chat-service и message-service была в корне неверной. Сейчас я делаю точно такую же архитектура как в Telegram и это действительно захватывает. Данная архитектура мало того что жрет меньше ресурсов при правильных реконнектах, так еще и безопаснее так-как происходит обмен ключей и все данные от всех микросервисов шифруются как в телеграме. Как в целом работает Websocket + gRpc бэкенд без HTTP?
1. api-gateway микросервис - это единая точка входа вебсокет соединений которая и принимает обмен ключами. Она просто связывает все ваши микросервисы и передает запросы туда куда надо. Я сделал так чтобы можно было отключить проверку обмена ключами на время до Production, чтобы разрабатывать в dev режиме. Вы делите запрос на несколько основных частей отправляя в body: type, service и method. Где type - это тип вебсокет запроса, service - это микросервис куда вы обращаетесь, и method - это просто название метода который вы дергаете например "get_profile", "get_user" хз.
2. Запрос перенаправляется в gRpc сервис который называется как например "AuthGatewayService", запрос прилетает в нужный микросервис и обрабатывается отдавая вам ответ который вы затем используете чтобы сделать обратный ответ по подключенному вебсокету
3. Если это например chat-service где нужно отдавать данные обратно вашему api-gateway но в силу gRpc вы этого не можете сделать (можете только если это стрим но это хуйня) то здесь вы используете уже Nats Pub/Sub который помогает вам соединить ответы между gRpc chat-service и вебсокетным api-gateway микросервисом
--------------------------------
5. Создал локальную библиотеку regen - "Rust Endpoint Generation" на Rust для своего бэкенд приложения
Эта библиотека которая генерирует протобафы .proto и модели, структуры данных .rs, Response Request с валидацией и трейтами используя файлы .yaml из папки docs. Вы сами назначаете dir и конечный outdir.
В ней так-же есть команда reverse которая позволяет делать обратную техник... кхм, обратную генерацию из generated/ .proto и .rs в docs/ папку. Она генерирует их таким образом, например вы расписываете в docs/auth-service/models.yaml и grpc.yaml и получаете generated/auth-service/models.rs и grpc.proto.
Эта библиотека просто "удобная"
--------------------------------
6. Локальная библиотека rwsend - "Rust WebSocket Endpointds"
Ой, крч хочу быть кратким, эта библиотека просто помогает за считанные минуты переписать свой http бэкенд на вебсокеты используя силу метапрограммирования (трейты, макросы). Минус перфа - нет.
Всё.
--------------------------------
4. Самая главная новость... Я начал рефакторить все свои микросервисы на Websocket + gRpc
Сейчас у нас только chat-service, message-service и file-service используют вебсокеты. Остальные микросервисы используют HTTP + gRpc. Один лишь ml-service использует онли gRpc.
Собственно я решил перейти на Вебокеты и gRpc во всех микросервисах, потому что я вдохновился телеграмом. Я и раньше примерно понимал как создан телеграм, но думал что это слишком тяжело и я не потяну. Но за все время пока я писал бэкенд приложения на расте и работал растером я получил много опыта (особенно в своей социальной сети) И как то раз сидя и смотря Network в телеграм я смотрел на эти зашифрованные Binary data и вебсокет коннекшены и я подумал, а почему я не могу сделать так-же?
В голове сразу пошли куча идей и реализаций.
В итоге создал две библиотеки, успешно перенес api-gateway микросервис на Вебсокеты и уже перенес auth-service и session-service микросервисы на gRpc. Это очень легко делается кстати.
Я еще понял что моя имплементация chat-service и message-service была в корне неверной. Сейчас я делаю точно такую же архитектура как в Telegram и это действительно захватывает. Данная архитектура мало того что жрет меньше ресурсов при правильных реконнектах, так еще и безопаснее так-как происходит обмен ключей и все данные от всех микросервисов шифруются как в телеграме. Как в целом работает Websocket + gRpc бэкенд без HTTP?
1. api-gateway микросервис - это единая точка входа вебсокет соединений которая и принимает обмен ключами. Она просто связывает все ваши микросервисы и передает запросы туда куда надо. Я сделал так чтобы можно было отключить проверку обмена ключами на время до Production, чтобы разрабатывать в dev режиме. Вы делите запрос на несколько основных частей отправляя в body: type, service и method. Где type - это тип вебсокет запроса, service - это микросервис куда вы обращаетесь, и method - это просто название метода который вы дергаете например "get_profile", "get_user" хз.
2. Запрос перенаправляется в gRpc сервис который называется как например "AuthGatewayService", запрос прилетает в нужный микросервис и обрабатывается отдавая вам ответ который вы затем используете чтобы сделать обратный ответ по подключенному вебсокету
3. Если это например chat-service где нужно отдавать данные обратно вашему api-gateway но в силу gRpc вы этого не можете сделать (можете только если это стрим но это хуйня) то здесь вы используете уже Nats Pub/Sub который помогает вам соединить ответы между gRpc chat-service и вебсокетным api-gateway микросервисом
--------------------------------
5. Создал локальную библиотеку regen - "Rust Endpoint Generation" на Rust для своего бэкенд приложения
Эта библиотека которая генерирует протобафы .proto и модели, структуры данных .rs, Response Request с валидацией и трейтами используя файлы .yaml из папки docs. Вы сами назначаете dir и конечный outdir.
В ней так-же есть команда reverse которая позволяет делать обратную техник... кхм, обратную генерацию из generated/ .proto и .rs в docs/ папку. Она генерирует их таким образом, например вы расписываете в docs/auth-service/models.yaml и grpc.yaml и получаете generated/auth-service/models.rs и grpc.proto.
Эта библиотека просто "удобная"
--------------------------------
6. Локальная библиотека rwsend - "Rust WebSocket Endpointds"
Ой, крч хочу быть кратким, эта библиотека просто помогает за считанные минуты переписать свой http бэкенд на вебсокеты используя силу метапрограммирования (трейты, макросы). Минус перфа - нет.
Всё.
--------------------------------
❤1
Ну и новости не по разработке:
1. Купил новый мак, "Macbook pro 14 m4 24gb ram 1024gb sdd | Space Black" и даже заснял это от первого лица (Сверху фрагмент видоса), мб скоро выпущу ролик если не лень будет. С этим маком разработка стала в разы легче, я пересобрал все 15 микросервисов, собирая 4 докер образа одновременно. Пересобирать бэк пришлось из за AWS Issue, долго обьяснять...
2. Купил всяких товаров с Temu, подставка для микрофона "О да наконецто он не будет у меня на столе занимать 25/30см радиуса", новый коврик и по херне крч, обновив рабочее место (На фотках сверху). Честно по началу не верил в Temu но теперь как разработчик уважаю разработчика Temu, очень качественное мировое приложение... За 2 года достичь оборотов Aws это мощно... (бля я неожидал что она настолько ах*енная и дешевая, большая поссылка пришла за 1.5 недели)
На этом пожалуй всё, большой пост получился)))) постараюсь чаще вас уведомлять о новостях. Удачи всем, ожидаем и не скучаем в общем😐 😜
P.S: Прошу писать комментарии и ставить реакции именно под этим постом, ну или под первым сверху хЗ
1. Купил новый мак, "Macbook pro 14 m4 24gb ram 1024gb sdd | Space Black" и даже заснял это от первого лица (Сверху фрагмент видоса), мб скоро выпущу ролик если не лень будет. С этим маком разработка стала в разы легче, я пересобрал все 15 микросервисов, собирая 4 докер образа одновременно. Пересобирать бэк пришлось из за AWS Issue, долго обьяснять...
2. Купил всяких товаров с Temu, подставка для микрофона "О да наконецто он не будет у меня на столе занимать 25/30см радиуса", новый коврик и по херне крч, обновив рабочее место (На фотках сверху). Честно по началу не верил в Temu но теперь как разработчик уважаю разработчика Temu, очень качественное мировое приложение... За 2 года достичь оборотов Aws это мощно... (бля я неожидал что она настолько ах*енная и дешевая, большая поссылка пришла за 1.5 недели)
На этом пожалуй всё, большой пост получился)))) постараюсь чаще вас уведомлять о новостях. Удачи всем, ожидаем и не скучаем в общем
P.S: Прошу писать комментарии и ставить реакции именно под этим постом, ну или под первым сверху хЗ
Please open Telegram to view this post
VIEW IN TELEGRAM
❤32👍5👏2👌1
День 443 | Разработка социальной сети
Хочу сказать, что я успешно перенес все 13 микросервисов не считая Ml-service и Api-gateway на gRpc. Оч долго собирал это всё в докер образцы, аж по 8 собрал в первый раз во всех 8-и терминалах, своим скриптом который автоматически собирает, отправляет в Registry и сам обновляет под в кубере на сервере
Теперь наша архитектура такова:
api-gateway микросервис это единая точка всех Websocket соединений которое делает обращение к другим gRpc микросервисам
Микросервисы по типу chat-service или message-service, для отправки сообщений всем в чате или в целом кому либо в ответ, используется Nats Pub/Sub.
Сейчас я занимаюсь рефакторингом всех actions сторов на клиентской части, я должен заменить все HTTP функции mobxSaiFetch из моей библиотеки mobx-toolbox, на mobxSaiWs и далеко не только это
Я сделал очень крутую архитектуру на мобилке:
1. Я создал WebsocketRoutesStore мобикс стор, в котором хранится массив с типами ответов от вебсокета, например мы используем функцию registerRoute отдавая туда какой нибудь { type: "auth-login", success: ..., error: ... } так-же можно и массивом, в success мы прокидываем функцию при успешном получении данных, а в error получаем саму ошибку в случае неуспешного запроса
2. Создал WebsocketApiStore в котором инициализировал сам основной вебсокет при помощи другого очень большого класса WebsocketStore который создает нужные функции, методы и состояния для удобного использования любого вебсокета, там реализованы системы автоматического heartBeat, Reconnection, обмена ключами и куча других опций которые можно еще и включать или выключать благодаря настройкам при инициализации класса
Так-же, на бэкенде я хочу перейти на ScyllaDb в chat-service и message-service. Так как это лучший вариант для таких больших и быстрых данных. Сообщений много, а postgres слишком большеват для этого применения.
Всем удачи и спокойной ночи😐 😜
Хочу сказать, что я успешно перенес все 13 микросервисов не считая Ml-service и Api-gateway на gRpc. Оч долго собирал это всё в докер образцы, аж по 8 собрал в первый раз во всех 8-и терминалах, своим скриптом который автоматически собирает, отправляет в Registry и сам обновляет под в кубере на сервере
Теперь наша архитектура такова:
api-gateway микросервис это единая точка всех Websocket соединений которое делает обращение к другим gRpc микросервисам
Микросервисы по типу chat-service или message-service, для отправки сообщений всем в чате или в целом кому либо в ответ, используется Nats Pub/Sub.
Сейчас я занимаюсь рефакторингом всех actions сторов на клиентской части, я должен заменить все HTTP функции mobxSaiFetch из моей библиотеки mobx-toolbox, на mobxSaiWs и далеко не только это
Я сделал очень крутую архитектуру на мобилке:
1. Я создал WebsocketRoutesStore мобикс стор, в котором хранится массив с типами ответов от вебсокета, например мы используем функцию registerRoute отдавая туда какой нибудь { type: "auth-login", success: ..., error: ... } так-же можно и массивом, в success мы прокидываем функцию при успешном получении данных, а в error получаем саму ошибку в случае неуспешного запроса
2. Создал WebsocketApiStore в котором инициализировал сам основной вебсокет при помощи другого очень большого класса WebsocketStore который создает нужные функции, методы и состояния для удобного использования любого вебсокета, там реализованы системы автоматического heartBeat, Reconnection, обмена ключами и куча других опций которые можно еще и включать или выключать благодаря настройкам при инициализации класса
Так-же, на бэкенде я хочу перейти на ScyllaDb в chat-service и message-service. Так как это лучший вариант для таких больших и быстрых данных. Сообщений много, а postgres слишком большеват для этого применения.
Всем удачи и спокойной ночи
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14❤🔥4🔥1👌1