производительный (относительно) клиент И сервер, желательно на [Open]Swoole. Условно говоря, мне нужен прокси (по смыслу).
И оно всё работает конечно, но только Swoole плодит кучу воркеров/процессов, у каждого из которых свой кусок памяти и соотв. доступа к данным другого воркера нет.
Вообще возможен такой вариант о котором я говорю или проще на чем-то другом написать?
*расшарить данные нужно между клиентом и сервером в данном случае, т.е. 1 клиент подключается к удаленному серверу и далее — рассылает входящие данные всем своим клиентам
Зачем пытаться выжать из пхп то, для чего он не предназначен? Используйте многопоточные ЯП, например Go, он ближе всего к пхп, хотя бы для общения клиент-сервер, а там уже передавайте обработанные данные в пхп
оно уже частично написано на Go (за неимением лучшего в общем-то), но задача относительно примитивная и не хотелось из-за этого плодить зоопарк, плюс ко всему, за несколько лет я так и не смог пока привыкнуть к тому, что в Go всё "прибито гвоздями" :)))
По описанию ты переизобретаеш паб саб. И первая мысль чел решил своего кролика написать . Те раббитМКю.
Т.е. плодить костыли в виде swoole и гораздо менее эффективного использования ресурсов и потенциально большего количества кода лучше? Ну ваше право... > в Go всё "прибито гвоздями" Странное утверждение, но чат не об этом по этому ладно.... > добавить пару простых команд и не пущай оно там работет... Как по мне, идеальная задача для Golang'a, он как раз дял подобных и спроектирован, но ладно, ваш путь мне понятен по этому отстал)
Не не не, никаких кроликов, и даже Redis тут лишний. Просто у меня есть некоторый сервер (внешний), который генерирует данные. И этот сервер — работает как работает, он не мой и повлиять на него я не могу. Данные (с сервера) нужно раздать клиентам, но не всем и всё подряд, а отфильтровать их некоторым образом и каждому из клиентов отправить то, что касается его лично — суть в этом. > Странное утверждение, но чат не об этом по этому ладно.... Это не утрвеждение, это моё субъективное мнение. Я до сих пор не могу понять сакрального смысла конвертирования строки в массив байтов и обратно (это не одно и то же, строка не из байтов состоит?), обязаловку про "неиспользуемые переменные", которые любой другой компилятор — просто игнорирует, автоформаттер кода — который делает исправленным (в репозитории) тот код — который я править не собирался, необходимость на каждый JSON-запрос/ответ — создавать структуру, коих в итоге формируется целая прорва (куча вообще не нужного кода, без которого можно отлично жить), в виду сильно ограниченных возможностей по динамическому парсингу данных, отсутствие даже такой банальщины — как тернарные операторы и так далее по списку. А так да, во всём прочем он очень хорош :)))
P.S. На счёт "костыля" в виде [Open]Swoole — согласен, я честно говоря тоже его идеями не слишком проникся. В том плане, что даже примеры с их сайта, запущенные внутри их же фирменного докер-контейнера — без доработки напильником не запускаются. И вообще заставить всё это нормально работать — не слишком тривиальная задача...
> Я до сих пор не могу понять сакрального смысла конвертирования строки в массив байтов и обратно > строка не из байтов состоит? - Ну так то любые данные из байтов состоят, что теперь, нам вообще от типов отказаться?) К слову в каком конкретно случае тебе приходится строку в массив байтов и обратно конвертировать?) > обязаловку про "неиспользуемые переменные", которые любой другой компилятор — просто игнорирует - И слава богу что она есть, если бы в php все неиспользуемые переменные и методы заставляли удалять... эх... сколько бы говнокода с проектов ушло > автоформаттер кода — который делает исправленным (в репозитории) тот код — который я править не собирался - Даже боюсь представить что там такого исправил автоформаттер, чего ты исправлять не планировал)) Он же просто отступы правит и то только в некоторых случаях... к слову, его запускает ide или ci/cd, его запуск совсем не обязателен > необходимость на каждый JSON-запрос/ответ — создавать структуру, коих в итоге формируется целая прорва (куча вообще не нужного кода, без которого можно отлично жить) - Ну тут уж глупость, сделай себе var response map[string]any и парси в него свой ответ, будет совсем как в пхп, хочешь строгую структуру - создавай собственно структуру, но так то и в ларавель на каждый реквест нужно создавать FormData Request, если нужна жесткая структура и кода получается ровно столько же > отсутствие даже такой банальщины — как тернарные операторы - Гы, тернарные операторы - зло, их не делают сознательно. Собственно запретом на циклические импорты, автоформаттером, отсутствием тернарных операторов и запретом создавать неиспользуемые переменные (а еще кучей тулзов) авторы го пытаются минимизировать количество говнокода и у них это неплохо получается хочу заметить Ну в общем то защищать го бессмысленно, большинство современного ПО которое используется в вебе сейчас теми же пхп шниками - написано на го, от докера до графаны)
@SlyPepper по поводу реквестов к слову структуру тоже не обязательно создавать, пользуйся: req, _ := json.Marshal(map[string]any{ "test": true, }) http.Post("http://google.com", "application/json", bytes.NewBuffer(req))
Это очень полезное замечание, спасибо! Вот именно так — никогда раньше не писал. Надо тоже попробовать/проверить/оценить.
Ну тут уж глупость, сделай себе var response map[string]any Посмотрел что это — тут пишут, что это алиас для interface{}. Это не то, что я бы я стал называть "Динамическим объектом". Из этого объекта, без бутылки и тёмной магии, просто так — нельзя вытащить поля, нужно опять таки, либо приводить их к строго типизированной структуре (или типу, в простейших случая), или через известное место данные оттуда доставать. Иными словами — это не решает проблему "куча структур, которые можно было бы не делать".
Центрифуга
Если нужно вытащить одно два поля, то никаких проблем не вижу с тайпкастингом, элементарно: var resp map[string]any v, ok := resp["fooField"] if !ok { // fooField not exists error } v, ok = v.(string) if !ok { // fooField is not string } А если это более сложная структура, с которой дальше надо работать и вытягивать поля, то извольте, вообще то и в ООП надо для подобного создавать класс, к слову всегда можно создать анонимную структуру прямо в том же методе, в котором получаешь ответ: respStruct := struct { Name string `json:"name"` Email string `json:"email"` }{} Я искрине считаю что проблема надумана, и, если с остальными предметами обсуждения могу понять твою точку зрения, то тут не могу)
Спасибо большое за информацию! Я попробую. Мне лично проблема надуманной не кажется, но возможно, выше описанный способ — действительно ее решает. Обязательно попробую.
Обсуждают сегодня