суть одна

Гайс а кто-то ручками пробовал сравнить призму и typeOrm?

В разрезе использования с TS :)

бери typeorm

А очень коротко в чем преимущество?

контроль, все плюшки призмы когда доходит до дела встают под большой вопрос

Спасиб

+
Как тонко подметил 👍

пару недель пробую тайпорм вместо призмы - прямо каеф

честно говоря мапить апи на базу вообще так себе идея, на чем то простом это еще работает, на чем то хоть немного сложном даже в простейший круд пробирается много бизнес логики  ... словом что призма что хасура  - врядли возьму в будущем для сложного проекта

Всё так. Графкуэль должен быть максимально простым и должен поменьше хранить бизнес логики в резолверах. Он в MVC как контроллер: взять аргументы, чекнуть их и вызвать методы с бизнес логикой из моделей.

Короче Графкуэль должен быть тупой проксей к вашей бизнес логике.

А когда все напихают в граф, потом мучаются с тестами, джобами, кронами, другими протоколами (grpc).

7:32-7:43 Ник говорит:
 Instead of like mapping what we have this kind of like object graph and like contorting it to be relational system. What if we just make it an object graph all the way from back to front.

Контекст к его словам из треда в твиттере:
 https://twitter.com/schrockn/status/1163568700256968704

 У нас была хорошая внутренняя объектная модель, которая была представлена в памяти в виде графа. Она называлась Ent.

 Первоначальный подход к API для мобильных устройств заключался в использовании нашей платформы API FQL (Facebook Query Language). Это был SQL-подобный DSL поверх API Facebook.

 Проблема, как я понял, заключается в том, что мы переходили от графа объектов к реляционному API и обратно к графу объектов в памяти на мобильных клиентах.

 Вместо этого, почему бы просто не поддерживать структуру графов объектов на клиенте и сервере без промежуточного искажения / перевода в реляционный. Это было избыточное объектное реляционное отображение, в котором мы не нуждались.

 Отсюда мое утверждение: «Почему бы нам просто не сделать это графом объектов изначально»

7:32-7:43 Ник говорит:
 Instead of like mapping what we have this kind of like object graph and like contorting it to be relational system. What if we just make it an object graph all the way from back to front.

Итоговый перевод:
 Наши данные на серверах хранились в виде объектного графа. Через старое Эй-пи-ай мы получали их в разрозненном виде и обратно склеивали в памяти мобильных устройств. Так что если мы избавимся от промежуточного маппинга данных и сразу будем получать их в удобном виде?

Вот как зарождался GraphQL в Фейсбуке и какие он там задачи должен бвл решить.

все верно, но возникает другая проблема - N + 1  (для квери, ну для мутаций это не варик, так как они последовательно исполняются)  - и вот это решается  лоадерами, которые придется прокидывать в сервисы и репозитории, что конечно не есть хорошо (хотелось бы чтобы просто тупо написать логику и не думать о перфе и N + 1 на чтение и не пробрасывал ничего лишнего в свои сервисы от графкуэля)

как вариант - можно монад накрутить, либо обертку для ормки писать, чтобы не заниматься этой фигней и выполнить в одну транзакцию большой квери со всех сервисов

так что нормальный графкуель "прокси" запилить - это уметь надо

тоже правда, я иделаьного решения я еще не нашел, но я по большому счету и не бекенд разработчик - так пилю его в форсмажорных ситуациях. Для меня главный плюс graphql это типобезопасность и скорость написания фонта. Если автогенерация призмы   то в чистом виде скорости написания фронта нету, на фронте начинают расти огромные запросы для реализации бизнес логикию Словом все как обычно - серебряной пули нам до пенсии не видать )

Про призму уже про вопрос об описании/реализации бизнес домена в виде схемы и самих данных, руками когда пишешь - ясное дело не выдумываешь кейсы на все случаи жизни, обычно итерациями фигачишь и все ок

А так, к фронту вообще никаких претензий)

Нет не нужно. Лоадеры это обычно прокся над методом findMany или findById.

так понятно, но ты же их как-то пробрасываешь в сервис - лоадеры? ( я говорю за то, что твои сервисы и репозитории раздуваются из-за того что ты прокидываешь в них лоадеры, которые создаются на каждый запрос)

или может ты по хитрому инжектишь их