Вы достаточно подробно описали каждый шаг, но в момент добавления LegacyRef<>, про него умолчали, почему нельзя было указать ref без преобразования в LegacyRef
Вопросов на самом деле много, часть из них перечислю:
— как вы определяете с технической стороны корректный видеозвонок?
— собираете ли вы статистику по звонкам, корректный поток у пользователя и у репетитора?
— допустим у пользователя заблокирована камера, возникают ли проблемы при соединению?
— вы как нибудь технически определяете успешность звонка или полагаетесь на отклик пользователя/репетитора? я как помню мне сразу предлагали в skype)) в обход вашего решения
— вы думали в сторону jitsi?
— как поступаете если ошибки на стороне медиасервера? есть какие-нибудь технические примеры, например реконнекта?
— собираете статистику WebRTC? rtt, jitter и другие метрики для определения состояния соединения?
Интересен был ваш опыт работы с WebRTC, а на деле просто рассказали про возникшие проблемы без технических деталей(
Планируете подробнее раскрыть тему?
Вчера проходил собеседование, типичная ситуация, проект полу дохлый:
1. Плохая структура проекта, все сложено в папку components, нет разделение на компоненты и контейнеры, тяжело разобраться, какая страница отображает какие компоненты, полный хаос
2. Вся логика в роутере, он же и есть данные + бизнес логика приложения, как это поддерживать?
3. Полная загрузка страницы занимает около 40 секунд, при этом ресурсов загружается на 20мб, это очень много
Можно продолжать сколько угодно, больше всего удивляет, что при найме на работу вопросы и тестовые задачи не соответствуют тому, над чем придется работать.
Тогда давай отказываться и от типизации, стандартов, соглашений и многого другого, что занимает время.
Когда попадаются проекты, на том же реакте, где был сделан упор на скорость, где не используется redux и другие библиотеки получается что то вот такое: github.com/magickasoft/wacdaq/blob/master/src/components/pagesRouter/pagesRouter.jsx
поэтому иногда эта «шаблонность» и «стандарты» принятые обществом лучше придерживать, так легче вникнуть в проект и дальше развивать проект.
Согласен, много шаблонного кода, но если использовать redux-act все становится немного удобнее и к тому же, где находится логика приложения? Вместе с данными? Мне больше нравится использовать Redux-Saga, данные отдельно, логика отдельно.
Мне больше интересно, как организовать систему доставки контента, например в данном случае 1 сервер для стрима, что делать, если пользователей несколько тысяч?
Если вы знаете ответ, пожалуйста ответьте на этот вопрос toster.ru/q/640003?e=7736213#clarification_714557
не совсем понимаю, как собираетесь передавать данные между клиентами, если это hls поток, где каждый чанк весит примерно 2-3мб, смотрят стрим примерно 30k пользователей…
У меня вопрос, получается 1 сервер это примерно 50 клиентов? Как вы решаете проблему большого потока пользователей, когда к стриму подключилось сразу 30 тыс. человек? используете cdn (как и какой? кешируете чанки .ts?)? или свое решение?
Как объект с данными находящимся в определенном месте может создать бардак? Экшены отдельно, редьюсеры отдельно, саги отдельно. Если ты меняешь экшен то везде поменяется, я предоставить не могу с редаксом то что ты описал…
Так проблема в подходе или в людях? Я вот начал практиковать flutter, и могу сказать что redux я там с большой радостью использую, не представляю другой подход к разработке
идея понравилась, скачал попытался поискать что-нибудь, бесконечная загрузка + постоянно требует капчу подтвердить. удалил
Вы достаточно подробно описали каждый шаг, но в момент добавления LegacyRef<>, про него умолчали, почему нельзя было указать ref без преобразования в LegacyRef
— как вы определяете с технической стороны корректный видеозвонок?
— собираете ли вы статистику по звонкам, корректный поток у пользователя и у репетитора?
— допустим у пользователя заблокирована камера, возникают ли проблемы при соединению?
— вы как нибудь технически определяете успешность звонка или полагаетесь на отклик пользователя/репетитора? я как помню мне сразу предлагали в skype)) в обход вашего решения
— вы думали в сторону jitsi?
— как поступаете если ошибки на стороне медиасервера? есть какие-нибудь технические примеры, например реконнекта?
— собираете статистику WebRTC? rtt, jitter и другие метрики для определения состояния соединения?
Планируете подробнее раскрыть тему?
1. Плохая структура проекта, все сложено в папку components, нет разделение на компоненты и контейнеры, тяжело разобраться, какая страница отображает какие компоненты, полный хаос
2. Вся логика в роутере, он же и есть данные + бизнес логика приложения, как это поддерживать?
3. Полная загрузка страницы занимает около 40 секунд, при этом ресурсов загружается на 20мб, это очень много
Можно продолжать сколько угодно, больше всего удивляет, что при найме на работу вопросы и тестовые задачи не соответствуют тому, над чем придется работать.
Когда попадаются проекты, на том же реакте, где был сделан упор на скорость, где не используется redux и другие библиотеки получается что то вот такое: github.com/magickasoft/wacdaq/blob/master/src/components/pagesRouter/pagesRouter.jsx
поэтому иногда эта «шаблонность» и «стандарты» принятые обществом лучше придерживать, так легче вникнуть в проект и дальше развивать проект.
Мне больше интересно, как организовать систему доставки контента, например в данном случае 1 сервер для стрима, что делать, если пользователей несколько тысяч?
Если вы знаете ответ, пожалуйста ответьте на этот вопрос toster.ru/q/640003?e=7736213#clarification_714557
Так проблема в подходе или в людях? Я вот начал практиковать flutter, и могу сказать что redux я там с большой радостью использую, не представляю другой подход к разработке