Должен ли я сделать свой собственный api стиль graphql, но только с sequelize?

Question

Context

Привет! Я сделал что-то вроде graphql, но только с Sequelize. Я имею в виду, что параметры запроса Sequelize являются объектами JSON, поэтому клиент может отправить параметры напрямую (с правильной обработкой).

Что я сделал

Просто для любопытства я построил это, и оно работает просто отлично. Теперь я сомневаюсь: насколько это плохо?

это пример клиента, использующего этот API

    const res = await http.post(APIs.FINDER, {
      model: 'User',
      options: {
        where: {
          id: someId
        },
        attributes: ['name', 'active']
      },
      include: [
          {
            as: 'zone',
            attributes: ['name']
          }
      ],
      order: [['createdAt', 'DESC']]
    });

хорошо, верно?

Санитарная / Ограничения

О санитарии я должен:

• убедитесь, что у включений есть известный предел, например: не более 10 вложенных включений
• проверить, что параметры не являются строками SQL или другими хаки (Sequelize позаботится об этом)
• не разрешать функции Sequelize, только простые запросы

Вопросы

Имея это в виду, я думаю, что это может быть использовано в производстве.

• Я что-то упустил, что могло бы отвергнуть эту идею из производственного использования? (Безопасность / использование / и т.д.)
• Есть ли в Graphql какая-то особенность, которая заставляет меня предпочитать ее этому пользовательскому решению?
• Будете ли вы использовать его в производственной среде? Я не могу представить, почему нет

Answer 1

Моя мысль к вопросам:

1. Я не рекомендую этот стиль API. Он предоставит общественности доступ к вашей реализации бэкэнда, что затруднит работу с любыми условиями безопасности, не говоря уже о бизнес-логике и авторизации. Кроме того, было бы трудно улучшить вашу производительность, потому что поведение тесно связано с пакетом sequelize.

2. Вы можете рассмотреть этот пост: GraphQL Mutation Design: Анемичные мутации . Хороший API-интерфейс GraphQL должен определяться доменом и требованием, а не данными.

3. НЕТ! Я испытал трудности с этим стилем API.

---

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

На стороне клиента ему нужен только конечный набор apis вместо apis с бесконечными возможностями.

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

Когда речь идет о разработке API, вы можете рассмотреть Domain Driven Design , который известен как DDD. Лучше использовать GET Friends?limit=10 API, чем GET { type: 'User", where: ..., include: ..., order: ..., limit: 10 }

Кстати, GraphQL - это не просто язык запросов, это по сути тонкий слой API ( ref ). Поэтому не используйте его в качестве базы данных JSON, а относитесь к нему как к API, ориентированному на потребности бизнеса.

Например, вот модель пользователя:

{
  "User": {
    "id": 1,
    "name": "Mary",
    "age": 20,
    "friendIds": [2, 3, 4] 
  }
}

Но в GraphQL, исходя из того, что вам нужно, оно может стать:

type User {
  id: ID
  name: String
  friends: [User]
  friendCount: Int
  friendsOverAge18: [User]
}

Вы можете прочитать эту замечательную статью о том, как разработать API GraphQL: Shopify / graphql-design-tutorial