Почему Prisma?
В чем же заключается сложность построения серверов GraphQL?

Что ж, в реальных приложениях вы, вероятно, столкнетесь со многими сценариями, где реализация преобразователей может стать чрезвычайно сложной. Тем более, что запросы GraphQL могут быть сложены в несколько уровней, реализация часто становится сложной и может легко привести к проблемам с производительностью.

В большинстве случаев вам также необходимо позаботиться о многих дополнительных рабочих процессах, таких как аутентификация, авторизация (разрешения), разбиение на страницы, фильтрация, в реальном времени, интеграция с сторонними службами или устаревшими системами ...

Как правило, при реализации преобразователей и подключении к базе данных у вас есть два варианта - оба из которых не очень убедительны:

1. Доступ к базе данных напрямую (путем написания SQL или с использованием другого API баз данных NoSQL);
2. Использовать ORM, который обеспечивает абстракцию для вашей базы данных и позволяет получить доступ к ней непосредственно с вашего языка программирования.

Первый вариант проблематичен, поскольку работа с SQL в resolvers сложна и быстро выходит из-под контроля. Другая проблема заключается в том, что SQL-запросы обычно передаются в базу данных как простые строки. Строки не придерживаются какой-либо структуры, это просто сырые последовательности символов. Поэтому ваш инструмент не сможет помочь вам найти какие-либо проблемы с ними или предоставить дополнительные преимущества, такие как автозаполнение в редакторах. Написание SQL-запросов, таким образом, утомительно и подвержено ошибкам.

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

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

Примечание. Связывание Prisma основано на идее сшивания схем и делегирования схемы. Мы не собираемся подробно описывать эти методы в этом уроке. Если вы хотите узнать больше о них, вы можете проверить следующие две статьи:
- Схема схемы GraphQL объясняется: Делегирование схемы https://blog.graph.cool/graphql-schema-stitching-explained-schema-delegation-4c6caf468405
- Повторное использование и компоновка API-интерфейсов GraphQL с привязками GraphQL https://blog.graph.cool/reusing-composing-graphql-apis-with-graphql-bindings-80a4aa37cff5
Что важно для понимания этой архитектуры, что вы имеете дело с двумя (!) Уровнями API GraphQL. Уровень приложения и уровень базы данных.

Уровень приложения (The application layer)
Первый API GraphQL - это тот, который вы уже начали создавать в предыдущих разделах этого руководства. Это API-интерфейс GraphQL для прикладного уровня. Он определяет API, с которым будут разговаривать ваши клиентские приложения. Здесь вы реализуете бизнес-логику, обычные рабочие процессы, такие как аутентификация и авторизация, или интегрируетесь со сторонними службами (такими как Stripe, если вы хотите реализовать процесс оплаты). API прикладного уровня определяется схемой GraphQL в src / schema.graphql - поэтому мы теперь будем ссылаться на эту схему как схему приложения.

Уровень базы данных (The database layer)
Второй API GraphQL - это тот, который предоставляется Prisma и обеспечивает уровень базы данных. В основном это интерфейс на основе GraphQL для вашей базы данных, который избавляет вас от тонкостей написания SQL. Итак, как выглядит этот API-интерфейс GraphQL?

API Prisma зеркалирует API базы данных, поэтому он позволяет выполнять операции CRUD для определенных типов данных. Какие типы данных? Ну, это зависит от вас - вы определяете эти типы данных, используя знакомый SDL— Schema Definition Language.

Как правило, эти типы данных представляют собой объекты вашего домена приложения. Например, если вы строите программное обеспечение для автомобилей, у вас, скорее всего, будут такие типы данных, как Car, CarDealer, Customer и т. Д. Вся коллекция этих типов данных называется вашей моделью данных.

После того, как ваша модель данных определена в SDL, Prisma переводит ее в схему базы данных и соответствующим образом настраивает базовую базу данных. Когда вы отправляете запросы и мутации в API Prisma GraphQL, он переводит их в операции с базой данных и выполняет эти операции для вас. Неплохо, да?

Ранее вы узнали, что все API-интерфейсы GraphQL поддерживаются схемой GraphQL. Итак, кто пишет схему для API Prisma GraphQL? Ответ заключается в том, что он автоматически создается на основе модели данных, которую вы предоставляете. Кстати, эта схема называется  Prisma database schema.  Перевод из курса: https://www.udemy.com/learning-graphql-with-prisma-and-nodejs/

@uxname Думаю стоит попробывать основные решения и выбрать, после сопоставительного анализа и под конкретную задачу.

К двум описанным “неубедительным” вариантам подключения к базе данных есть вопросы.

1. В базу данных SQL в любом случае уходят запросы select, update, set, remove. В какой последовательности обрабатываются условия where, order, having, union, join, context table expression это решать для SQL. Например, PostgreSQL, сам определяет как выполнить запрос, в зависимости от индексов, структуры и т.д. Если написание sql вызывает фрустрацию, имеет смысл использовать query builder, такой как knexjs (JavaScript). Здесь также присутствует инструмент автозаполнение. И это не чистые строки, которые могут водвергнуться sql injection.

2. Призма все еще остается ORM и сравнение идет с другими ORM со всеми плюсами и минусами. Почему бы не поговорить о минусах первого? Минусы занимают бОльшое количество времени в работе. Как обычно любой уровень абстракции, в том числе ORM, это путь изучения. Рост профессиональных навыков и фич, которые можно реализовать в умеренное время, будет прямо пропорционален возможностям ORM, т.е. чего не умеет ORM или нестандартно для него, потребует резкого выхода из зоны комфорта, как следствие времени для реализации бизнес требования. Например, этот типичный и в тоже время необычный по своему запрос.

select SUM(case when seen_at is null then 1 else 0 end) from "app"."events"
  left join app.events_users
  on events_users.id = (
    select id from app.events_users
    where user_id = "5a674f1c-ct5e-11e8-9kb2-03d840d1e489" and event_id = events.id
    limit 1
  )
 where ((
    array[1]::integer[] <@ cities
    or ARRAY(select country_id from app._cities where city_id = 1) <@ countries
  )
  and approved = true and archived_at is null
  and coalesce(start_time, CURRENT_TIMESTAMP) <= CURRENT_TIMESTAMP
  and CURRENT_TIMESTAMP <= coalesce(end_time, CURRENT_TIMESTAMP)
) limit 1

select SUM(case when seen_at is null then 1 else 0 end) from "app"."events"
  left join app.events_users
  on events_users.id = (
    select id from app.events_users
    where user_id = "5a674f1c-ct5e-11e8-9kb2-03d840d1e489" and event_id = events.id
    limit 1
  )
 where ((
    array[1]::integer[] <@ cities
    or ARRAY(select country_id from app._cities where city_id = 1) <@ countries
  )
  and approved = true and archived_at is null
  and coalesce(start_time, CURRENT_TIMESTAMP) <= CURRENT_TIMESTAMP
  and CURRENT_TIMESTAMP <= coalesce(end_time, CURRENT_TIMESTAMP)
) limit 1

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

Мне кажется её стоит использовать как вторую, вспомогательную orm, тогда будет и удобно и где надо быстро

а не оверхед поднимать всю эту махину для вспомогательной орм?

Ну, в каком смысле оверхед? По нагрузке на железо?

По комплексити системы

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

Не только понять но и поддерживать включая инстанс

У меня сейчас задача сделать e-commerce платформу, там кууча сущностей, и писать простые круды очень лень, особенно учитывая что нужно выкатить MVP за месяц+-, и вот в таком случае призма мне показалась очень неплохим решением, особенно потому что API будет на GraphQL. Поддерживать да, сложнее.

А потом потихоньку, после релиза можем начать переписывать все на node-postgres какой-нибудь

Куча либ генерит круд из схемы базы

Всё ещё не пойму зачем призма

Какие? Я искал, не нашел как-то

Какая база?

Pg

Постграфиль

Он api круд генерит или код?