GraphQL на Rust / forpes.ru

Главная
GraphQL на Rust

GraphQL на Rust +20

09.03.2021 14:23

not_bad 27 3500 Источник

В этой статье я покажу как создать GraphQL сервер, используя Rust и его экосистему; будут приведены примеры реализации наиболее часто встречающихся задач при разработке GraphQL API. В итоге API трёх микросервисов будут объединены в единую точку доступа с помощью Apollo Server и Apollo Federation. Это позволит клиентам запрашивать данные одновременно из нескольких источников без необходимости знать какие данные приходят из какого сервиса.

Введение

Обзор

С точки зрения функциональности описываемый проект довольно похож на представленный в моей предыдущей статье, но в этот раз с использованием стэка Rust. Архитектурно проект выглядит так:

Каждый компонент архитектуры освещает несколько вопросов, которые могут возникнуть при реализации GraphQL API. Доменная модель включает данные о планетах Солнечной системы и их спутниках. Проект имеет многомодульную структуру (или монорепозиторий) и состоит из следующих модулей:

Существуют две основных библиотеки для разработки GraphQL сервера на Rust: Juniper и Async-graphql, но только последняя поддерживает Apollo Federation, поэтому она была выбрана для реализации проекта (есть также открытый запрос на реализацию поддержки Federation в Juniper). Обе библиотеки предлагают code-first подход.

Помимо этого использованы PostgreSQL — для реализации слоя данных, JWT — для аутентификации и Kafka — для асинхронного обмена сообщениями.

Стэк технологий

В следующей таблице показан стэк основных технологий, использованных в проекте:

Тип	Название	Сайт	GitHub
Язык программирования	Rust	link	link
GraphQL библиотека	Async-graphql	link	link
Единая GraphQL точка доступа	Apollo Server	link	link
Web фреймворк	actix-web	link	link
База даных	PostgreSQL	link	link
Брокер сообщений	Apache Kafka	link	link
Оркестрация контейнеров	Docker Compose	link	link

Также некоторые использованные Rust библиотеки:

Тип	Название	Сайт	GitHub
ORM	Diesel	link	link
Kafka клиент	rust-rdkafka	link	link
Хэширование паролей	argonautica	link	link
JWT библиотека	jsonwebtoken	link	link
Библиотека для тестирования	Testcontainers-rs	link	link

Необходимое ПО

Чтобы запустить проект локально, вам нужен только Docker Compose. В противном случае вам может понадобиться следующее:

Rust
Diesel CLI (для установки выполните cargo install diesel_cli --no-default-features --features postgres)
LLVM (это нужно для работы крэйта argonautica)
CMake (это нужно для работы крэйта rust-rdkafka)
PostgreSQL
Apache Kafka
npm

Реализация

В Cargo.toml в корне проекта указаны три приложения и одна библиотека:

Root Cargo.toml

[workspace]
members = [
    "auth-service",
    "planets-service",
    "satellites-service",
    "common-utils",
]

Начнём с planets-service.

Зависимости

Cargo.toml выглядит так:

Cargo.toml

[package]
name = "planets-service"
version = "0.1.0"
edition = "2018"

[dependencies]
common-utils = { path = "../common-utils" }
async-graphql = "2.4.3"
async-graphql-actix-web = "2.4.3"
actix-web = "3.3.2"
actix-rt = "1.1.1"
actix-web-actors = "3.0.0"
futures = "0.3.8"
async-trait = "0.1.42"
bigdecimal = { version = "0.1.2", features = ["serde"] }
serde = { version = "1.0.118", features = ["derive"] }
serde_json = "1.0.60"
diesel = { version = "1.4.5", features = ["postgres", "r2d2", "numeric"] }
diesel_migrations = "1.4.0"
dotenv = "0.15.0"
strum = "0.20.0"
strum_macros = "0.20.1"
rdkafka = { version = "0.24.0", features = ["cmake-build"] }
async-stream = "0.3.0"
lazy_static = "1.4.0"

[dev-dependencies]
jsonpath_lib = "0.2.6"
testcontainers = "0.9.1"

async-graphql — это GraphQL библиотека, actix-web — web фреймворк, а async-graphql-actix-web обеспечивает интеграцию между ними.

Ключевые функции

Начнём с main.rs:

main.rs

#[actix_rt::main]
async fn main() -> std::io::Result<()> {
    dotenv().ok();
    let pool = create_connection_pool();
    run_migrations(&pool);

    let schema = create_schema_with_context(pool);

    HttpServer::new(move || App::new()
        .configure(configure_service)
        .data(schema.clone())
    )
        .bind("0.0.0.0:8001")?
        .run()
        .await
}

Здесь окружение и HTTP сервер конфигурируются с помощью функций, определённых в lib.rs:

lib.rs

pub fn configure_service(cfg: &mut web::ServiceConfig) {
    cfg
        .service(web::resource("/")
            .route(web::post().to(index))
            .route(web::get().guard(guard::Header("upgrade", "websocket")).to(index_ws))
            .route(web::get().to(index_playground))
        );
}

async fn index(schema: web::Data<AppSchema>, http_req: HttpRequest, req: Request) -> Response {
    let mut query = req.into_inner();

    let maybe_role = common_utils::get_role(http_req);
    if let Some(role) = maybe_role {
        query = query.data(role);
    }

    schema.execute(query).await.into()
}

async fn index_ws(schema: web::Data<AppSchema>, req: HttpRequest, payload: web::Payload) -> Result<HttpResponse> {
    WSSubscription::start(Schema::clone(&*schema), &req, payload)
}

async fn index_playground() -> HttpResponse {
    HttpResponse::Ok()
        .content_type("text/html; charset=utf-8")
        .body(playground_source(GraphQLPlaygroundConfig::new("/").subscription_endpoint("/")))
}

pub fn create_schema_with_context(pool: PgPool) -> Schema<Query, Mutation, Subscription> {
    let arc_pool = Arc::new(pool);
    let cloned_pool = Arc::clone(&arc_pool);
    let details_batch_loader = Loader::new(DetailsBatchLoader {
        pool: cloned_pool
    }).with_max_batch_size(10);

    let kafka_consumer_counter = Mutex::new(0);

    Schema::build(Query, Mutation, Subscription)
        .data(arc_pool)
        .data(details_batch_loader)
        .data(kafka::create_producer())
        .data(kafka_consumer_counter)
        .finish()
}

Эти функции делают следующее:

index — обрабатывает GraphQL запросы (query) и мутации
index_ws — обрабатывает GraphQL подписки
index_playground — предоставляет Playground GraphQL IDE
create_schema_with_context — создаёт GraphQL схему с глобальным контекстом доступным в рантайме, например, пул соединений с БД

Определение GraphQL запроса и типа

Рассмотрим как определить запрос:

Определение запроса

#[Object]
impl Query {
    async fn get_planets(&self, ctx: &Context<'_>) -> Vec<Planet> {
        repository::get_all(&get_conn_from_ctx(ctx)).expect("Can't get planets")
            .iter()
            .map(|p| { Planet::from(p) })
            .collect()
    }

    async fn get_planet(&self, ctx: &Context<'_>, id: ID) -> Option<Planet> {
        find_planet_by_id_internal(ctx, id)
    }

    #[graphql(entity)]
    async fn find_planet_by_id(&self, ctx: &Context<'_>, id: ID) -> Option<Planet> {
        find_planet_by_id_internal(ctx, id)
    }
}

fn find_planet_by_id_internal(ctx: &Context<'_>, id: ID) -> Option<Planet> {
    let id = id.to_string().parse::<i32>().expect("Can't get id from String");
    repository::get(id, &get_conn_from_ctx(ctx)).ok()
        .map(|p| { Planet::from(&p) })
}

Эти запросы получают данные из БД используя слой репозитория. Полученные сущности конвертируются в GraphQL DTO (это позволяет соблюсти принцип единственной ответственности для каждой структуры). Запросы get_planets и get_planet могут быть выполнены из любой GraphQL IDE например так:

Пример использования запроса

{
  getPlanets {
    name
    type
  }
}

Структура Planet определена так:

Определение GraphQL типа

#[derive(Serialize, Deserialize)]
struct Planet {
    id: ID,
    name: String,
    planet_type: PlanetType,
}

#[Object]
impl Planet {
    async fn id(&self) -> &ID {
        &self.id
    }

    async fn name(&self) -> &String {
        &self.name
    }

    /// From an astronomical point of view
    #[graphql(name = "type")]
    async fn planet_type(&self) -> &PlanetType {
        &self.planet_type
    }

    #[graphql(deprecation = "Now it is not in doubt. Do not use this field")]
    async fn is_rotating_around_sun(&self) -> bool {
        true
    }

    async fn details(&self, ctx: &Context<'_>) -> Details {
        let loader = ctx.data::<Loader<i32, Details, DetailsBatchLoader>>().expect("Can't get loader");
        let planet_id = self.id.to_string().parse::<i32>().expect("Can't convert id");
        loader.load(planet_id).await
    }
}

В impl определяется резолвер для каждого поля. Также для некоторых полей определены описание (в виде Rust комментария) и deprecation reason. Это будет отображено в GraphQL IDE.

Проблема N+1

В случае наивной реализации функции Planet.details выше возникла бы проблема N+1, то есть, при выполнении такого запроса:

Пример возможного ресурсоёмкого GraphQL запроса

{
  getPlanets {
    name
    details {
      meanRadius
    }
  }
}

для поля details каждой из планет был бы сделан отдельный SQL запрос, т. к. Details — отдельная от Planet сущность и хранится в собственной таблице.

Но с помощью DataLoader, реализованного в Async-graphql, резолвер details может быть определён так:

Определение резолвера

async fn details(&self, ctx: &Context<'_>) -> Result<Details> {
    let data_loader = ctx.data::<DataLoader<DetailsLoader>>().expect("Can't get data loader");
    let planet_id = self.id.to_string().parse::<i32>().expect("Can't convert id");
    let details = data_loader.load_one(planet_id).await?;
    details.ok_or_else(|| "Not found".into())
}

data_loader — это объект в контектсе приложения, определённый так:

Определение DataLoader'а

let details_data_loader = DataLoader::new(DetailsLoader {
    pool: cloned_pool
}).max_batch_size(10);

DetailsLoader реализован следующим образом:

DetailsLoader definition

pub struct DetailsLoader {
    pub pool: Arc<PgPool>
}

#[async_trait::async_trait]
impl Loader<i32> for DetailsLoader {
    type Value = Details;
    type Error = Error;

    async fn load(&self, keys: &[i32]) -> Result<HashMap<i32, Self::Value>, Self::Error> {
        let conn = self.pool.get().expect("Can't get DB connection");
        let details = repository::get_details(keys, &conn).expect("Can't get planets' details");

        Ok(details.iter()
            .map(|details_entity| (details_entity.planet_id, Details::from(details_entity)))
            .collect::<HashMap<_, _>>())
    }
}

Такой подход позволяет предотвратить проблему N+1, т. к. каждый вызов DetailsLoader.load выполняет только один SQL запрос, возвращающий пачку DetailsEntity.

Определение интерфейса

GraphQL интерфейс и его реализации могут быть определены следующим образом:

Определение GraphQL интерфейса

#[derive(Interface, Clone)]
#[graphql(
    field(name = "mean_radius", type = "&CustomBigDecimal"),
    field(name = "mass", type = "&CustomBigInt"),
)]
pub enum Details {
    InhabitedPlanetDetails(InhabitedPlanetDetails),
    UninhabitedPlanetDetails(UninhabitedPlanetDetails),
}

#[derive(SimpleObject, Clone)]
pub struct InhabitedPlanetDetails {
    mean_radius: CustomBigDecimal,
    mass: CustomBigInt,
    /// In billions
    population: CustomBigDecimal,
}

#[derive(SimpleObject, Clone)]
pub struct UninhabitedPlanetDetails {
    mean_radius: CustomBigDecimal,
    mass: CustomBigInt,
}

Здесь вы также можете видеть, что если в структуре нет ни одного поля со "сложным" резолвером, то она может быть реализована с использованием атрибута SimpleObject.

Определение кастомного скалярного типа

Кастомные скаляры позволяют определить как представлять и как парсить значения определённого типа. Проект содержит два примера определения кастомных скаляров; оба являются обёртками для числовых структур (т. к. невозможно определить внешний трейт на внешней структуре из-за orphan rule). Эти обёртки определены так:

Кастомный скаляр: обёртка для BigInt

#[derive(Clone)]
pub struct CustomBigInt(BigDecimal);

#[Scalar(name = "BigInt")]
impl ScalarType for CustomBigInt {
    fn parse(value: Value) -> InputValueResult<Self> {
        match value {
            Value::String(s) => {
                let parsed_value = BigDecimal::from_str(&s)?;
                Ok(CustomBigInt(parsed_value))
            }
            _ => Err(InputValueError::expected_type(value)),
        }
    }

    fn to_value(&self) -> Value {
        Value::String(format!("{:e}", &self))
    }
}

impl LowerExp for CustomBigInt {
    fn fmt(&self, f: &mut Formatter<'_>) -> fmt::Result {
        let val = &self.0.to_f64().expect("Can't convert BigDecimal");
        LowerExp::fmt(val, f)
    }
}

Кастомный скаляр: обёртка для BigDecimal

#[derive(Clone)]
pub struct CustomBigDecimal(BigDecimal);

#[Scalar(name = "BigDecimal")]
impl ScalarType for CustomBigDecimal {
    fn parse(value: Value) -> InputValueResult<Self> {
        match value {
            Value::String(s) => {
                let parsed_value = BigDecimal::from_str(&s)?;
                Ok(CustomBigDecimal(parsed_value))
            }
            _ => Err(InputValueError::expected_type(value)),
        }
    }

    fn to_value(&self) -> Value {
        Value::String(self.0.to_string())
    }
}

В первом примере также показано, как представить гигантское число в виде экспоненциальной записи.

Определение мутации

Мутация может быть определена следующим образом:

Определение мутации

pub struct Mutation;

#[Object]
impl Mutation {
    #[graphql(guard(RoleGuard(role = "Role::Admin")))]
    async fn create_planet(&self, ctx: &Context<'_>, planet: PlanetInput) -> Result<Planet, Error> {
        let new_planet = NewPlanetEntity {
            name: planet.name,
            planet_type: planet.planet_type.to_string(),
        };

        let details = planet.details;
        let new_planet_details = NewDetailsEntity {
            mean_radius: details.mean_radius.0,
            mass: BigDecimal::from_str(&details.mass.0.to_string()).expect("Can't get BigDecimal from string"),
            population: details.population.map(|wrapper| { wrapper.0 }),
            planet_id: 0,
        };

        let created_planet_entity = repository::create(new_planet, new_planet_details, &get_conn_from_ctx(ctx))?;

        let producer = ctx.data::<FutureProducer>().expect("Can't get Kafka producer");
        let message = serde_json::to_string(&Planet::from(&created_planet_entity)).expect("Can't serialize a planet");
        kafka::send_message(producer, message).await;

        Ok(Planet::from(&created_planet_entity))
    }
}

Чтобы использовать объект как входной параметр мутации, надо определить структуру следующим образом:

Определение input type

#[derive(InputObject)]
struct PlanetInput {
    name: String,
    #[graphql(name = "type")]
    planet_type: PlanetType,
    details: DetailsInput,
}

Мутация защищена RoleGuard'ом, который гарантирует что только пользователи с ролью Admin могут выполнить её. Таким образом, для выполнения, например, следующей мутации:

Пример использования мутации

mutation {
  createPlanet(
    planet: {
      name: "test_planet"
      type: TERRESTRIAL_PLANET
      details: { meanRadius: "10.5", mass: "8.8e24", population: "0.5" }
    }
  ) {
    id
  }
}

вам нужно указать заголовок Authorization с JWT, полученным из auth-service (это будет описано далее).

Определение подписки

В определении мутации выше вы могли видеть что при добавлении новой планеты отправляется сообщение:

Отправка сообщения в Kafka

let producer = ctx.data::<FutureProducer>().expect("Can't get Kafka producer");
let message = serde_json::to_string(&Planet::from(&created_planet_entity)).expect("Can't serialize a planet");
kafka::send_message(producer, message).await;

Клиент API может быть уведомлен об этом событии с помощью подписки, слушающей Kafka consumer:

Определение подписки

pub struct Subscription;

#[Subscription]
impl Subscription {
    async fn latest_planet<'ctx>(&self, ctx: &'ctx Context<'_>) -> impl Stream<Item=Planet> + 'ctx {
        let kafka_consumer_counter = ctx.data::<Mutex<i32>>().expect("Can't get Kafka consumer counter");
        let consumer_group_id = kafka::get_kafka_consumer_group_id(kafka_consumer_counter);
        let consumer = kafka::create_consumer(consumer_group_id);

        async_stream::stream! {
            let mut stream = consumer.start();

            while let Some(value) = stream.next().await {
                yield match value {
                    Ok(message) => {
                        let payload = message.payload().expect("Kafka message should contain payload");
                        let message = String::from_utf8_lossy(payload).to_string();
                        serde_json::from_str(&message).expect("Can't deserialize a planet")
                    }
                    Err(e) => panic!("Error while Kafka message processing: {}", e)
                };
            }
        }
    }
}

Подписка может быть использована так же, как запросы и мутации:

Пример использования подписки

subscription {
  latestPlanet {
    id
    name
    type
    details {
      meanRadius
    }
  }
}

Подписки должны отправляться на ws://localhost:8001.

Интеграционные тесты

Тесты запросов и мутаций можно написать так:

Тест запроса

#[actix_rt::test]
async fn test_get_planets() {
    let docker = Cli::default();
    let (_pg_container, pool) = common::setup(&docker);

    let mut service = test::init_service(App::new()
        .configure(configure_service)
        .data(create_schema_with_context(pool))
    ).await;

    let query = "
        {
            getPlanets {
                id
                name
                type
                details {
                    meanRadius
                    mass
                    ... on InhabitedPlanetDetails {
                        population
                    }
                }
            }
        }
        ".to_string();

    let request_body = GraphQLCustomRequest {
        query,
        variables: Map::new(),
    };

    let request = test::TestRequest::post().uri("/").set_json(&request_body).to_request();

    let response: GraphQLCustomResponse = test::read_response_json(&mut service, request).await;

    fn get_planet_as_json(all_planets: &serde_json::Value, index: i32) -> &serde_json::Value {
        jsonpath::select(all_planets, &format!("$.getPlanets[{}]", index)).expect("Can't get planet by JSON path")[0]
    }

    let mercury_json = get_planet_as_json(&response.data, 0);
    common::check_planet(mercury_json, 1, "Mercury", "TERRESTRIAL_PLANET", "2439.7");

    let earth_json = get_planet_as_json(&response.data, 2);
    common::check_planet(earth_json, 3, "Earth", "TERRESTRIAL_PLANET", "6371.0");

    let neptune_json = get_planet_as_json(&response.data, 7);
    common::check_planet(neptune_json, 8, "Neptune", "ICE_GIANT", "24622.0");
}

Если часть запроса может быть переиспользована в другом запросе, вы можете использовать фрагменты:

Тест запроса с использованием фрагмента

const PLANET_FRAGMENT: &str = "
    fragment planetFragment on Planet {
        id
        name
        type
        details {
            meanRadius
            mass
            ... on InhabitedPlanetDetails {
                population
            }
        }
    }
";

#[actix_rt::test]
async fn test_get_planet_by_id() {
    ...

    let query = "
        {
            getPlanet(id: 3) {
                ... planetFragment
            }
        }
        ".to_string() + PLANET_FRAGMENT;

    let request_body = GraphQLCustomRequest {
        query,
        variables: Map::new(),
    };

    ...
}

Чтобы использовать переменные, запишите тест так:

Тест запроса с использованием фрагмента и переменной

#[actix_rt::test]
async fn test_get_planet_by_id_with_variable() {
    ...

    let query = "
        query testPlanetById($planetId: String!) {
            getPlanet(id: $planetId) {
                ... planetFragment
            }
        }".to_string() + PLANET_FRAGMENT;

    let jupiter_id = 5;
    let mut variables = Map::new();
    variables.insert("planetId".to_string(), jupiter_id.into());

    let request_body = GraphQLCustomRequest {
        query,
        variables,
    };

    ...
}

В этом проекте используется библиотека Testcontainers-rs, что позволяет подготовить тестовое окружение, то есть, создать временную БД PostgreSQL.

Клиент к GraphQL API

Вы можете использовать код из предыдущего раздела для создания клиента к внешнему GraphQL API. Также для этого существуют специальные библиотеки, например, graphql-client, но я их не использовал.

Безопасность API

Существуют различные угрозы безопасности GraphQL API (см. список); рассмотрим некоторые из них.

Ограничения глубины и сложности запроса

Если бы структура Satellite содержала поле planet, был бы возможен такой запрос:

Пример тяжёлого запроса

{
  getPlanet(id: "1") {
    satellites {
      planet {
        satellites {
          planet {
            satellites {
              ... # more deep nesting!
            }
          }
        }
      }
    }
  }
}

Сделать такой запрос невалидным можно так:

Пример ограничения глубины и сложности запроса

pub fn create_schema_with_context(pool: PgPool) -> Schema<Query, Mutation, Subscription> {
    ...

    Schema::build(Query, Mutation, Subscription)
        .limit_depth(3)
        .limit_complexity(15)

    ...
}

Стоит отметить, что при указании ограничений выше может перестать отображаться документация сервиса в GraphQL IDE. Это происходит потому, что IDE пытается выполнить introspection query, который имеет заметные глубину и сложность.

Аутентификация

Эта функциональность реализована в auth-service с использованием крэйтов argonautica и jsonwebtoken. Первый отвечает за хэширование паролей пользователей с использованием алгоритма Argon2. Аутентификация и авторизация показаны исключительно в демонстрационных целях; пожалуйста, изучите вопрос более тщательно перед использованием в продакшене.

Рассмотрим как реализован вход в систему:

Реализация входа в систему

pub struct Mutation;

#[Object]
impl Mutation {

    async fn sign_in(&self, ctx: &Context<'_>, input: SignInInput) -> Result<String, Error> {
        let maybe_user = repository::get_user(&input.username, &get_conn_from_ctx(ctx)).ok();

        if let Some(user) = maybe_user {
            if let Ok(matching) = verify_password(&user.hash, &input.password) {
                if matching {
                    let role = AuthRole::from_str(user.role.as_str()).expect("Can't convert &str to AuthRole");
                    return Ok(common_utils::create_token(user.username, role));
                }
            }
        }

        Err(Error::new("Can't authenticate a user"))
    }
}

#[derive(InputObject)]
struct SignInInput {
    username: String,
    password: String,
}

Посмотреть реализацию функции verify_password можно в модуле utils, create_token в модуле common_utils. Как вы могли бы ожидать, функция sign_in возвращает JWT, который в дальнейшем может быть использован для авторизации в других сервисах.

Для получения JWT выполните следующую мутацию:

Получение JWT

mutation {
  signIn(input: { username: "john_doe", password: "password" })
}

Используйте параметры john_doe/password. Включение полученного JWT в последующие запросы позволит получить доступ к защищённым ресурсам (см. следующий раздел).

Авторизация

Чтобы запросить защищённые данные, добавьте заголовок в HTTP запрос в формате Authorization: Bearer $JWT. Функция index извлечёт роль пользователя из HTTP запроса и добавит её в параметры GraphQL запроса/мутации:

Получение роли

async fn index(schema: web::Data<AppSchema>, http_req: HttpRequest, req: Request) -> Response {
    let mut query = req.into_inner();

    let maybe_role = common_utils::get_role(http_req);
    if let Some(role) = maybe_role {
        query = query.data(role);
    }

    schema.execute(query).await.into()
}

К ранее показанной мутации create_planet применён следующий атрибут:

Использование гарда

#[graphql(guard(RoleGuard(role = "Role::Admin")))]

Сам гард реализован так:

Реализация гарда

struct RoleGuard {
    role: Role,
}

#[async_trait::async_trait]
impl Guard for RoleGuard {
    async fn check(&self, ctx: &Context<'_>) -> Result<()> {
        if ctx.data_opt::<Role>() == Some(&self.role) {
            Ok(())
        } else {
            Err("Forbidden".into())
        }
    }
}

Таким образом, если вы не укажете токен, сервер ответит сообщением "Forbidden".

Определение перечисления

GraphQL перечисление может быть определено так:

Определение перечисления

#[derive(SimpleObject)]
struct Satellite {
    ...
    life_exists: LifeExists,
}

#[derive(Copy, Clone, Eq, PartialEq, Debug, Enum, EnumString)]
#[strum(serialize_all = "SCREAMING_SNAKE_CASE")]
pub enum LifeExists {
    Yes,
    OpenQuestion,
    NoData,
}

Работа с датами

Async-graphql поддерживает типы даты/времени из библиотеки chrono, поэтому вы можете определить такие поля как обычно:

Определение поля с датой

#[derive(SimpleObject)]
struct Satellite {
    ...
    first_spacecraft_landing_date: Option<NaiveDate>,
}

Поддержка Apollo Federation

Одна из целей satellites-service — продемонстрировать как распределённая GraphQL сущность (Planet) может резолвиться в двух (или более) сервисах и затем запрашиваться через Apollo Server.

Тип Planet был ранее определён в planets-service так:

Определение типа Planet в planets-service

#[derive(Serialize, Deserialize)]
struct Planet {
    id: ID,
    name: String,
    planet_type: PlanetType,
}

Также в planets-service тип Planet является сущностью:

Определение сущности Planet

#[Object]
impl Query {
    #[graphql(entity)]
    async fn find_planet_by_id(&self, ctx: &Context<'_>, id: ID) -> Option<Planet> {
        find_planet_by_id_internal(ctx, id)
    }
}

satellites-service расширяет сущность Planet путём добавления поля satellites:

Расширение типа Planet в satellites-service

struct Planet {
    id: ID
}

#[Object(extends)]
impl Planet {
    #[graphql(external)]
    async fn id(&self) -> &ID {
        &self.id
    }

    async fn satellites(&self, ctx: &Context<'_>) -> Vec<Satellite> {
        let id = self.id.to_string().parse::<i32>().expect("Can't get id from String");
        repository::get_by_planet_id(id, &get_conn_from_ctx(ctx)).expect("Can't get satellites of planet")
            .iter()
            .map(|e| { Satellite::from(e) })
            .collect()
    }
}

Также вам нужно реализовать функцию поиска для расширяемого типа. В примере ниже функция просто создаёт новый инстанс Planet:

Функция поиска для типа Planet

#[Object]
impl Query {

    #[graphql(entity)]
    async fn get_planet_by_id(&self, id: ID) -> Planet {
        Planet { id }
    }
}

Async-graphql генерирует два дополнительных запроса (_service and _entities), которые будут использованы Apollo Server'ом. Эти запросы — внутренние, то есть они не будут отображены в API Apollo Server'а. Конечно, сервис с поддержкой Apollo Federation по-прежнему может работать автономно.

Apollo Server

Apollo Server и Apollo Federation позволяют достичь две основные цели:

создать единую точку доступа к нескольким GraphQL API
создать единый граф данных из распределённых сущностей

Таким образом, даже если вы не используете распределённые сущности, для frontend разработчиков удобнее использовать одну точку доступа, чем несколько.

Существует и другой способ создания единой GraphQL схемы, schema stitching, но пока что я его не использовал.

Модуль включает следующий исходный код:

Мета-информация и зависимости

{
  "name": "api-gateway",
  "main": "gateway.js",
  "scripts": {
    "start-gateway": "nodemon gateway.js"
  },
  "devDependencies": {
    "concurrently": "5.3.0",
    "nodemon": "2.0.6"
  },
  "dependencies": {
    "@apollo/gateway": "0.21.3",
    "apollo-server": "2.19.0",
    "graphql": "15.4.0"
  }
}

Определение Apollo Server

const {ApolloServer} = require("apollo-server");
const {ApolloGateway, RemoteGraphQLDataSource} = require("@apollo/gateway");

class AuthenticatedDataSource extends RemoteGraphQLDataSource {
    willSendRequest({request, context}) {
        if (context.authHeaderValue) {
            request.http.headers.set('Authorization', context.authHeaderValue);
        }
    }
}

let node_env = process.env.NODE_ENV;

function get_service_url(service_name, port) {
    let host;
    switch (node_env) {
        case 'docker':
            host = service_name;
            break;
        case 'local': {
            host = 'localhost';
            break
        }
    }

    return "http://" + host + ":" + port;
}

const gateway = new ApolloGateway({
    serviceList: [
        {name: "planets-service", url: get_service_url("planets-service", 8001)},
        {name: "satellites-service", url: get_service_url("satellites-service", 8002)},
        {name: "auth-service", url: get_service_url("auth-service", 8003)},
    ],
    buildService({name, url}) {
        return new AuthenticatedDataSource({url});
    },
});

const server = new ApolloServer({
    gateway, subscriptions: false, context: ({req}) => ({
        authHeaderValue: req.headers.authorization
    })
});

server.listen({host: "0.0.0.0", port: 4000}).then(({url}) => {
    console.log(`? Server ready at ${url}`);
});

Если код выше может быть упрощён, не стесняйтесь поправить.

Авторизация в apollo-service работает так же, как было показано ранее для Rust сервисов (вам надо указать заголовок Authorization и его значение).

Приложение, написанное на любом языке или фреймворке, может быть добавлено в качестве нижележащего сервиса под Apollo Server, если оно реализует спецификацию Federation; список библиотек, добавляющих поддержку этой спецификации доступен в документации.

При реализации модуля я столкнулся со следующими ограничениями:

Apollo Gateway не поддерживает подписки (но они по-прежнему работают в standalone Rust сервисе)
сервису, пытающемуся расширить GraphQL интерфейс требуется информация о его конкретных имплементациях

Взаимодействие с БД

Уровень хранения реализован с помощью PostgreSQL and Diesel. Если вы не используете Docker при локальном запуске, то нужно выполнить diesel setup, находясь в директории каждого из сервисов. Это создаст пустую БД, к которой далее будут применены миграции, создающие таблицы и инициализирующие данные.

Запуск проекта и тестирование API

Как было отмечено ранее, проект можно запустить двумя способами:

с использованием Docker Compose (docker-compose.yml)
Здесь, в свою очередь, также возможны два варианта:
- режим разработки (используя локально собранные образы)
  docker-compose up
- production mode (используя релизные образы)
  docker-compose -f docker-compose.yml up
без Docker
Запустите каждый Rust сервис с помощью cargo run, потом запустите Apollo Server:
- cd в папку apollo-server
- определите переменную среды NODE_ENV, например, set NODE_ENV=local (для Windows)
- npm install
- npm run start-gateway

Успешный запуск apollo-server должен выглядеть так:

Лог запуска Apollo Server

[nodemon] 2.0.6
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): *.*
[nodemon] watching extensions: js,mjs,json
[nodemon] starting `node gateway.js`
Server ready at http://0.0.0.0:4000/

Вы можете перейти на http://localhost:4000 в браузере и использовать встроенную Playground IDE:

Здесь возможно выполнять запросы, мутации и подписки, определённые в нижележащих сервисах. Кроме того, каждый из этих сервисов имеет собственную Playground IDE.

Тест подписки

Чтобы убедиться в том, что подписка работает, откройте две вкладки любой GraphQL IDE; в первой подпишитесь таким образом:

Пример подписки

subscription {
  latestPlanet {
    name
    type
  }
}

Во второй укажите заголовок Authorization как было описано ранее и выполните мутацию:

Пример мутации

mutation {
  createPlanet(
    planet: {
      name: "Pluto"
      type: DWARF_PLANET
      details: { meanRadius: "1188", mass: "1.303e22" }
    }
  ) {
    id
  }
}

Подписанный клиент будет уведомлен о событии:

CI/CD

CI/CD сконфигурирован с помощью GitHub Actions (workflow), который запускает тесты приложений, собирает их Docker образы и разворачивает их на Google Cloud Platform.

Вы можете посмотреть на описанные API здесь.

Замечание: На "продакшн" среде пароль отличается от указанного ранее, чтобы предотвратить изменение данных.

Заключение

В этой статье я рассмотрел как решать наиболее частые вопросы, которые могут возникнуть при разработке GraphQL API на Rust. Также было показано как объединить API Rust GraphQL микросервисов для получения единого GraphQL интерфейса; в подобной архитектуре сущность может быть распределена среди нескольких микросервисов. Это достигается за счёт использования Apollo Server, Apollo Federation и библиотеки Async-graphql. Исходный код рассмотренного проекта доступен на GitHub. Не стесняйтесь написать мне, если найдёте ошибки в статье или исходном коде. Благодарю за внимание!

Полезные ссылки

Комментарии (27)

ShashkovS
09.03.2021 17:57
#22783486
А есть ли какие-либо данные по производительности такого решения?
1. not_bad Автор
  09.03.2021 18:25
  #22783582
  Можете посмотреть по ссылке на live demo в разделе CI/CD.
  
  Всё запущено на e2-small GCE инстансе. Под нагрузкой не пробовал, сейчас показывает:

Kwisatz
09.03.2021 18:40
#22783628
Красиво, и подписки есть, не хватает только блокировок для полного счастья.
Очень крутая статья хоть и не пишу на раст.

ЗЫ вообще чем больше смотрю на graphql тем меньше понимаю почему рест еще не сдох.
1. domix32
  10.03.2021 14:35
  #22786916
  Потому что нельзя взять и переписать миллионы приложений, которые уже работают на нем. Если проблемы масштабирования не возникает, то и переезд с уже работающего REST имеет мало ценности. Плюс некоторые новый код продолжают пилить с ним для единообразия собственной инфраструктуры.
1. Fortop
  10.03.2021 16:44
  #22787856
  -1
  Потому что graphql кривой и ряд вещей без бубна в нем не делаются?
  1. not_bad Автор
    10.03.2021 21:43
    #22789368
    +1
    Уточните, пожалуйста, пару моментов:
    
    "кривая" спецификация GraphQL или какие-то из реализаций на конкретных языках? Если второе, то на каких именно?
    
    "ряд вещей" — можете привести пару примеров?
    
    Fortop
    11.03.2021 02:06
    #22790148
    Сама идеология.
    
    Имеются проблемы с гранулярностью контроля доступа к данным.
    С нормальным кешированием.
    Да и rate limit в рамках его идеологии ложится из рук вон плохо.
    
    P.S. И да, у REST своего… хватает. Но поскольку он чуть ниже уровнем, то жить с этим чуток проще.
    
    not_bad Автор
    11.03.2021 13:27
    #22792236
    Я не считаю идеологию кривой. Запрашивать ровно те данные, которые нужны клиенту, при меньшем количестве сетевых запросов — вполне нормальный подход. Может наоборот, REST кривой в этом аспекте?
    
    По поводу примеров:
    
    если я правильно понял "гранулярность доступа", то с этим всё ок. Сама спека ничего не говорит об этом, при этом конкретные реализации могут имплементировать данную функциональность. Что и было показано в статье (раздел "Авторизация"), когда для мутации определён "гард". Аналогично гард может быть указан для любого поля какой-либо структуры. В других фреймворках это будет реализовано по-другому
    
    кэширование — не знаю, что вы имеете в виду. Вот пара ссылок: eng/ru, судя по которым не кажется, что кэширование в GraphQL — это rocket science. Да, сделано по-другому, чем в REST, но это ведь не значит криво?
    
    rate limit — сходу не нашёл примеров реализации, но стоит отметить, что эта проблема не столь актуальна как в REST. В GraphQL вызовы одной и той же query могут содержать разные наборы полей, поэтому большее значение имеет возможность ограничения глубины и сложности запроса, что, полагаю, реализовано в большинстве GraphQL библиотек и также было показано в статье
    
    Fortop
    12.03.2021 11:14
    #22796548
    Начнем со второй части.
    
    если я правильно понял «гранулярность доступа», то с этим всё ок.
    
    Ничего там не ок. Там зубодробительная логика на стороне бекенда получается.
    Вы никогда не знаете что захочет запросить клиент и вынуждены покрывать все кейсы.
    А это ведет либо к запутанному, либо к медленному коду.
    
    Кеш в целом для graphql сложнее. У вас нет никаких гарантий что в рамках одного и того же запроса даже с одинаковым unique ID, как рекомендуют по вашим ссылкам, у вас будут одинаковые структуры и одинаковый набор полей (вы ведь при запросе их указываете).
    Можно делать прегенерированные запросы с гарантированным набором полей (это, кстати, решает и вопрос доступа) и кешировать их, но это превращает всю идеологию graphql в тыкву.
    github.com/apollographql/persistgraphql
    Правда не знаю что сейчас актуально вместо этого решения, а искать лень.
    
    rate limit — сходу не нашёл примеров реализации,
    
    Они есть, но там тоже ничего приятного.
    
    Теперь вернемся к нашим баранам.
    
    Я не считаю идеологию кривой. Запрашивать ровно те данные, которые нужны клиенту, при меньшем количестве сетевых запросов — вполне нормальный подход.
    
    Идеология graphql в инверсии контроля, а не «запрашивать те данные которые нужны».
    Вы перекладываете контроль за тем что и как вам нужно на строну клиента.
    Пока у вас приложение внутреннее — все ок.
    Как только вы интерфейс выставляете наружу, то выясняется что доверять клиенту нельзя. Отсюда и вопрос доступа, и вопрос лимита на запросы и т.п.
    
    Поэтому идеология и кривая — потому что она содержит противоречия прямо внутри себя.
    В этом контексте REST имеет меньше противоречий, потому что он тупой.
    
    И, да, это не значит что я за REST. Мне он не нравится лишь немногим меньше чем graphql.
    Как разумную альтернативу здорового человека я предлагаю использовать RPC и его вариации в виде JSON-RPC, XML-RPC, gRPC.
    
    У него есть минусы.
    
    вы должны предусмотреть варианты запросов заранее (но смотрим persistgraphql)
    
    вы будете медленнее вносить изменения потому что они должны будут сделаны и на клиенте и на бекенде.
    
    Но при этом.
    
    У вас сохраняется возможность запросить ровно те данные, которые нужны на клиента.
    
    У вас нет проблем присущих graphql с доступами и ratelimit.
    
    У вас нет проблем излишней абстрактности REST, который вынуждал дробить запросы.
    
    not_bad Автор
    12.03.2021 16:43
    #22798246
    Там зубодробительная логика на стороне бекенда получается.
    Это ваш личный опыт реализации GraphQL API или в вашей компании? Дело в том, что множество материалов, включая прочитанную (?) вами настоящую статью, это не подтверждают
    
    Идеология graphql в инверсии контроля, а не «запрашивать те данные которые нужны». Вы перекладываете контроль за тем что и как вам нужно на строну клиента.
    Это вольная трактовка или есть источники/ссылки, подтверждающие что это и есть иделогия?
    
    Вы перекладываете контроль за тем что и как вам нужно на строну клиента.
    Пока у вас приложение внутреннее — все ок.
    Как только вы интерфейс выставляете наружу, то выясняется что доверять клиенту нельзя. Отсюда и вопрос доступа, и вопрос лимита на запросы и т.п.
    "GraphQL позволяет клиенту выбирать нужные ему данные с точностью до полей, но при этом всё ещё нужно обеспечивать безопасность приложения" — no comment
    
    Как разумную альтернативу здорового человека я предлагаю использовать RPC и его вариации в виде JSON-RPC, XML-RPC, gRPC.
    Как разумный здоровый человек я воздержусь от обсуждения RPC как способа frontend-backend взаимодействия в комментариях к статье "GraphQL на Rust"
    
    Доп. вопрос: какую библиотеку вы использовали для реализации GraphQL API?
    
    Fortop
    12.03.2021 18:01
    #22798656
    Дело в том, что множество материалов, включая прочитанную (?) вами настоящую статью, это не подтверждают
    
    Угу, туториалы они такие туториалы. Но когда пишешь или смотришь на чужие реализации отличные от туториалов то все почему-то не так радужно…
    
    Почему бы это вдруг?
    
    Hint: включите свои гварды на запрос с 3-4 join/subselect обеспечив ограничение области видимости отдельных полей для разных пользователей и не запрашивая их у БД, если пользователю они не доступны по контексту данных (ой да, бывает и такое).
    
    Это вольная трактовка или есть источники/ссылки, подтверждающие что это и есть иделогия?
    
    Это то, что содержится в вашем же определении выделенном кавычками.
    Вы незнакомы с тем как в реальности работают стандартные API и веб сервисы и не понимаете почему graphql декларирует инверсию контроля в сравнении с ними?
    
    Доп. вопрос: какую библиотеку вы использовали для реализации GraphQL API?
    
    graphql-php
    и уже не помню что на стороне nodejs в качестве api gateway. Емнип что-то из apollo, но это не точно, давненько было.
    Чем вам это поможет в бессмысленных попытках натянуть сову на глобус?
    
    По запросу «graphql drawbacks» гугл выдаёт почти то же самое, что привели вы. Совпадение?
    
    А сейчас я вам перечислю список планет в солнечной системе, а вы начнете меня обвинять в том, что он совпадает с списком из гугла…
    
    Ну-ну.
    
    not_bad Автор
    12.03.2021 18:28
    #22798742
    Угу, туториалы они такие туториалы. Но когда пишешь или смотришь на чужие реализации отличные от туториалов то все почему-то не так радужно…
    Я правильно понял, что у вас не получилось реализовать GraphQL API в рабочем проекте без проблем с перформансом?
    
    Это то, что содержится в вашем же определении выделенном кавычками.
    Так вы же попытались там опровергнуть моё определение, предложив своё. Вот мне и стало интересно, откуда оно?
    
    Чем вам это поможет в бессмысленных попытках натянуть сову на глобус?
    О чём вы?
    
    А сейчас я вам перечислю список планет в солнечной системе, а вы начнете меня обвинять в том, что он совпадает с списком из гугла…
    Где вы увидели обвинение? Я только уточнил
    
    Fortop
    12.03.2021 19:51
    #22799070
    Я правильно понял, что у вас не получилось реализовать GraphQL API в рабочем проекте без проблем с перформансом?
    
    Я правильно понимаю что у вас нет внятной аргументации и ответов и поэтому вы пытаетесь о чем-то догадаться?
    
    Так вы же попытались там опровергнуть моё определение, предложив своё. Вот мне и стало интересно, откуда оно?
    
    Оно не мое. Это прямо следует из вашего определения.
    
    Если дверь открывается, но ее открывали не вы, то это сделал кто-то (или что-то) отличное от вас.
    
    Это прямо таки рокетсайнс?
    
    О чём вы?
    
    О вашей идее что graphql это серебрянная пуля, подходящая везде всегда и вообще наилучшее решение.
    Ведь именно это вы пытаетесь протолкнуть не сумев опровергнуть ни одного из замечаний, ссылаясь исключительно на «там кто-то написал».
    
    not_bad Автор
    12.03.2021 22:15
    #22799614
    Я правильно понимаю что у вас нет внятной аргументации и ответов и поэтому вы пытаетесь о чем-то догадаться?
    Нет, вы ошибаетесь, аргументация есть. Оптимально, когда задаваемые вопросы касаются темы статьи ("GraphQL на Rust"). Также по мере возможностей отвечаю на более абстрактные вопросы, в том числе совпадающие с поисковой выдачей гугла по запросу "graphql drawbacks"
    
    О вашей идее что graphql это серебрянная пуля, подходящая везде всегда и вообще наилучшее решение.
    Ведь именно это вы пытаетесь протолкнуть не сумев опровергнуть ни одного из замечаний, ссылаясь исключительно на «там кто-то написал».
    А вот это уже клевета. Не уверен, что это разрешено правилами сайта
    
    not_bad Автор
    12.03.2021 17:26
    #22798448
    -1
    del
    
    not_bad Автор
    12.03.2021 17:29
    #22798478
    -1
    По запросу "graphql drawbacks" гугл выдаёт почти то же самое, что привели вы. Совпадение?
  1. Kwisatz
    10.03.2021 22:36
    #22789572
    Поддерживаю оратора выше а так же замечу что rest api вот уж точно кривой и точно ряд вещей без бубна не делаются.
1. andreyverbin
  10.03.2021 20:18
  #22789046
  REST проще, GraphQL нужен для моделей типа FB, а таких в природе немного.
  1. not_bad Автор
    10.03.2021 21:56
    #22789432
    Я всё же использовал GraphQL в паре рабочих проектов вне FAANG, при этом думаю, что реализация подобных доменных моделей на REST была бы болью и для фронтэнда, и для бэкэнда.
    Но порог входа, думаю, у GraphQL действительно выше.
    
    andreyverbin
    14.03.2021 12:35
    #22801070
    Каким образом в GraphQL гарантировать, что через апи нельзя выбрать лишнего и что запросы, которые получаются не уложат базу? Если есть простой способ этого добиться, то я только за, но пока непонятно как это должно работать. Имеем мощный язык, а на беке, выходит, нужно уметь любые возможные выражения этого языка правильно превращать в запросы. Это выглядит очень сложно.
    
    not_bad Автор
    14.03.2021 20:50
    #22802478
    -1
    Каким образом в GraphQL гарантировать, что через апи нельзя выбрать лишнего
    А что вы понимаете под "выбрать лишнего"? В моём понимании это гарантирует синтаксис. В статье есть пример запроса:
    
    { getPlanets { name type } }
    
    В ответ на это GraphQL сервер пришлёт исключительно 2 запрашиваемых поля для каждого элемента возвращаемого списка.
    
    запросы, которые получаются не уложат базу
    Для этого есть несколько инструментов:
    
    ограничение сложности и глубины запроса
    
    решение проблемы N+1
    
    пагинация (для query, возвращающих массивы/списки с большим количеством элементов, создайте параметры pageNumber, pageSize)
    
    Первые два вопроса освещены в статье. Да и в целом по ним достаточно материала
    
    Если есть простой способ этого добиться
    Имплементация вышеуказанного — в целом решаемая задача
    
    andreyverbin
    14.03.2021 01:18
    #22803226
    +1
    А что вы понимаете под "выбрать лишнего"?
    Попросить
    
    { blog { published_posts { author { posts } } }
    
    И либо положить базу, либо получить неопубликованные посты автора, ибо кто-то на сервере не подумал, что клиент может такой хитрый запрос отправить.
    
    ограничение сложности и глубины запроса
    Ткните меня носом, где это смотреть? Сложность запроса же от схемы БД и от данных зависит, как GraphQL знает, какой запрос окажется сложным, а какой нет? Разве он знает, что в моем блоге только один автор, а комментарии упорядочены по времени и их можно эффективно считать с помощью специально для этого сделанного индекса?
    
    not_bad Автор
    14.03.2021 19:45
    #22804876
    -1
    Я бы предложил поменять схему данных, после чего запрос станет:
    
    { getPosts(filter: {status: PUBLISHED}, page: {number: 1, size: 10}) { author { name } } }
    
    Далее, предположим у кого-то появится желание положить сервер таким запросом:
    
    { getPosts(filter: {status: PUBLISHED}, page: {number: 1, size: 10}) { author { posts { author { posts { # и т. д. } } } } } }
    
    Предотвратить такую циклическую цепочку вызовов невозможно, если только не поменять типы, удалив поле Author.posts или Post.author.
    
    Поэтому первое с чего стоит начать — это ограничение глубины запроса (разумеется, GraphQL, а не SQL. В качестве хранилища может быть что угодно: SQL, NoSQL, in-memory и т. д., о чём GraphQL знать не нужно). В данном простейшем случае можно установить его например 3, чего должно быть достаточно для получения всех нужных данных. Соответственно, клиенту при выполнении запроса выше придёт сообщение о его невалидности.
    
    Также можно указать, что поле Author.posts принимает аргумент количества постов, тогда запрос станет:
    
    { getPosts(filter: {status: PUBLISHED}, page: {number: 1, size: 10}) { author { posts(first: 10) { title } } } }
    
    Вроде обращение Author.posts и избыточно, но по крайней мере не критично для перформанса.
    
    Если этих простейших шагов окажется недостаточно, то можно использовать более продвинутые техники (например, Query Cost Analysis) (см. https://www.apollographql.com/blog/securing-your-graphql-api-from-malicious-queries-16130a324a6b/ и другие источники).
    
    andreyverbin
    14.03.2021 20:34
    #22805002
    Спасибо, но вы так и не ответили по существу моего вопроса. Каким образом мне убедиться, что любой возможный GraphQL запрос
    
    Не положит базу.
    
    Не вытащит чего-то, чего юзеру видеть нельзя.
    
    В REST есть похожие проблемы, но их масштаб, кажется, значительно меньше.
    
    not_bad Автор
    14.03.2021 20:58
    #22805066
    -1
    Спасибо, что представили существо вопроса
    
    Используйте все указанные выше подходы
    
    Изучите документацию к выбранному фреймворку и используйте представленные там подходы к security
    
    andreyverbin
    15.03.2021 01:22
    #22805640
    Идем сюда — cve.mitre.org/cgi-bin/cvekey.cgi?keyword=GraphQL и смотрим первые 10 уязвимостей. Видим, что 6 из них это про получение или модификацию данных, которые получить и модифицировать нельзя (CVE-2021-22863, CVE-2020-6165, CVE-2020-26417, CVE-2020-26415, CVE-2020-26413, CVE-2020-2640). Занавес. Похоже у ребят из Gitlab, Github и SilverStripe активно наступают на грабли, о которых я говорю.
  1. Kwisatz
    10.03.2021 23:10
    #22789668
    Нет не проще когда вы доходите до подписок и селективности свойств, а вы до них в любом случае дойдете.

GraphQL на Rust +20

Введение

Обзор

Стэк технологий

Необходимое ПО

Реализация

Зависимости

Ключевые функции

Определение GraphQL запроса и типа

Проблема N+1

Определение интерфейса

Определение кастомного скалярного типа

Определение мутации

Определение подписки

Интеграционные тесты

Клиент к GraphQL API

Безопасность API

Ограничения глубины и сложности запроса

Аутентификация

Авторизация

Определение перечисления

Работа с датами

Поддержка Apollo Federation

Apollo Server

Взаимодействие с БД

Запуск проекта и тестирование API

Тест подписки

CI/CD

Заключение

Полезные ссылки

Комментарии (27)

not_bad Автор

not_bad Автор

not_bad Автор

not_bad Автор

not_bad Автор

not_bad Автор

not_bad Автор

not_bad Автор

not_bad Автор

not_bad Автор

not_bad Автор

not_bad Автор