Если кто-то поменяет поля без обратной совместимости, у вас обычные клиенты тоже сломаются. Какая разница, где чинить, в graphql gateway или на клиентах. Тут проблема не в graphql
Доклад может посмотрю. Это он? https://youtu.be/v3m93Xj_BRU?si=5GMaO8k_1Q0YmJeu
А вы про графкл из своего опыта пишете? Исходя из ваших вопросов, кажется, что нет.
Там прямо в стандарте прописано, как работает валидация и как репортятся ошибки. И можно частично загрузить данные при этом (часть графа).
Если у вас есть готовый рест, то графкл очень приятно собирает несколько всех ваших рест ендпоинтов в одну схему. И FE достаточно сделать один запрос, чтобы загрузить связанные данные. Например: фио заказчика, сумму заказа и статус доставки. Которые живут в разных доменах и, возможно, разных сервисах.
Зачастую такие Gateway организуют сами FE разработчики для себя. Чтобы упростить работу со множеством rest endpoint'ов
А что, эта проблема как-то специфична для США или английского языка? Или вам без русскоязычных примеров статья не понятна?
Какие учёные собрали статистику, оттуда и пришла новость
Спасибо автору статьи за публикацию, лично для меня она интересна. А вот последующая статья о "российские учёные обнаружили что chatgpt влияет на язык россиян" (или поставьте любую другую нацию) мне будет совершенно не интересна, т.к. в этом не будет ничего нового.
А что, эта проблема как-то специфична для США или английского языка? Или вам без русскоязычных примеров статья не понятна?
Какие учёные собрали статистику, оттуда и пришла новость
Спасибо автору статьи за публикацию, лично для меня она интересна. А вот последующая статья о "российские учёные обнаружили что chatgpt влияет на язык россиян" (или поставьте любую другую нацию) мне будет совершенно не интересна, т.к. в этом не будет ничего нового.
Спейсы чаще всего указывают (или это утекает), что входит в программу следующего тестового полета. ДО этого полёта. Поэтому очень легко понять, что по результатам получилось, а что нет. По крайней мере такие крупные вещи, как посадка на воду, известны заранее.
Когда три предыдущих полёта провалились, то с этим особо никто и не спорил.
Почему тестовый полет не может включать нагрузочные испытания?
Я кстати не понимаю по вашим сообщениям. Вы действительно считаете посадку на воду (а не платформу в воде) заявленной характеристикой?
Мы для своего решения делали: у разных заказчиков стояли разные БД (oracle и postgres), и по требованиям наша система должна была работать с их базой данных. Наша система устанавливалась на их сервера и не имела доступа в интернет.
Но я с вами согласен, что это прям очень редкий кейс. Более крупные on premise решения могут диктовать заказчикам свои условия.
Для Saas это ещё менее актуально. Хотя иметь возможность свалить на что-то более удобное/дешёвое, это всегда приятно. Никто не любит vendor lock
Если вам повезло, что за 3 года у вас не усложнилась модель работы с БД, это не значит, что у других тоже не усложнится.
Из проектов с самописной ОРМ, которые я видел, в такую систему изменения вносились несколько раз в год, и каждый раз через страдания.
Хибернейт такой большой не потому что его писали неумелые разработчики, которым платили за каждую строчку кода. А потому что там покрыто огромное количество edge cas'ов, которые вам, к счастью, не попадались. Ну, либо, вы лукавите и за 3 года вносили не одно изменение, но успешно про это забыли.
Вы так говорите, будто 100500 колонок с фильтрами это сложность. Но как бы тоже нет. Не знаю, что входило в вашу аналитику, может там действительно что-то сложное было. Но динамические колонки и фильтры я делал ещё джуном
Размер продукта это почти всегда сложность, потому что у вас есть очень сложные цепочки решений, интеграции, и взаимосвязи Иначе зачем ему быть большим?
Может быть у нас отличаются понятия круд, для меня это доменный сервис, который просто тупая прослойка над БД. Но в нашем случае сервисы это 80% бизнес логики.
Ну и я вас не понимаю, вы говорите, что орм хороши для хеллоу ворлд проектов, у которых круд. А потом говорите, что оказывается crm и финтех тоже сюда входит.
Какой размер продукта является чем-то более сложным в вашем понимании?
Монолит, написанный в течении 8 лет, одновременно усилиями 5-10 разработчиков это уже достаточно сложный? Помимо десятка сервисов около него
Количество sql запросов можно пересчитать по пальцам и их количество только уменьшается
Производительность заметно страдает только в тех случаях, когда люди руками загружают сложное дерево через n+1 (это не хибер n+1, а люди реально в цикле из каждого сервиса данные грузят)
Я им пользуюсь более 10 лет в качестве основного рабочего дистрибутива
В зависимости от железа либо просто все, что нужно работало, либо приходилось мучаться. Но в целом я более доволен, чем коллеги, которые мучаюсь с каждым новым апгрейдом убунты
Я не писал ни про незаменимых сотрудников ни про грязную работу. Даже для выполнения "грязной" работы нужно знать домен, архитектуру и принятые стандарты. Иначе работа и правда будет грязной.
Мне кажется мы в разных мирах разрабатываем софт
Если кто-то поменяет поля без обратной совместимости, у вас обычные клиенты тоже сломаются. Какая разница, где чинить, в graphql gateway или на клиентах. Тут проблема не в graphql
Доклад может посмотрю. Это он? https://youtu.be/v3m93Xj_BRU?si=5GMaO8k_1Q0YmJeu
А вы про графкл из своего опыта пишете? Исходя из ваших вопросов, кажется, что нет.
Там прямо в стандарте прописано, как работает валидация и как репортятся ошибки. И можно частично загрузить данные при этом (часть графа).
Если у вас есть готовый рест, то графкл очень приятно собирает несколько всех ваших рест ендпоинтов в одну схему. И FE достаточно сделать один запрос, чтобы загрузить связанные данные. Например: фио заказчика, сумму заказа и статус доставки. Которые живут в разных доменах и, возможно, разных сервисах.
Зачастую такие Gateway организуют сами FE разработчики для себя. Чтобы упростить работу со множеством rest endpoint'ов
Я почитал про HARP, (не) спасибо. Другим не советую. Остальным для справки, это от автора самого лучшего фреймворка mol.
Поясните пожалуйста, чем graphql поверх rest (http в данном случае) так плох?
Может я что-то упустил, но тут вроде как речь про призыв покемонов для боёв. Т.е. это больше пет, чем игровой персонаж
Разница с некромантами в том, что ваш основной персонаж сам не сражается, и у вас только битва петов.
Хабр торт, спасибо
Сорри за дубликат
А что, эта проблема как-то специфична для США или английского языка? Или вам без русскоязычных примеров статья не понятна?
Какие учёные собрали статистику, оттуда и пришла новость
Спасибо автору статьи за публикацию, лично для меня она интересна. А вот последующая статья о "российские учёные обнаружили что chatgpt влияет на язык россиян" (или поставьте любую другую нацию) мне будет совершенно не интересна, т.к. в этом не будет ничего нового.
А что, эта проблема как-то специфична для США или английского языка? Или вам без русскоязычных примеров статья не понятна?
Какие учёные собрали статистику, оттуда и пришла новость
Спасибо автору статьи за публикацию, лично для меня она интересна. А вот последующая статья о "российские учёные обнаружили что chatgpt влияет на язык россиян" (или поставьте любую другую нацию) мне будет совершенно не интересна, т.к. в этом не будет ничего нового.
Спейсы чаще всего указывают (или это утекает), что входит в программу следующего тестового полета. ДО этого полёта. Поэтому очень легко понять, что по результатам получилось, а что нет. По крайней мере такие крупные вещи, как посадка на воду, известны заранее.
Когда три предыдущих полёта провалились, то с этим особо никто и не спорил.
Почему тестовый полет не может включать нагрузочные испытания?
Я кстати не понимаю по вашим сообщениям. Вы действительно считаете посадку на воду (а не платформу в воде) заявленной характеристикой?
Ваш аргумент тоже работает в другую сторону))
Мы для своего решения делали: у разных заказчиков стояли разные БД (oracle и postgres), и по требованиям наша система должна была работать с их базой данных. Наша система устанавливалась на их сервера и не имела доступа в интернет.
Но я с вами согласен, что это прям очень редкий кейс. Более крупные on premise решения могут диктовать заказчикам свои условия.
Для Saas это ещё менее актуально. Хотя иметь возможность свалить на что-то более удобное/дешёвое, это всегда приятно. Никто не любит vendor lock
Если вам повезло, что за 3 года у вас не усложнилась модель работы с БД, это не значит, что у других тоже не усложнится.
Из проектов с самописной ОРМ, которые я видел, в такую систему изменения вносились несколько раз в год, и каждый раз через страдания.
Хибернейт такой большой не потому что его писали неумелые разработчики, которым платили за каждую строчку кода. А потому что там покрыто огромное количество edge cas'ов, которые вам, к счастью, не попадались. Ну, либо, вы лукавите и за 3 года вносили не одно изменение, но успешно про это забыли.
Вы так говорите, будто 100500 колонок с фильтрами это сложность. Но как бы тоже нет. Не знаю, что входило в вашу аналитику, может там действительно что-то сложное было. Но динамические колонки и фильтры я делал ещё джуном
Размер продукта это почти всегда сложность, потому что у вас есть очень сложные цепочки решений, интеграции, и взаимосвязи Иначе зачем ему быть большим?
Может быть у нас отличаются понятия круд, для меня это доменный сервис, который просто тупая прослойка над БД. Но в нашем случае сервисы это 80% бизнес логики.
Ну и я вас не понимаю, вы говорите, что орм хороши для хеллоу ворлд проектов, у которых круд. А потом говорите, что оказывается crm и финтех тоже сюда входит.
Какой размер продукта является чем-то более сложным в вашем понимании?
Монолит, написанный в течении 8 лет, одновременно усилиями 5-10 разработчиков это уже достаточно сложный? Помимо десятка сервисов около него
Количество sql запросов можно пересчитать по пальцам и их количество только уменьшается
Производительность заметно страдает только в тех случаях, когда люди руками загружают сложное дерево через n+1 (это не хибер n+1, а люди реально в цикле из каждого сервиса данные грузят)
Я неправильно понял их ответ. Я думал, что это телеграмм борется с мошенниками, блокируя звонки.
Подождите, я не понял. Это не опсосы блокируют, а сам телеграм согласился?
Потому что он весь такой независимый и невзламываемый.
Я им пользуюсь более 10 лет в качестве основного рабочего дистрибутива
В зависимости от железа либо просто все, что нужно работало, либо приходилось мучаться. Но в целом я более доволен, чем коллеги, которые мучаюсь с каждым новым апгрейдом убунты
Идея и браузер не требуют чего то особенного
Надеюсь / сдается мне, что рекламу обязательно будет выделять как-то.
Как, например, в гугл поиске. Наверняка это будет зарегулировано
Какая тогда разница, какая статья?
Я не писал ни про незаменимых сотрудников ни про грязную работу. Даже для выполнения "грязной" работы нужно знать домен, архитектуру и принятые стандарты. Иначе работа и правда будет грязной.
ПС ответ не вам, а продолжение/подтверждение моего расчета выше: https://swyply.com/blog/what-is-the-cost-of-replacing-an-employee
Т.е. с 600% месячной зп я попал в нижнюю оценку согласно этой статье.