помимо веб сервера (или любого другого ингресса типа прокси), сам бэк может так же блокировать запросы с большими файлами. например php отбросит запросы с 413 кодом, если запрос превышает ini параметры post_max_size и/или upload_max_filesize.
и если речь про микросервисную архитектуру, то скорее всего проект юзает куб для оркестрации контейнеров, а значит надо проверить настройки ingress и настройки пода/деплоймента, где крутится контейнер с этим микросервисом
странные показатели, на живом проекте fpm давал на однотипные запросы (мускуль, редис, ничего сложного) порядка 200мс на запрос, тогда как rr/franken те же запросы выполняли за 50мс
Уже год использую RR. Встал вопрос о переходе с FPM, и сначала я выбрал FrankenPHP. Октан выполняет большую часть работы по адаптации PHP-сервера к приложению, но не обошлось без проблем. Все основные проблемы возникали с статичными классами, значения которых передавались от сессии к сессии. Например, таймзона клиента хранилась в статичных свойствах, и если один клиент менял таймзону в рамках одного воркера, она изменялась и для другого клиента. Я откатил обратно на FPM и начал более подробно изучать тему.
После детального изучения, что именно нужно доработать, я решил остановиться на RR. Основные причины:
Он всё ещё невероятно быстрый по сравнению с FPM.
RR — это не только PHP-сервер, но и, например, сервер очередей, кешей и других полезных вещей.
Интеграция с Temporal можно отнести ко второму пункту, но я бы выделил её отдельно. Для тех, кто работает с глобальными workflow или с Temporal в частности, RR из коробки поддерживает поднятие Temporal-сервера на PHP.
Ну и не стоит забывать, что RR делают те же ребята, которые разрабатывают Spiral и другие проекты. Активно поддерживающие PHP-сообщество ну и говорят по-русски. Это даёт им несколько дополнительных очков форы )
Мда. ИТ-Сисуритлу, который мы заслужили в 24 году. "Если забыть про access-control, то любой сможет получить доступ ко всем данным". И что дальше? "Не забывайте закрыть автомобиль, а то любой сможет в него сесть"?
@butschster мужик! фарт-тайм -- мужики. rr -- мужики! темпурал вообще топ. с огромным удовольствием читаю ваши подборки php новостей в вашем чате и на телеграфе, увы, пхпшторм дневник ушёл куда-то в другую сторону
много лет пишу кроссплатформу. начинал с натива, потом был phonegap/cordova (pwa), потом перелез на react native. не для наброса на вентилятор, но справедливости для пробегусь по минусам RN:
Хоть JSX и использует JavaScript, что делает его намного понятнее, нельзя не отметить довольно сложный и запутанный синтаксис этого языка.
сложность и запутанность javascript? это по сравнению с явой то?
React Native не предоставляет полный доступ к нативным функциям устройства, что может затруднять разработку.
интересно, каким образом RN ограничивает доступ к функциям устройства? ну т.е. этот пункт надо вычеркнуть и забыть, что он вообще был, это просто глупость.
Нестабильная работа на разных устройствах и платформах, помимо этого из-за постоянных обновлений множество функций может быть удаленно или изменено.
это дань кроссплатформе. любое приложение, адаптированное под все возможные платформы так или иначе будет отваливаться то там то тут. увы, андроид в целом нестабильная штука. сейчас такого я не встречал, но раньше, например, было нормально, что у определённых устройств мог отваливаться wifi модуль или gps. просто без причин. и ты, как разработчик, сначала код дебажишь свой, а потом едешь и покупаешь устройство, чтобы отловить этот баг. а когда понимаешь, что дело не в твоём приложении, а в конкретном устройстве -- начинаешь думать, как бы это донести до клиента.
Приложения, созданные с использованием React Native, менее производительными по сравнению с нативными приложениями из-за моста JavaScript и самой концепции кросс-платформенного кода. Это может быть особенно заметно при работе с большим объемом данных или сложными анимациями.
это очевидно, т.к. действительно кроссплатформа даёт прилично оверхеда. на самом деле современный RN стал быстрым, современные андройды стали быстрыми, разницы конечный клиент по сути и не заметит, но да действительно, если считать миллисекунды на бутстрапе -- натив победит. про большой объём данных -- допустим, что автор просто опечатался, т.к. нет никакой разницы из натива ты работаешь с большими данными или из rn. про сложные анимации вообще смешно, reanimated настолько подняли планку, что не каждый нативщик сможет так же просто и быстро делать 60fps анимацию.
Создание сложных пользовательских интерфейсов может быть более сложным с использованием React Native по сравнению с нативными разработками из-за ограниченности фреймворка.
а в чём ограниченность фреймворка? тут автор прав при одном условии -- если rn пишут новички, то действительно приложение будет запутанным и сложным для понимания. свобода, которую даёт jsx+javascript играет в обратную сторону, если проект делает не опытная команда. в этом плане android studio, конечно, всё же обязаывает разработчика писать "правильно" и не придумывать велосипед. но опять же, всё зависит от команды.
В отличие от нативной разработки, React Native может ограничить доступ к некоторым функциям и возможностям, доступным только на конкретной платформе. То есть то что работает на iOS в лучшем случае будет выдавать ошибку на Android.
опять же, к некоторым, это например к каким? и что, например, будет работать на иос и будет выдавать ошибку в андройде?
Использование сторонних библиотек и плагинов может привести к проблемам совместимости или возникновению ошибок в процессе разработки. При этом зачастую их использование необходимо для реализации определённого функционала.
и ничего не мешает разработчику исправить код этих "плагинов"... ровно так же, как и в нативе.
laravel-websockets 3 недели как archived... последний релиз в августе 2023, с тех пор куча ошибок, связанных с неверными версиями зависимостей. тут либо ждать https://reverb.laravel.com/, либо юзать что-то вроде https://mercure.rocks/
Приветствую, werf прекрасна, спасибо за вашу работу. Подскажите по поводу "Запуск миграций до релиза". Есть кластер, есть отдельно база. Вариант с обновлением кода, потом миграцией, потом траффиком -- подходит, но смущает, что пауза между миграцией и переброской траффика -- существенная, несколько секунд. Тогда как миграция может похерить часть кода в определённых кейсах (например, переименование таблиц итп). Есть какие-то механизмы и обновления кодовой базы и сразу создания нужных подов/ингресов, чтобы после миграции моментально переключить траффик? Или общий совет, подобные кейсы решать в 2 шага (код, понимающий и старые названия таблиц и новые, потом миграция + новый код с новыми таблицами)?
этой «проблеме» миллион лет, тот же nginx по дефолту не принимает файлы больше 1мб
https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
помимо веб сервера (или любого другого ингресса типа прокси), сам бэк может так же блокировать запросы с большими файлами. например php отбросит запросы с 413 кодом, если запрос превышает ini параметры post_max_size и/или upload_max_filesize.
и если речь про микросервисную архитектуру, то скорее всего проект юзает куб для оркестрации контейнеров, а значит надо проверить настройки ingress и настройки пода/деплоймента, где крутится контейнер с этим микросервисом
с пушами пробела, с faceid проблема, ну и в любом случае это отдельная разработка со своими ньюансами.
странные показатели, на живом проекте fpm давал на однотипные запросы (мускуль, редис, ничего сложного) порядка 200мс на запрос, тогда как rr/franken те же запросы выполняли за 50мс
Уже год использую RR. Встал вопрос о переходе с FPM, и сначала я выбрал FrankenPHP. Октан выполняет большую часть работы по адаптации PHP-сервера к приложению, но не обошлось без проблем. Все основные проблемы возникали с статичными классами, значения которых передавались от сессии к сессии. Например, таймзона клиента хранилась в статичных свойствах, и если один клиент менял таймзону в рамках одного воркера, она изменялась и для другого клиента. Я откатил обратно на FPM и начал более подробно изучать тему.
После детального изучения, что именно нужно доработать, я решил остановиться на RR. Основные причины:
Он всё ещё невероятно быстрый по сравнению с FPM.
RR — это не только PHP-сервер, но и, например, сервер очередей, кешей и других полезных вещей.
Интеграция с Temporal можно отнести ко второму пункту, но я бы выделил её отдельно. Для тех, кто работает с глобальными workflow или с Temporal в частности, RR из коробки поддерживает поднятие Temporal-сервера на PHP.
Ну и не стоит забывать, что RR делают те же ребята, которые разрабатывают Spiral и другие проекты. Активно поддерживающие PHP-сообщество ну и говорят по-русски. Это даёт им несколько дополнительных очков форы )
*ТСПУ
(открывайте форточку)
А GPU так же будет один на всю линейку 50-ой серии? Разница только в чистоте?
летом была подобная штука с d подсетью, просто легла на пару часов. печально всё это
d подсеть ничем не задело, за b не скажу
где-то поперхнулся react-native
Мда. ИТ-Сисуритлу, который мы заслужили в 24 году. "Если забыть про access-control, то любой сможет получить доступ ко всем данным".
И что дальше? "Не забывайте закрыть автомобиль, а то любой сможет в него сесть"?
Столбцы в постгри местами уже можно менять?
одобряю, но пахнет кумовством )
@butschster мужик! фарт-тайм -- мужики. rr -- мужики! темпурал вообще топ. с огромным удовольствием читаю ваши подборки php новостей в вашем чате и на телеграфе, увы, пхпшторм дневник ушёл куда-то в другую сторону
полнейший фейспалм. беру свои слова обратно. ждать не стоило.
много лет пишу кроссплатформу. начинал с натива, потом был phonegap/cordova (pwa), потом перелез на react native. не для наброса на вентилятор, но справедливости для пробегусь по минусам RN:
Хоть JSX и использует JavaScript, что делает его намного понятнее, нельзя не отметить довольно сложный и запутанный синтаксис этого языка.
сложность и запутанность javascript? это по сравнению с явой то?
React Native не предоставляет полный доступ к нативным функциям устройства, что может затруднять разработку.
интересно, каким образом RN ограничивает доступ к функциям устройства? ну т.е. этот пункт надо вычеркнуть и забыть, что он вообще был, это просто глупость.
Нестабильная работа на разных устройствах и платформах, помимо этого из-за постоянных обновлений множество функций может быть удаленно или изменено.
это дань кроссплатформе. любое приложение, адаптированное под все возможные платформы так или иначе будет отваливаться то там то тут. увы, андроид в целом нестабильная штука. сейчас такого я не встречал, но раньше, например, было нормально, что у определённых устройств мог отваливаться wifi модуль или gps. просто без причин. и ты, как разработчик, сначала код дебажишь свой, а потом едешь и покупаешь устройство, чтобы отловить этот баг. а когда понимаешь, что дело не в твоём приложении, а в конкретном устройстве -- начинаешь думать, как бы это донести до клиента.
Приложения, созданные с использованием React Native, менее производительными по сравнению с нативными приложениями из-за моста JavaScript и самой концепции кросс-платформенного кода. Это может быть особенно заметно при работе с большим объемом данных или сложными анимациями.
это очевидно, т.к. действительно кроссплатформа даёт прилично оверхеда. на самом деле современный RN стал быстрым, современные андройды стали быстрыми, разницы конечный клиент по сути и не заметит, но да действительно, если считать миллисекунды на бутстрапе -- натив победит. про большой объём данных -- допустим, что автор просто опечатался, т.к. нет никакой разницы из натива ты работаешь с большими данными или из rn. про сложные анимации вообще смешно, reanimated настолько подняли планку, что не каждый нативщик сможет так же просто и быстро делать 60fps анимацию.
Создание сложных пользовательских интерфейсов может быть более сложным с использованием React Native по сравнению с нативными разработками из-за ограниченности фреймворка.
а в чём ограниченность фреймворка? тут автор прав при одном условии -- если rn пишут новички, то действительно приложение будет запутанным и сложным для понимания. свобода, которую даёт jsx+javascript играет в обратную сторону, если проект делает не опытная команда. в этом плане android studio, конечно, всё же обязаывает разработчика писать "правильно" и не придумывать велосипед. но опять же, всё зависит от команды.
В отличие от нативной разработки, React Native может ограничить доступ к некоторым функциям и возможностям, доступным только на конкретной платформе. То есть то что работает на iOS в лучшем случае будет выдавать ошибку на Android.
опять же, к некоторым, это например к каким? и что, например, будет работать на иос и будет выдавать ошибку в андройде?
Использование сторонних библиотек и плагинов может привести к проблемам совместимости или возникновению ошибок в процессе разработки. При этом зачастую их использование необходимо для реализации определённого функционала.
и ничего не мешает разработчику исправить код этих "плагинов"... ровно так же, как и в нативе.
laravel-websockets 3 недели как archived... последний релиз в августе 2023, с тех пор куча ошибок, связанных с неверными версиями зависимостей. тут либо ждать https://reverb.laravel.com/, либо юзать что-то вроде https://mercure.rocks/
есть мнение, что ребята из Фланта всё же разбираются в кубере )
nginxconfig.io уже не торт?
ну да, тоже пришёл к этому выводу, чтобы обеспечить доступность, в узких кейсах нужны два шага.
Приветствую, werf прекрасна, спасибо за вашу работу.
Подскажите по поводу "Запуск миграций до релиза".
Есть кластер, есть отдельно база. Вариант с обновлением кода, потом миграцией, потом траффиком -- подходит, но смущает, что пауза между миграцией и переброской траффика -- существенная, несколько секунд. Тогда как миграция может похерить часть кода в определённых кейсах (например, переименование таблиц итп). Есть какие-то механизмы и обновления кодовой базы и сразу создания нужных подов/ингресов, чтобы после миграции моментально переключить траффик? Или общий совет, подобные кейсы решать в 2 шага (код, понимающий и старые названия таблиц и новые, потом миграция + новый код с новыми таблицами)?