Скажите пожалуйста, а зачем вы вводите клиентов в заблуждение, говоря им о том, что наше оборудование принадлежит компании REG.RU?
накал страстей нешуточный из-за ваших писем, что все сломается
Простите, но в нашем письме, которое мы отправили нашим клиентам, нет ни слова о том, что что-либо будет ломаться. Вы снова распространяете дезинформацию?
Поясню, что было с нашей стороны (если мы правильно прочитали мутные формулировки в жалобе).
1. Мы никогда и ни при каких обстоятельствах не выполняли никакие запросы auth-кодов для переноса домена в момент его продления.
2. Перенос домена возможен только явно (для стимуляции мы придумали акцию beget.com/ru/news/2018/transfer-renewal). Кстати, такая акция теперь есть и наших конкурентов.
3. Никаких ссылок/скриптов в письмах нет (а как вообще можно скрипт в письме разместить? :)
4. Более того, мы даже никакую рассылку про эту акцию не делали.
5. Никакой передачи персональных данных в процедуре переноса нет и не может быть.
Поэтому нам тоже очень интересно, что же за письма в приложениях. Возможно их вообще не мы отправляли?
> что «Бегет» отказался исправлять выявленные нарушения
Конечно Бегет никогда не отказывается исправлять какие-либо нарушения. Особенно, если речь идет об уязвимостях или технических несовершенствах, то мы всегда рады фидбеку и незамедлительно их устраняем. Хороший пример — программа Bug Bounty, которую мы запускали в прошлом году и выплатили достаточно много денег за найденные проблемы тем, кто сообщал нам о таких вещах.
В данном случае стоит явно отметить, что мы не получали никакого уведомления с претензиями или указанием на наши некорректные действия. Более того, мы до сих пор не получили от бывших коллег никакой конкретной информации о причинах, побудивших их расторгнуть договор.
главное чтобы компоненты были написаны правильно и не текла память
Из-за этого мы не рискнули применять такой подход. Ранее рассматривали вариант перехода на PHP-PM, который работает по схожему принципу. Но у нас довольно много сишных екстеншенов используется и стороннего кода из Composer. Сложно ручаться за все библиотеки.
И еще страшно за транзакции/сейвпоинты в БД. Если где-то в одном месте она не закрыта случайно, то, кажется, все следующие запросы будут под угрозой. Навскидку приходит только либо отдать контроль за этим приложению (ввести счетчик и надеяться, что все будут открывать транзакции через контроллируемый нами метод), либо перед обработкой запроса ходить в БД за информацией о транзакции на этом подключении.
В любом случае хорошо, что в мире PHP потихоньку происходит изменение подхода к построению приложений. Лично я надеюсь, что в будущем появится больше удобств для создания фуллстек-приложений и со стороны интерпретатора.
Ваш проект тоже достаточно интересный. Но, насколько я понял, вам была важна производительность. Нам же было важно научить существующий код работать через новый интерфейс без смены фреймворка. В вашем случае стандартные фреймворки, скорее всего, не смогут корректно работать в условиях долгоживущего процесса.
А насчет оптимизации производительности: у вас интересный порядок цифр 10-30 раз. Если не секрет, с чем производилось сравнение?
Не очень понятно, что именно подразумевается под «этим чудом» и о каком тестировании идет речь. Если речь идет о том, как тестировать API, то ответ простой: так же, как любое другое API. Клиент генерируется автоматически. Остается лишь написать ассерты.
REST, на мой взгляд — достаточно ущербный стиль взаимодействия, который добавляет больше проблем и неоднозначностей, чем решает. Далеко не любые бизнес-процессы можно выразить с помощью REST: если у вас что-то сложнее чем CRUD, то начинаются проблемы. Ведь в REST мы говорим существительными и оперируем ресурсами. В классическом RPC — глаголами. Бизнес-процессы удобнее выражать глаголами.
Что касается gRPC: у нас много сервисов на разных ЯП и нам удобно:
Описывать API одинаково и на нормальном языке.
Генерировать из него клиенты и серверы. Весь тулинг официальный и активно поддерживается. Сами proto-файлы с описанием сервисов мы подключаем субмодулями в нужные проекты. Все стандартизировано и достаточно удобно. Само API проходит code review.
Честно говоря не очень понял, что имеется в виду под "спецификой protobuf-протокола", т.к. protobuf — это способ сериализации данных со схемой. Лично нам он очень приглянулся из-за его однозначности и удобства для восприятия. Также классная штука oneof: очень удобно возвращать ошибки из метода.
Ребятам на фронтенд мы тоже даем читать обычные proto-файлы. В них есть и информация о том, как вызвать метод по http и все структуры прозрачно конвертируются в json. Это все вместо (имхо), совершенно неадекватного описания web-api через тот же сваггер, которое больно читать.
Также есть реальная надежда на приход gRPC на фронтенд в полном виде. В этом случае у нас все готово: убираем конвертацию в json и все.
Thrift рассматривали. Очень похож на gRPC и на первый взгляд все здорово, но сам проект еле живой и совсем не развивается.
Мы приспособили его к web с помощью grpc-gateway. Да, оно конвертит в тот же пресловутый json, но на стороне сервиса мы все еще пишем api на gRPC и не пытаемся заигрывать с REST. Сейчас также изучаем возможность работы с нативным gRPC на клиенте.
CLI действительно менее удобный. Однако, по сравнению с сваггером (OpenAPI) тут есть вменяемый красивый DSL.
Что и требовалось доказать: никакого замедления в 100500 раз нет. Поскольку все происходит в рантайме, то конечно есть накладные расходы небольшие, это и так достаточно очевидно. Но так бы мы писали эти же проверки и касты самостоятельно.
Этот доклад — расшифровка одного из лучших выступлений на конференции разработчиков высоконагруженных систем HighLoad++.
Выступление может и лучшее (ну, допустим докладчик там жонглировал на сцене по ходу доклада), но вот содержание хромает и, как мне кажется, не тянет на конференцию с таким громким названием.
По сути это неполный пересказ документации о memcache, redis и, особенно RabbitMQ без каких-то интересных кейсов или неочевидных особенностей.
Надеюсь организаторы изменят политику по отбору докладов (я был на вашей конференции год назад), и будет больше хардкора.
Справедливости ради надо отметить, что это весьма холиварная тема: ADM против RDM. Есть несколько трактований понятия «Модель» и пара лагерей, которые кидают друг в друга какашками.
Но в общем случае модель — это не только данные, но и методы по их обработке. А вот где они находятся — в сервисах или в других классах — вопрос десятый.
IDE подскажет класс, а зайти в класс потратить пару минут на изучение — это уже скилл программиста.
по-моему, скилл программиста (в данном случае, разработчика D7), заключается, в частности, в том, чтоб догадаться о том, что параметр метода в виде магического массива, для понимания структуры которого надо лезть на сайт с документацией или смотреть исходники метода (а зачастую еще пару методов в глубину надо будет проглядеть) — это не то, что хочет пользователь фреймворка.
А догадаться в этом месте сделать нормальный самодокументрируемый fluent-интерфейс для установки всех параметров — вот это уже больше похоже на скилл программиста
Забавно, что эта, так называемая, «ORM» (хотя что-то мне подсказывает, что до ORM там далеко, но т.к. детально код не смотрел, утверждать не берусь), своим способом конфигурации подозрительно напоминает упомянутый вами AR в Yii1 как пример говнокода (там тоже можно было проинициализировать CDbCriteria магическим массивом): http://www.yiiframework.com/doc/guide/1.1/ru/database.ar
Да и даже в устаревшем Yii1 код и, в частности, ORM, гораздо лучше.
Но иногда действительно не хватает возможности просто передать null в обязательный аргумент.
А как же billion-dollar mistake? Сейчас все языки пытаются избавиться от такой возможности, т.к. это ведет к огромному количеству NPE, а вы хотите это впихнуть в PHP :(
Имхо, лучше делать ограничения и доп. проверки при использовании nullable-типов, например, как это сделано в Kotlin'е.
Простите, но в нашем письме, которое мы отправили нашим клиентам, нет ни слова о том, что что-либо будет ломаться. Вы снова распространяете дезинформацию?
1. Мы никогда и ни при каких обстоятельствах не выполняли никакие запросы auth-кодов для переноса домена в момент его продления.
2. Перенос домена возможен только явно (для стимуляции мы придумали акцию beget.com/ru/news/2018/transfer-renewal). Кстати, такая акция теперь есть и наших конкурентов.
3. Никаких ссылок/скриптов в письмах нет (а как вообще можно скрипт в письме разместить? :)
4. Более того, мы даже никакую рассылку про эту акцию не делали.
5. Никакой передачи персональных данных в процедуре переноса нет и не может быть.
Поэтому нам тоже очень интересно, что же за письма в приложениях. Возможно их вообще не мы отправляли?
Конечно Бегет никогда не отказывается исправлять какие-либо нарушения. Особенно, если речь идет об уязвимостях или технических несовершенствах, то мы всегда рады фидбеку и незамедлительно их устраняем. Хороший пример — программа Bug Bounty, которую мы запускали в прошлом году и выплатили достаточно много денег за найденные проблемы тем, кто сообщал нам о таких вещах.
В данном случае стоит явно отметить, что мы не получали никакого уведомления с претензиями или указанием на наши некорректные действия. Более того, мы до сих пор не получили от бывших коллег никакой конкретной информации о причинах, побудивших их расторгнуть договор.
Пусть каждый выводы сделает сам.
Из-за этого мы не рискнули применять такой подход. Ранее рассматривали вариант перехода на PHP-PM, который работает по схожему принципу. Но у нас довольно много сишных екстеншенов используется и стороннего кода из Composer. Сложно ручаться за все библиотеки.
И еще страшно за транзакции/сейвпоинты в БД. Если где-то в одном месте она не закрыта случайно, то, кажется, все следующие запросы будут под угрозой. Навскидку приходит только либо отдать контроль за этим приложению (ввести счетчик и надеяться, что все будут открывать транзакции через контроллируемый нами метод), либо перед обработкой запроса ходить в БД за информацией о транзакции на этом подключении.
В любом случае хорошо, что в мире PHP потихоньку происходит изменение подхода к построению приложений. Лично я надеюсь, что в будущем появится больше удобств для создания фуллстек-приложений и со стороны интерпретатора.
А насчет оптимизации производительности: у вас интересный порядок цифр 10-30 раз. Если не секрет, с чем производилось сравнение?
REST, на мой взгляд — достаточно ущербный стиль взаимодействия, который добавляет больше проблем и неоднозначностей, чем решает. Далеко не любые бизнес-процессы можно выразить с помощью REST: если у вас что-то сложнее чем CRUD, то начинаются проблемы. Ведь в REST мы говорим существительными и оперируем ресурсами. В классическом RPC — глаголами. Бизнес-процессы удобнее выражать глаголами.
Что касается gRPC: у нас много сервисов на разных ЯП и нам удобно:
Честно говоря не очень понял, что имеется в виду под "спецификой protobuf-протокола", т.к. protobuf — это способ сериализации данных со схемой. Лично нам он очень приглянулся из-за его однозначности и удобства для восприятия. Также классная штука
oneof: очень удобно возвращать ошибки из метода.Ребятам на фронтенд мы тоже даем читать обычные proto-файлы. В них есть и информация о том, как вызвать метод по http и все структуры прозрачно конвертируются в json. Это все вместо (имхо), совершенно неадекватного описания web-api через тот же сваггер, которое больно читать.
Также есть реальная надежда на приход gRPC на фронтенд в полном виде. В этом случае у нас все готово: убираем конвертацию в json и все.
Thrift рассматривали. Очень похож на gRPC и на первый взгляд все здорово, но сам проект еле живой и совсем не развивается.
Мы приспособили его к web с помощью grpc-gateway. Да, оно конвертит в тот же пресловутый json, но на стороне сервиса мы все еще пишем api на gRPC и не пытаемся заигрывать с REST. Сейчас также изучаем возможность работы с нативным gRPC на клиенте.
CLI действительно менее удобный. Однако, по сравнению с сваггером (OpenAPI) тут есть вменяемый красивый DSL.
Поэтому мы забили на REST и перешли на gRPC. Стало гораздо удобнее и однозначнее.
Уточните, пожалуйста, что тут подразумевается под «компонентами»?
Выступление может и лучшее (ну, допустим докладчик там жонглировал на сцене по ходу доклада), но вот содержание хромает и, как мне кажется, не тянет на конференцию с таким громким названием.
По сути это неполный пересказ документации о memcache, redis и, особенно RabbitMQ без каких-то интересных кейсов или неочевидных особенностей.
Надеюсь организаторы изменят политику по отбору докладов (я был на вашей конференции год назад), и будет больше хардкора.
Но в общем случае модель — это не только данные, но и методы по их обработке. А вот где они находятся — в сервисах или в других классах — вопрос десятый.
по-моему, скилл программиста (в данном случае, разработчика D7), заключается, в частности, в том, чтоб догадаться о том, что параметр метода в виде магического массива, для понимания структуры которого надо лезть на сайт с документацией или смотреть исходники метода (а зачастую еще пару методов в глубину надо будет проглядеть) — это не то, что хочет пользователь фреймворка.
А догадаться в этом месте сделать нормальный самодокументрируемый fluent-интерфейс для установки всех параметров — вот это уже больше похоже на скилл программиста
Забавно, что эта, так называемая, «ORM» (хотя что-то мне подсказывает, что до ORM там далеко, но т.к. детально код не смотрел, утверждать не берусь), своим способом конфигурации подозрительно напоминает упомянутый вами AR в Yii1 как пример говнокода (там тоже можно было проинициализировать CDbCriteria магическим массивом): http://www.yiiframework.com/doc/guide/1.1/ru/database.ar
Да и даже в устаревшем Yii1 код и, в частности, ORM, гораздо лучше.
А как же billion-dollar mistake? Сейчас все языки пытаются избавиться от такой возможности, т.к. это ведет к огромному количеству NPE, а вы хотите это впихнуть в PHP :(
Имхо, лучше делать ограничения и доп. проверки при использовании nullable-типов, например, как это сделано в Kotlin'е.