Pull to refresh

Comments 11

Сначала даём возможность фронту (и всем-всем-всем) нагружать бэк слабо контролируемыми запросами, потом мужественно пытаемся решить эту проблему.
Экономия на написании нормальных API эндпоинтов с предсказуемой логикой выливается в издержки по дальнейшему окостыливанию наколеночного GraphQL поделия.

P.S. требования 'гибкости' продукта обычно произрастают из хренового планирования, как бизнес- так и технологической части. Конечно, зачем тратиться на аналитиков и прорабатывать модели и архитектуру, когда можно захреначить в продакшен вот уже завтра (конкуренты же так и ходят стаями!), «а там посмотрим».
Не думаю, что FB настолько глупы, чтобы не помнить об этой проблемеи не предусмотреть это в рамках реализации GQL, другой вопрос если используют его наобум, не зная технологии и специфики

Там можно вес запроса ограничить. Причем вес анализируется статически, хоть на клиенте можно делать.

Интересно, я один как идиот тыкал на «play» на этой картинке, чтобы воспроизвести видео?

image

У вас на картинке Play не работает :)

UFO just landed and posted this here

Статья понравилась, хороший обзор. Лишний раз убедился в правильности выбора между двух "зол". Правда я выбрал зло от гугл, https://grpc.io/. Рекомендую приглядеться.

Только вот gRPC это RPC. А GraphQL — совсем нет. Все равно, что выбирать между теплым и красным.

кстати в коде загрузчика данных есть один момент, притом важный, о котором кстати не сказано ни слова, это
for i, id := range ids {
    users[i] = userById[id]
    i++
}

отдать список юзеров нужно в строго том же порядке что и получили список id, так же если для id нет данных в бд, нужно обязательно вернуть nil, иначе сломается ответ, об этом написано в оригинальной библиотеке от facebook портом на го которой является dataloaden

Здесь выполняются лишь два запроса к базе данных, в результате все теперь счастливы

А если нужно JOIN, а не 2 последовательных запроса, то как этого добиться?

Sign up to leave a comment.