При работе через builder, виджеты создаются по мере необходимости при скролле. Если логика создания виджета тяжёлая, то будет протормаживать. Надо посмотреть профайлером, что там происходит.
Когда я писал на флаттер, скроллинг работал нормально. Ну и я только что скачал приложение Медузы, на не очень быстром телефоне тоже со скроллингом всё ок. Может быть какие-то специфические задачи?
Ну он же не только как подвозящий, он развозит людей по нескольким направлениям где метро нет. И эта функция останется после завершения строительства станции
Они не дублируют. Метро должно связать Автовокзал с ЖД Вокзалом одной веткой, трамваи до туда не ходят. Так что трамваи там как временное решение, ну и для доставки по ближайшим территориям
В 2005-ом мы её делали такую штуку на MySQL, а в 2006-ом переписали на постгрес, потому что MySQL на какой-то глубине запросов переставал оптимизировать джойны и начинал тупо их перемножать, что на миллионах записей не выдерживали никакие таймауты.
Но только для постгреса и с ограничениями. Да, костылей много, но смысл от этого не меняется — в graphql изначально не продумали эффективность запросов и теперь эти дыры приходится затыкать.
Проблема не в БД — так-то многие базы совмещают разные типы данных, тот же постгрес отлично работает и с графами, и с json и с парами ключ-значение. Проблема именно в прослойке, в данном случае GraphQL
Если писать полностью свою реализацию, то всё просто. Но тогда не получится нормально съэкономить. А вот с готовыми решениями — проблема в том, что они по умолчанию каждую сущность дёргают отдельно.
Dataloader умеет батчинг только если каждый случай явно реализовывать. А без произвольных запросов, смысл GraphQL сильно теряется. Произвольные запросы умеет строить Join Monster, но там есть свои ограничения.
А про графовую структуру на JOIN-ах:
Во-первых, вполне можно. Мы ещё в 2006-ом делали графовую БД на постгресе с использованием рекурсивных запросов.
Во-вторых, GraphQL, не взирая на своё название, всё-таки далеко не только про графы.
Да, NoSQL не отменяет джойнов, в конце концов он же «Not only» и позволяет получить данные одним запросом. Вопрос в том, насколько это позволяют сделать реализации GraphQL. Тот же сервер Apollo по умолчанию делает отдельные запросы к провайдеру данных для каждого случая.
Одна из самых больших проблем GraphQL — что он изначально не рассчитан на то, чтобы на сервере работать единым запросом. Это удобно, когда нужно собрать данные из разных источников, но когда нужно получить данные из реляционной БД — начинаются костыли. Есть отдельные библиотеки для того, чтобы собирать SQL-запросы с JOIN на сервере, но они работают через боль. Плюс отсутствие версионирования API из коробки и многие другие ограничения.
Самое смешное, что есть отличный стандарт oData, в котором это реализуется очень удобно.
Я тоже закончил этот поток на продакта. Удалось получить обратную связь по кейсам и это было реально полезно. Я старался выбирать кейс, по которому есть перспективные контакты, и угадал.
Про отсутствие обратной связи от самих организаторов — да, жирный минус, но сам материал понравился.
ИМХО, это вопрос архитектуры кода, в первую очередь. Разработчики, с которыми я сейчас работаю, активно используют Feature Flag и вне проверки гипотез. Когда в этом месте нет проблем, дальше уже должно быть легко.
Когда приложение запрашивает доступ к сети, если раньше не требовалось, то это может быть оно. А остальное — нет.
Сейчас магазины приложений не позволяют приложениям собирать больше персональной информации, чем они могут разумно обосновать — из-за законов типа GDPR. Просто начать собирать дополнительные данные для аналитики приложение не может.
Беру свои слова назад. Возможность управления приложением с клавиатуры, оказывается — часть рекомендаций Google по accessibility, а значит должна быть реализована в обозримом будущем.
И для разных размеров экранов тоже. Корневой виджет — приложение. Дальше мы хотим, например, для планшетов слева всегда показывать меню, а для смартфонов делать его условно отдельным экраном. Мы в отображении приложения проверяем ширину экрана и, в зависимости от неё, строим разные деревья виджетов.
А можно поподробнее? В Новосибирске нет ни скоростного трамвая, ни планируемых веток метро
Dataloader умеет батчинг только если каждый случай явно реализовывать. А без произвольных запросов, смысл GraphQL сильно теряется. Произвольные запросы умеет строить Join Monster, но там есть свои ограничения.
А про графовую структуру на JOIN-ах:
Во-первых, вполне можно. Мы ещё в 2006-ом делали графовую БД на постгресе с использованием рекурсивных запросов.
Во-вторых, GraphQL, не взирая на своё название, всё-таки далеко не только про графы.
Самое смешное, что есть отличный стандарт oData, в котором это реализуется очень удобно.
Про отсутствие обратной связи от самих организаторов — да, жирный минус, но сам материал понравился.
Сейчас магазины приложений не позволяют приложениям собирать больше персональной информации, чем они могут разумно обосновать — из-за законов типа GDPR. Просто начать собирать дополнительные данные для аналитики приложение не может.