--------------------------------
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
❤33👍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❤🔥5🔥3👌1
Нью лого, кстати скоро выйдет пост о том как я переписал все запросы в chat-service и message-service с Postgresql на ScyllaDb, почему я это сделал, что это даёт и так далее. Инфа о том какие методы в chat-service я добавил, и какие собираюсь в message-service. А так-же новости о новых фичах приложениях ;)
Оставайтесь на связи😐 😜 🚀
Оставайтесь на связи
Please open Telegram to view this post
VIEW IN TELEGRAM
❤19❤🔥5🔥2💔1