Тут был длинный текст, но habr его съел другой кнопкой ответить, к сожалению…
GraphQL был упомянут в контексте github.com/graphql/dataloader
По поводу проще: думайте о пользователе, которому не важно, что у вас там внутри в архитектуре, а который хочет получить результат за минимальное время. Поэтому тема взаимодействия «frontend» и «backend» на схеме вообще не раскрыта, а от этого зависит все остальное обсуждение. Кто такой фронтенд — браузер в регионах ИЛИ сервис, отдающий готовый HTML? Или и то, и другое (next.js), и еще мобильные приложения?
Network latency, время обработки ответа, легкость разработки/поддержки API, его версионирование, вот это важно. А все остальное — это уже способы достижения этих целей.
Зачем обсуждать протоколы API, если нет контекста? Берите gRPC! :)
Смысл в том, что когда у пользователя есть 5 различных сущностей (например, получить профиль, последние сообщения, счетчик новых откликов и т.д.), то проще упаковать это в batch, чем делать 5 HTTP запросов. А в этот момент на сервере они могут выполниться параллельно.
Вы можете мне возразить, что будет HTTP/2, одно соединение, и там дальше запросы полетят на разные ноды/инстансы приложения. Но если мы говорим о классическом PHP-FPM (не в daemon, типа roadrunner.dev), то конечный RPS будет у вас гораздо меньше из-за оверхеда на обработку каждого запроса на PHP.
Тем более, что «может» и «нужно» неравнозначны
Поэтому половину вашей статьи можно убрать, так как она не соответствует спецификации. Может — это как с проверкой на null: Если в 99% не null, но в 1% null, то вряд ли не нужно проверять на null, иначе все упадет.
получать batch парсить его и раскидывать внутри по нодам
graphql передает привет :)
мы в проектирование API и на REST трудностей не испытываем.
Не знаю, откуда у вас взялись такие тезисы, но давайте разберем.
RPC запросы быстрее и эффективнее, потому, что позволяют делать batch-запросы.
Кол-во batch запросов всегда ограничивается в рамках разумного, например не больше 5.
На схеме у вас master-master репликация? Или вы будете роутить только GET запросы на реплику со всеми известными последствиями.
Использование кеша: на уровне сервера приложений (но в PHP у вас его нет по умолчанию), тут можно отдельную статью писать.
RPC запросы надежнее, потому, что могут выполнять batch-запросы в рамках одной транзакции
В документации написано, что batch запросы могут исполнятся параллельно. Поэтому с транзакциями тут вообще нет никакой связи. The Server MAY process a batch rpc call as a set of concurrent tasks, processing them in any order and with any width of parallelism.
Весь смысл в batch-запросах: запустить их выполнение параллельно на сервере и сделать это в одном HTTP запросе, если возможно.
А смысл в RPC: это проектирование API. Даже gRPC пытаются сделать grpc-gateway, чтобы на бэкенде использовать gRPC, а фронтенд там как-нибудь сам справится.
Привет! Расскажите, пожалуйста, где вы используете еще PHP, помимо сайта, и не планируете ли вы полностью от него отказаться в пользу Go? (например, написав на нем свой PHP :)
Второй вопрос: используете ли вы у себя service discovery (везде или точечно) и есть ли история успеха по этому поводу?
Спасибо!
>у Postgre web’е нет совершенно никаких решающих преимуществ
Я вам расскажу пару преимуществ Postgres в вебе – массивы и hstore c возможностью поиска по индексам. Упрощается структура приложения и базы без потери производительности.
А тут в 9.4 уже jsonb подвезли c CREATE INDEX USING VODKA :)
10, я думаю, это синхронизируемых объектов. В принципе для обычных пользователей этого может быть достаточно, но…
Я тут сделал 1,5 года назад проект для шаринга фоток по альбомам, так вот в итоге альбомов явно будет больше, чем 10. И это меня расстраивает, так как нормальной альтернативы для такого простого шаринга нет (или я не знаю).
У него немного не такой вариант использования. Просто кинуть secret не получится, сначала оба устройства должны добавить друг друга. Для создания своего личного облака — легко, а для простого обмена файлами как BTSync – пока альтернатив я не знаю, кроме как syncapp.bittorrent.com/1.4.111/ )
The total number of folders which can be kept synced via FREE version at a time is limited to 10. If you have already added 10 folders, and want to add one more, you will have to delete at least 1 folder from the previously added ones or upgrade to PRO.
Прототип прикольный, вот вам сходу пара наблюдений:
– я выбираю аэропорт в поиске по коду IATA, но когда я ввел AER, попал в Фукусиму (в принципе, я не против, но билетов не нашлось) :)
– очень долго думал, где же посмотреть обратный перелет. Наверху как-то информативнее нужно будет сделать.
>для включения и выключения телевизора используется одна и та же ИК команда
Обычно у современных телеков идет отдельно Power On, Power Off и Power Toggle. Что за модель у вас?
Добавлю ещё: можно на значения ключей повесить индексы, сделать полнотекстовый поиск опять же.
А так — лучше получается вариант 3а: в таблице Entity отдельные hstore поля для каждого языка (например, ruLang, enLang), а в этих полях: ключ — имя поля таблицы (например, name, title, description), значение — перевод. И это очень удобно использовать в объектной модели и в коде (например есть возможность переопределить стандартные поля у объектов переводами из полей).
GraphQL был упомянут в контексте github.com/graphql/dataloader
По поводу проще: думайте о пользователе, которому не важно, что у вас там внутри в архитектуре, а который хочет получить результат за минимальное время. Поэтому тема взаимодействия «frontend» и «backend» на схеме вообще не раскрыта, а от этого зависит все остальное обсуждение. Кто такой фронтенд — браузер в регионах ИЛИ сервис, отдающий готовый HTML? Или и то, и другое (next.js), и еще мобильные приложения?
Network latency, время обработки ответа, легкость разработки/поддержки API, его версионирование, вот это важно. А все остальное — это уже способы достижения этих целей.
Зачем обсуждать протоколы API, если нет контекста? Берите gRPC! :)
Вы можете мне возразить, что будет HTTP/2, одно соединение, и там дальше запросы полетят на разные ноды/инстансы приложения. Но если мы говорим о классическом PHP-FPM (не в daemon, типа roadrunner.dev), то конечный RPS будет у вас гораздо меньше из-за оверхеда на обработку каждого запроса на PHP.
Поэтому половину вашей статьи можно убрать, так как она не соответствует спецификации. Может — это как с проверкой на null: Если в 99% не null, но в 1% null, то вряд ли не нужно проверять на null, иначе все упадет.
graphql передает привет :)
Рад за вас.
Кол-во batch запросов всегда ограничивается в рамках разумного, например не больше 5.
На схеме у вас master-master репликация? Или вы будете роутить только GET запросы на реплику со всеми известными последствиями.
Использование кеша: на уровне сервера приложений (но в PHP у вас его нет по умолчанию), тут можно отдельную статью писать.
В документации написано, что batch запросы могут исполнятся параллельно. Поэтому с транзакциями тут вообще нет никакой связи.
The Server MAY process a batch rpc call as a set of concurrent tasks, processing them in any order and with any width of parallelism.
Весь смысл в batch-запросах: запустить их выполнение параллельно на сервере и сделать это в одном HTTP запросе, если возможно.
А смысл в RPC: это проектирование API. Даже gRPC пытаются сделать grpc-gateway, чтобы на бэкенде использовать gRPC, а фронтенд там как-нибудь сам справится.
Возможно пригодится
Так же есть еще генерация сваггера (все в репозитории выше), пример api.myshows.me/shared/doc, пример endpoint'a api.myshows.me/v2/rpc/?smd
Удалось сделать даже документацию ошибок, которые есть в JSON-RPC. Ну и генерация самого клиента тоже есть. Вот так это все примерно выглядит (smdbox)
Второй вопрос: используете ли вы у себя service discovery (везде или точечно) и есть ли история успеха по этому поводу?
Спасибо!
Я вам расскажу пару преимуществ Postgres в вебе – массивы и hstore c возможностью поиска по индексам. Упрощается структура приложения и базы без потери производительности.
А тут в 9.4 уже jsonb подвезли c CREATE INDEX USING VODKA :)
Я тут сделал 1,5 года назад проект для шаринга фоток по альбомам, так вот в итоге альбомов явно будет больше, чем 10. И это меня расстраивает, так как нормальной альтернативы для такого простого шаринга нет (или я не знаю).
APK есть тут, но вот что делать с iOS – я не знаю(
– я выбираю аэропорт в поиске по коду IATA, но когда я ввел AER, попал в Фукусиму (в принципе, я не против, но билетов не нашлось) :)
– очень долго думал, где же посмотреть обратный перелет. Наверху как-то информативнее нужно будет сделать.
В блокноте доменов небольшой баг есть — mytvsho.ws — не обновляет автоматически.
Обычно у современных телеков идет отдельно Power On, Power Off и Power Toggle. Что за модель у вас?
— Я обошел 10 файрволл и подключился к местным камерам!
А так — лучше получается вариант 3а: в таблице Entity отдельные hstore поля для каждого языка (например, ruLang, enLang), а в этих полях: ключ — имя поля таблицы (например, name, title, description), значение — перевод. И это очень удобно использовать в объектной модели и в коде (например есть возможность переопределить стандартные поля у объектов переводами из полей).