Squora, Тогда вам вот ещё момент: если будете брать MacBook Pro, то рассмотрите вариант уже с процессором M4 Pro, а не просто M4. Это иногда путает людей, и они берут более дешёвый вариант, который мало чем от Air отличается. А вот процессор M4 Pro - это точно новый уровень и точно увидите разницу
Squora, Вот, кстати, хорошее видео с более подробным разбором разницы между Air и Pro. Там есть ряд неточностей, но это реальный толковый программер, и его советы можно учитывать. https://www.youtube.com/watch?v=UwjBQpdSjsA&t=201s
Squora, Только видео может забить диск такого размера. Никакие репозитории даже близко не подберутся к 512.
А как я уже писал, для видео лучше купить NAS. Я к своему домашнему NAS подключаюсь извне через VPN, и могу смотреть свои видосы из любой точки мира
Squora, Вам стоит ещё учесть, что Маки не сильно падают в цене на вторичном рынке. И если вам "в будущем" чего-то не будет хватать, то продадите этот и купите новый. А ведь вот это нехватающее "в будущем" может и не наступить вовсе. Зато ворчание о том, что ноут не такой лёгкий и удобный как Air, и я за это неудобство ещё и доплатил, наступит в первый же день использования
Squora, Внимательно подумайте, что такое огромное вы будете хранить на ноуте, что вам не хватит 512 SSD.
Я давным-давно купил себе Synology NAS, и всё кино и смонтированное видео хранится там.
У меня мильон проектов, я вообще не думаю об экономии места и каким-то образом мне этой памяти с головой хватает.
512 SSD + NAS - и нет проблем
rPman, websockets - это не http. Это совершенно другой протокол. Соединение только инициируется через http с заголовком Upgrade: websocket. И далее общение по http заменяется общением по websocket по тому же самому TCP/IP соединению.
А в SSE используется тот же http.
И хоть поддержка в браузере есть и у того и у другого, но обрабатывать SSE на клиенте всё равно значительно проще. В SSE можно подписываться на конкретные события. А у вебсокетов один общий хэндлер. Реконнект у SSE автоматический, а не ручной, как у websockets.
rPman, Вебсокеты сложнее вообще для всех. И для клиента и для сервера. А зачем? Просто чтобы получить сигнал о том, что данные изменились? Их надо выбирать, если вы пишете чат в реальном времени для кучи народу, игру или аналог Google Docs. Для большинства остальных случаев это чудовищный оверкилл.
SSE работает тупо на HTTP. EventSource API поддерживается напрямую браузером со всеми ретраями, реконнектами и стандартными сообщениями об ошибках. Нужен просто Javascript и ничего более.
Shurik, Погуглите, как правильно настраивать nginx location под вебсокеты. Там есть ряд особенностей, на которые стоит обратить внимание. В таком конкретном вопросе вам Гугл поможет больше меня
Shurik, Вот я попросил у ИИ накидать как объединить всё что вам нужно в докере. Не проверял ничего, глянул по-быстрому, вроде всё там норм. Но идея вам должна быть понятна.
Shurik, Не надо вам лезть в unix сокеты.
У вас несколько контейнеров на одном сервере. У каждого контейнера открыты свои специфические порты.
Nginx у вас должен работать в качестве reverse-proxy для ваших внутренних контейнеров с разными частями приложения.
Поэтому Nginx желательно вынести в отдельный контейнер. PHP-FPM - еще один контейнер. А вебсокеты - третий контейнер, которому в докере нужно будет назначить автоматический рестарт.
reverse-proxy в контейнере Nginx будет заниматься пробросом данных в тот или иной контейнер с теми или иными параметрами соединения в зависимости от урла.
Рекомендую все три конейнера объединить в docker-compose, который создаёт между контейнерами внутреннюю сеть, и тогда вам даже порты открывать не придётся, а слать запросы на хостнеймы, описанные в docker-compose.yaml
Shurik, Очень часто люди влезают в вебсокеты, даже не зная о существовании такой прекрасной технологии, как SSE (Server-Sent Events). Это вебсокеты "для бедных". Канал связи однонаправленный, с сервера в браузер. Работает через HTTP
Браузер подписывается на получение событий от SSE-сервера. PHP шлёт на SSE-сервер запрос о том, что событие возникло, и SSE-сервер уже рассылает это событие всем подписанным на него браузерам.
Таким образом: Если один человек изменяет список, то всем подписанным на это событие браузерам сообщается, что список изменился, и они могут получить новые данные обычным HTTP-запросом. Либо можно даже новые данные передавать в этом же событии.
Рекомендую освоить сначала этот подход. Вы поймёте, как работает эта схема асинхронного общения, отшлифуете её, а потом, если понадобится, вникнете уже в вебсокеты. Понимание самой сути асинхронной работы с сервером поможет вам потом и в некоторых аспектах эффективного использования весбокетов. Вы наработаете для себя паттерны этих процессов обмена данными.
Вот описание процесса для Symfony. Нужно будет дополнительно установить Mercure Hub. Это сервис, написанный на Go, который как раз занимается реализацией схемы publish/subscribe для SSE https://symfony.com/doc/current/mercure.html
У себя в PHP приложении вы будете отправлять сообщения через банальшейший Symfony messenger, а Mercure Hub автоматом разошлёт его всем клиентам
Shurik, Мне интересен один момент. А вам именно вебсокеты нужны? Какую задачу вы решаете.
Потому как если вам нужно только периодически отправлять какие-то сообщения с сервера на фронтенд, то есть гораздо более простое решение.
Shurik, Тогда вам желательно использовать именно Ratchet. Можете либо напрямую его имплементить у себя, либо нагуглить уже готовый бандл, который вам подойдёт.
Иван Родичев, Умеешь видеть чужой код на расстоянии даже в приватном репозитории? Зря теряешь тут время, тебе надо в ФСБ работать. Иначе такой уверенности ничем не объяснить. Помог бы уже тогда человеку вместо болтовни.
А вот я кода не видел... И ну вот не знаю я где и как там id генерируется, ничего не вижу кроме слов.
Илья, Я вам дам подсказку, которая очень сильно вам поможет, если вы будете где-то работать начинающим программистом в команде с очень опытным сеньором, которому в обязанности вменили вам помогать профессионально расти. Постарайтесь вникнуть в то, как другие люди думают.
Если у вас что-то не будет получаться, и вы просто с разбегу подойдёте к этому человеку с вопросом: "у меня тут не работает, помоги", то, в зависимости от характера человека либо от его настроения, вы можете получить очень разные вариации крайне токсичных и даже до слёз обидных ответов.
Почему так происходит? Потому что у человека куча своих дел, проект горит и т.д. и т.п., и кого он видит перед глазами? Очень ленивого человека, которому было влом сделать даже ряд простых действий перед обращением. И все эти действия теперь придётся делать ему самому, а вы будете у окна ворон считать.
Что должен сделать начинающий перед обращением к сеньору?
- Загуглить гугл до 125-й страницы выдачи, пока там уже порно не появится.
- Запромтить ChatGPT до тяжёлых галлюцинаций и отказа работать с вами.
- Затрейсить вашу программу до значений в регистрах процессора.
- Перепробовать 100500 раз переписать забагованный участок кода в разных парадигмах программирования на трёх разных языках программирования.
Я, конечно, преувеличиваю, но смысл вы, надеюсь поняли.
Скорей всего, после такого процесса вы сами найдёте баг. Но если даже не найдёте, то смело идите на консультацию.
И тогда вы не поверите! Если вы подойдёте к тому же самому человеку, находящемуся в том же самом настроении с такой кучей информации, то, скорей всего, он через несколько секунд сможет найти баг, а потом с улыбкой расскажет вам, что это за баг, почему он происходит, и как его избегать в будущем. И станет потом вас больше уважать.
Почему так происходит? Мы, люди, существа общественные. И что бы вам не вещали вокруг в духе "человек человеку волк", но нам очень нравится помогать другим людям, которые находятся в беде или затруднении. Даже безвозмездно. За одним редким исключением: когда человек этот ленивый халявщик. Не воспринимайте на свой счёт, просто именно в таком свете зачастую видят человека, который предоставляет крайне недостаточно информации для помощи ему же.
Илья, Это ничего не значит. Браузер может кэшировать preflight запросы.
Может быть, ваш бэкенд устанавливает в ответе хедер Access-Control-Max-Age. Там содержится время, в течение которого не будут повторно отправляться OPTIONS запросы для одного и того же запроса.
Михаил Ливач, Т.е. вы даже шаблонизаторами не пользуетесь, насколько я понимаю? Потому как у twig, например, точно такая же ситуация в IDE в плане подсветки.
Проблемы с шаблонами возникают у людей, пытающихся пихать в них тонны логики. И тогда в них действительно невозможно разобраться. В шаблоне должны использоваться только переменные, простейшие условия и простейшие циклы. Также шаблоны должны быть разбиты на небольшие блоки.
Я, вообще, считаю, что плохая репутация PHP в сообществе большей частью вызвана именно решением сделать PHP так же и шаблонизатором HTML. Да, это помогло очень быстро и просто клепать сайты, но это же и породило такие тонны го*нокода, что у людей, занимавшихся рефакторингом, случился пост-травматический синдром после работы с PHP. Когда я вижу, что React с их JSX наступает со всей силы на те же грабли, мне плохо становится. Потому что люди ничему не учатся...
Twig как раз и создавался с целью максимально усложнить создание хитрой логики в шаблонах. И это позволило сделать код чистым и простым. Но до сих пор убеждать людей, что PHP - неплохой язык программирования, крайне тяжело.
