То есть вы считаете, что указать в селекте / отфильтровать на бэке нужные клиенту поля это бОльший оверхед, чем весь тот код, который gql привносит на бэк своим существованием?
Я могу из своего опыта сказать (соответственно, моя предметная область - малые и средние сайты c2b, скажем так. Несколько десятков эндпойнтов/методов на backend API)
80% запросов на бэк - кастомные. Нужно писать контроллеры со своей логикой.
20% - из разряда CRUD хоть с сущностями хоть с нет (которые типа ложатся на REST или GraphQL - ваш getOrderWithProductsAndCustomers ). Если нет вложенных сущностей - все ок. Если есть- написать свой универсальный функционал добавления одного вложенного уровня в зависимости от параметра запроса - несложно. Свой маленький удобный QL
80% запросов - кастомные. Иначе если логику переносить на фронт (бэк - типа просто доступ к БД), то будет огромный оверхед по запросам
GraphQL - это невероятное усложнение коммуникации фронта с бэком, подходит наверно для каких-то очень редких случаев public API
REST - это зоопарк без удобных стандартов и даже особо бест практик.
JSON-RPC дает строгость, стандарты и порядок, который ты сам и задаешь. Всё гениальное - просто
Представьте несколько абсолютно разных страниц, которые написаны на разных фреймворках, но объединены в одно приложение. Это и есть MFE, или микрофронтенды.
Странное определение
А если у меня веб приложение на одном Vue, и в нем две слабо связанные части которые независимо пишут две команды - это не микрофронтенды?
Кто-то не в курсе, что горячая уже идёт больше года?
Ангина и туберкулез это разные вещи (в аспекте обсуждаемой статьи)
А так, да - жизнь много раз подтверждала и в большом IT и малом, что нужно стремиться пользоваться только стандартными технологиями и практиками. Нестандартные реализовывать самому или иметь дублера на подхвате
На самом деле, на выделенном сервере можно держать не только почту, верней, почту пристроить к другому серверу можно, раз уж тут айтишники. Так что за сервер особо денег не нужно. Нужно на админа, который один раз всё это настроит и потом иногда будет решать возникающие вопросы, чтобы самому времени не тратить. А это точно дешевле яндекса получится.
Я вообще не понимаю почему почтовые сервисы гигантов такие деньги дерут за каждого пользователя. Как будто у них к каждому индивидуальный подход
Вы так легко оперируете выражениями "длина", "расстояние", "короче"...
Скажите, пожалуйста, а что такое длина произвольной линии? В классической планиметрии есть только длина ломанной, являющейся суммой длин её отрезков. А длина отрезка задается через единичный отрезок. В классической математике длина произвольной линии появляется только после введения понятия "меры" и операций дифференцирования и интегрирования в курсе математического анализа, но у вас и Франца Симашко, верно, свое виденье. Судя по предложению ученикам работать с лупой, вы также и длину линии замеряете, наверно, ниточкой?
Дайте определение длины произвольной линии, пожалуйста.
То есть вы считаете, что указать в селекте / отфильтровать на бэке нужные клиенту поля это бОльший оверхед, чем весь тот код, который gql привносит на бэк своим существованием?
Это о чем?
Пример
Вот эта аргументация, что если несколько типов клиентов, то gql лучше rest или json-rpc - она откуда берется?
В чем именно лучше?
Я могу из своего опыта сказать (соответственно, моя предметная область - малые и средние сайты c2b, скажем так. Несколько десятков эндпойнтов/методов на backend API)
80% запросов на бэк - кастомные. Нужно писать контроллеры со своей логикой.
20% - из разряда CRUD хоть с сущностями хоть с нет (которые типа ложатся на REST или GraphQL - ваш getOrderWithProductsAndCustomers ).
Если нет вложенных сущностей - все ок. Если есть- написать свой универсальный функционал добавления одного вложенного уровня в зависимости от параметра запроса - несложно. Свой маленький удобный QL
80% запросов - кастомные. Иначе если логику переносить на фронт (бэк - типа просто доступ к БД), то будет огромный оверхед по запросам
GraphQL - это невероятное усложнение коммуникации фронта с бэком, подходит наверно для каких-то очень редких случаев public API
REST - это зоопарк без удобных стандартов и даже особо бест практик.
JSON-RPC дает строгость, стандарты и порядок, который ты сам и задаешь. Всё гениальное - просто
Вот моя статья о нем - https://habr.com/ru/articles/709362/
JSON-RPC
Остальное от лукавого
Чисто для пушей можно и приложение сделать
Напоминает, как Телеграм 5 лет назад пытался пролезть сквозь редуты Роскомнадзора. У него получилось. А Сбер чего-то...
Не поместится...
Плюс, прививаться надо регулярно. Дополнительные расходы...
Странное определение
А если у меня веб приложение на одном Vue, и в нем две слабо связанные части которые независимо пишут две команды - это не микрофронтенды?
Закрытый ключ шифруешь, стеганографируешь в картинку, и на флешку
Ангина и туберкулез это разные вещи (в аспекте обсуждаемой статьи)
А так, да - жизнь много раз подтверждала и в большом IT и малом, что нужно стремиться пользоваться только стандартными технологиями и практиками. Нестандартные реализовывать самому или иметь дублера на подхвате
Похоже на подготовку к холодной войне..
Хотя и сам стал задумываться об упрощении переезда с одного сервиса на другой.
На самом деле, на выделенном сервере можно держать не только почту, верней, почту пристроить к другому серверу можно, раз уж тут айтишники. Так что за сервер особо денег не нужно. Нужно на админа, который один раз всё это настроит и потом иногда будет решать возникающие вопросы, чтобы самому времени не тратить. А это точно дешевле яндекса получится.
Я вообще не понимаю почему почтовые сервисы гигантов такие деньги дерут за каждого пользователя. Как будто у них к каждому индивидуальный подход
Вы так легко оперируете выражениями "длина", "расстояние", "короче"...
Скажите, пожалуйста, а что такое длина произвольной линии? В классической планиметрии есть только длина ломанной, являющейся суммой длин её отрезков. А длина отрезка задается через единичный отрезок. В классической математике длина произвольной линии появляется только после введения понятия "меры" и операций дифференцирования и интегрирования в курсе математического анализа, но у вас и Франца Симашко, верно, свое виденье. Судя по предложению ученикам работать с лупой, вы также и длину линии замеряете, наверно, ниточкой?
Дайте определение длины произвольной линии, пожалуйста.
За бесконечное время? )
А кому его не должны?
Крипта по закону нынче уже имущество, вроде
Суд признает USDT, суду не предоставлено надлежащих доказательств факта сделки
Вы не видите разницы между "аксиомой" и "утверждением"?
Вы не видите разницы между "аксиомой" и "свойством", и между "линией" и "ломаной"?