В объективной реальности можно использовать файлы как локальный нетребовательный кеш для временных или промежуточных данных, что не помещаются в память.
И, внезапно, при смонтированном nfs или gluster можно получить абсолютно неприятные последствия. Поскольку он вроде бы как и есть, но с таким latency… что лучше бы его не было вообще
Разработчик вскинулся и в порыве возмущения сказал
Это проблемы разработчика, а точнее постановки задачи product owner или project manager. Если с точки зрения бизнесзадачи тут должна быть отрисовка без «задержки», то должна быть именно она.
Если «бизнес» допускает временную остановку отрисовки (а на какой период?), то ок.
Это и сразу выглядит как костыль в рамках GraphQL напрочь убивающее большую часть его пользы.
А уж в рамках одного из комментариев выше
В случае решения а-ля REST (т.к. это уже ни разу не REST, а JSON RPC какой-то) приходится или плодить кучу эндпоинтов на каждый чих, либо снабжать ресурс кучей get-параметров
Сам GraphQL выглядит как банальное «not invented here»
Моя практика показывает, что при наличии хорошей экспертизы в предметной области ваши сущности сразу будут большими. Но только те, кто действительно это требует.
Чаще сущность появляется сразу маленькой у человека уже с опытом в разработке, но без опыта в предметной области.
Но в любом случае проектировать БД посредством ERM диаграмм проще чем писать в консоли что-то невнятное.
А уж потом по готовой схеме генерировать классы Entity.
Консольная команда для этого имеется
Я так подозреваю, с таким подходом вы и без анимированных гифок в рабочем чате не справляетесь никак…
Логично что в тех "крупных" проектах просто не используется json в этом месте
И, внезапно, при смонтированном nfs или gluster можно получить абсолютно неприятные последствия. Поскольку он вроде бы как и есть, но с таким latency… что лучше бы его не было вообще
Откровенно говоря, читая выборочно три прочие ваши статьи я понял, что это просто проблема очень унылой подачи информации.
То есть собственно говоря не описываемой ситуации, а авторского умения (точнее неумения) писать.
Ссылки картинками? 8-О
За что вы нас так не любите?
Это проблемы разработчика, а точнее постановки задачи product owner или project manager. Если с точки зрения бизнесзадачи тут должна быть отрисовка без «задержки», то должна быть именно она.
Если «бизнес» допускает временную остановку отрисовки (а на какой период?), то ок.
На самом деле это очень плохо. Потому что эту "ошибку измерений" исправить крайне сложно
Они изначально собирали данные по диапазонам. И диапазоны ровно такие как на графиках…
М-да… И эти люди ещё что-то тестируют…
Как можно доверять результатам таких тестов?
Да безразличен этнос и литературное описание.
Чисто с точки зрения механики она стоит плохо
А уж в рамках одного из комментариев выше
Сам GraphQL выглядит как банальное «not invented here»
120 EUR/month
40 EUR/month
Вам точно еще нужна Линода?
В этом случае оно взлетает отлично.
Масштабируемость одиночного сервера? Это как?
Моя практика показывает, что при наличии хорошей экспертизы в предметной области ваши сущности сразу будут большими. Но только те, кто действительно это требует.
Чаще сущность появляется сразу маленькой у человека уже с опытом в разработке, но без опыта в предметной области.
Но в любом случае проектировать БД посредством ERM диаграмм проще чем писать в консоли что-то невнятное.
А уж потом по готовой схеме генерировать классы Entity.
Консольная команда для этого имеется
Это ад.
Вы сущность на 2-3 десятка полей так же задаёте?
Так что потрясло авторов?
Коврик? Светильник? Ещё какая-то фигня?
Какие нынче у нас впечатлительные пошли…
Вы не поверите, но достаточно большое количество банков в США вообще не работают с физлицами