Дмитрий Карловский @nin-jin
Full Stack Overflow
Information
- Rating
- 1,263-rd
- Location
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Date of birth
- Registered
- Activity
Specialization
Chief Technology Officer (CTO), Chief information officer (CIO)
Lead
From 8,000 €
OOP
Database
Designing application architecture
Учимся правильно готовить рест и не говорить глупости.
Вы, видимо, считаете себя очень умным, но это определённо не так, если не видите противоречия между следующими отличительными свойствами GQL:
Рекурсивные выборки
Денормализованная выдача
Только полнейший профан мог такое спроектировать. И только бездумные овощи делают вид, будто этой проблемы нет.
В GQL есть и куча других проблем, но эта просто вопиющая, ибо не допустить её было бы проще простого, не обрекая разработчиков на изобретение костылей.
Секретная джедайская техника: делать монолит, любой модуль которого можно легко задеплоить, как отдельный сервис.
В это и суть реста как бы - ограниченный набор методов для работы с неограниченным набором ресурсов.
Вот пример.
Ну то есть и в этом автор наврал? graphql тоже кривой так-то.
Пруфы в статье:
Необходимость писать роуты для каждого метода.
Прибитость гвоздями к хттп.
https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm Раздел 5.3.2, приятного чтения.
У меня вопрос к руководителю SpaceWeb: Ну поставили вы джуна руководить разработкой, бывает, но зачем позориться-то на весь интернет?
Человек же совершенно не понимает, что такое рест и что он к протоколу, никаким боком не привязан (у нас, например, рест апи единообразно работает поверх http, websocket, sse и даже webrtc); не способен сделать тривиальный фасад к апи, без отдельных роутингов для каждого метода; просто взял первый попавшийся кривой фремворк (fastapi) и сделал поверхностные выводы об архитектурном принципе (rest); даже не рассмотрел ни graphql, ни odata, ни даже harp (про решаемые ими проблемы, очевидно, даже не в курсе, так что ждите в скором времени костылей); высасывает из пальца разницу в необходимости описывать входящие и исходящие типы, которой на самом деле нет (более того, в ресте типов надо описывать меньше, так как число ресурсов кратно меньше числа методов в эквивалентном рпц, а валидация и интроспекция нужна в обоих случаях и в обоих же случаях может быть автоматизирована).
Понимаю, звучит обидно, но вас же дети читают - чему вы их учите? Что достаточно взять 2 самых популярных среди хомячков решения, проигнорировав все остальные достижения человечества, провести поверхностный анализ, наговорить глупостей, выбрать посредственное решение и пустить его в прод?
Похоже зумеры изобрели HTML.. Скоро ещё CSS изобретут, вот тогда заживём.
Следите за руками:
Неужели не хочется писать простой и лаконичный код?
Переписал ваш код на нормальном языке:
Считайте, что Shape - это и есть ваша фабрика.
Как-то я не уловил смысла в этой
VariantFactory
. Для разных типов нужны разные наборы по разному подготавливаемых аргументов. Тот, кто их предоставляет, может сразу и создавать вариант соответствующего им типа. Единственное применение, которое я вижу для подобной фабрики, - это обобщённая (де)сериализация. Но ваше решение для этого не применимо.О том и речь..
С поиском-то всё понятно, а как быть с добавлением данных? Повсеместно используемый в СУБД B-tree использует букеты, выстраивая их в самобалансирующееся дерево, что неизбежно приводит к логарифмическому поиску. Причём далеко не бинарному, то есть степень логарифма не 2, а исчисляется десятками, а то и сотнями. Предложенный же тут алгоритм работает лишь на плоских списках. А если его применять к не плоским, то вновь выползет логарифм на доступ к каждому элементу. Для равномерно распределённых данных таким образом лучше подходит какой-нибудь trie, который по префиксу очень быстро скачет по букетам, и поиск в котором для фиксированной длины ключа даёт константную сложность.
Не мучайтесь с JSON. Используйте более подходящие форматы.
Ну вот если сделаете PWA, то у вас даже и FCP уменьшится. А так, смотрели бы лучше на TBT, а то он у вас зашкаливает.
Очевидно, в разных контекстах я говорил про разных разработчиков. Но какое это всё имеет отношение к качествам самого фреймворка - ума не приложу. У вас своя голова на плечах есть?
Я тут рассказывал, почему у нас получаются такие маленькие бандлы.
Заходим в ростер, проваливаемся в диалог, возвращаемся назад - фриз на 2 секунды (а на low-end mobile всё ещё в 2-3 раза хуже). Я ведь только что там был - все необходимые данные уже загружены, нужно лишь показать тривиальный список контактов.
Если уж говорить про метрики загрузки страницы, то там тоже полный швах даже без очистки хранилища:
А какая разница? Ну будет несколько диалогов с разными людьми.
Куда выгоднее тут доложить боссу о таком выгодном предложении от начальника и занять его место.