Desempenho em aplicações web que utilizam GraphQL (mas não somente)

GDG Lauro de Freitas

08 de novembro de 2024

 

  • Ciência da Computação / UFBA
  • Ruby On Rails desde 2008 / JavaScript desde 2006
  • https://ca.ios.ba
  • @caiosba
  • São Francisco - Califórnia
  • Engenheiro de Software desde 2011      
  • https://meedan.com
  • @meedan

Check

   github.com/meedan/check-api

   github.com/meedan/check

O foco desta palestra é...

GraphQL

Ruby On Rails

... mas não precisa ser!

Muitos conceitos e arquiteturas são aplicados a outros frameworks e stacks.

Mais disclaimers!

  • Não existe bala de prata
  • Otimização Prematura
  • Os problemas e soluções apresentados aqui funcionaram para mim, mas dependem de fatores diferentes (por exemplo, banco de dados) e necessidades - e lembre-se, toda decisão tem um trade-off (manutenibilidade, legibilidade, dependências, etc.)

GraphQL

"GraphQL é uma linguagem de consulta para sua API, e uma ferramenta do lado do servidor para executar consultas usando um sistema de tipos que você define para seus dados."

 

 

REST

Media

Comment

Tag

1

*

User

*

*

*

1

GET /api/v1/medias/1
GET /api/v1/medias/1/comments
GET /api/v1/medias/1/tags
GET /api/v1/medias/1/comments/1
GET /api/v1/users/1?fields=avatar,name
GET /api/v1/users/2?fields=avatar,name
GET /api/v1/users/3?fields=avatar,name
...

Endpoints reutilizáveis

GET /api/v1/medias/1?include=comments&count=5

GET /api/v1/medias/1?include=comments,tags
    &comments_count=5&tags_count=5

GET /api/v1/medias/1?fields=comments(text,date)
    &tags(tag)


...


GET /api/v1/media_and_comments/1
GET /api/v1/media_comments_and_tags/1
GET /api/v1/media_comments_tags_and_users/1
GET /api/v1/medias/1?include=comments&count=5

GET /api/v1/medias/1?include=comments,tags
    &comments_count=5&tags_count=5

GET /api/v1/medias/1?fields=comments(text,date)
    &tags(tag)


...


GET /api/v1/media_and_comments/1
GET /api/v1/media_comments_and_tags/1
GET /api/v1/media_comments_tags_and_users/1

Muitas requisições!

GraphQL

Um endpoint para todos governar

POST /graphql

POST /api/graphql?query=
{
  media(id: 1) {
    title
    embed
    tags(first: 3) {
      tag
    }
    comments(first: 5) {
      created_at
      text
      user {
        name,
        avatar
      }
    }
  }
}
POST /api/graphql?query=
{
  media(id: 1) {
    title
    embed
    tags(first: 3) {
      tag
    }
    comments(first: 5) {
      created_at
      text
      user {
        name,
        avatar
      }
    }
  }
}

Media

Comment

Tag

1

*

User

*

*

*

1

~

POST /api/graphql?query=
{
  media(id: 1) {
    title
    embed
    tags(first: 3) {
      tag
    }
    comments(first: 5) {
      created_at
      text
      user {
        name,
        avatar
      }
    }
  }
}
{
  "media": {
    "title": "Avangers Hulk Smash",
    "embed": "<iframe src=\"...\"></iframe>",
    "tags": [
      { "tag": "avengers" },
      { "tag": "operation" }
    ],
    "comments": [
      {
        "text": "This is true",
        "created_at": "2016-09-18 15:04:39",
        "user": {
          "name": "Ironman",
          "avatar": "http://[...].png"
        }
      },
      ...
    ]
  }
}

GraphQL

Ruby On Rails

Tipos

  • Tipos personalizados
  • Argumentos
  • Campos
  • Conexões

Mutations

mutation { 
  createMedia(
    input: {
      url: "http://youtu.be/7a_insd29fk"
      clientMutationId: "1"
    }
   )
   {
     media {
       id
     }
   }
}

As mutações fazem alterações no seu lado do servidor.

CRUD:

Queries: Read

Mutations:

  • Create
  • Update
  • Delete
# mutation { 
     createMedia(
#     input: {
        url: "http://youtu.be/7a_insd29fk"
#       clientMutationId: "1"
#     }
#    )
     {
       media {
         id
       }
     }
# }

Nome da mutação

Parâmetros de entrada

Saída desejada

Muito flexível!

😊

 

Flexível demais!

😔

 

query {
  teams(first: 1000) {
    name
    profile_image
    users(first: 1000) {
      name
      email
      posts(first: 1000) {
        title
        body
        tags(first: 1000) {
          tag_name
        }
      }
    }
  }
}

Consultas aninhadas podem se tornar um verdadeiro problema.

 

A complexidade real de uma consulta e o custo de alguns campos podem ficar ocultos pela expressividade da linguagem.

 

Vamos ver algumas estratégias para lidar com isso.

Vamos por partes... Você não pode realmente consertar o que não pode testar

# Some controller test

gql_query = 'query { posts(first: 10) { title, user { name } } }'
assert_queries 5 do
  post :create, params: { query: gql_query }
end

Monitore se alguma refatoração ou alteração de código introduz regressões em como algumas consultas GraphQL são executadas.

# Some test helper

def assert_queries(max, &block)
  query_cache_enabled = ApplicationRecord.connection.query_cache_enabled
  ApplicationRecord.connection.enable_query_cache!
  queries  = []
  callback = lambda { |_name, _start, _finish, _id, payload|
    if payload[:sql] =~ /^SELECT|UPDATE|INSERT/ && !payload[:cached]
      queries << payload[:sql]
    end
  } 
  ActiveSupport::Notifications.subscribed(callback, "sql.active_record", &block)
  queries
ensure
  ApplicationRecord.connection.disable_query_cache! unless query_cache_enabled
  message = "#{queries.size} expected to be less or equal to #{max}."
  assert queries.size <= max, message
end

Debaixo dos panos, uma maneira é:

Ok, os testes estão passando! Hora de enviar, implantar e... monitorar

O monitoramento padrão de requisições HTTP não é suficiente...

  • As coisas podem melhorar com um log mais estruturado
     
  • Útil para integrar com outras ferramentas de alerta (Uptime, etc.)

Sabemos quanto tempo as requisições HTTP GraphQL estão levando, mas quanto tempo a consulta GraphQL realmente leva?

OpenTelemetry / Honeycomb

Ótimo! Agora podemos ver quanto tempo cada etapa da GraphQL realmente leva... mas quais campos?

Apollo GraphQL Studio

Apollo GraphQL Studio

Apollo GraphQL Studio

Outras ferramentas

  • Grafana
  • Stellate
  • Hasura
  • ...

Agora que podemos rastrear e monitorar requisições GraphQL,  como realmente melhorá-las ?

Evitar Consultas N+1

query {
  posts(first: 5) {
    id
    author {
      name
    }
  }
}
Post Load (0.9ms)  SELECT "posts".* FROM "posts"
User Load (0.3ms)  SELECT  "users".* FROM "users" WHERE "users"."id" = $1 LIMIT $2  [["id", 1], ["LIMIT", 1]]
User Load (0.3ms)  SELECT  "users".* FROM "users" WHERE "users"."id" = $1 LIMIT $2  [["id", 2], ["LIMIT", 1]]
User Load (0.3ms)  SELECT  "users".* FROM "users" WHERE "users"."id" = $1 LIMIT $2  [["id", 3], ["LIMIT", 1]]
User Load (0.3ms)  SELECT  "users".* FROM "users" WHERE "users"."id" = $1 LIMIT $2  [["id", 4], ["LIMIT", 1]]
User Load (0.3ms)  SELECT  "users".* FROM "users" WHERE "users"."id" = $1 LIMIT $2  [["id", 5], ["LIMIT", 1]]
class User < ApplicationRecord
  has_many :posts
end

class Post < ApplicationRecord
  belongs_to :user
  has_many :tags
end

Em um endpoint REST, você normalmente preveria retornar tanto posts quanto seus autores, sugerindo eager-loading na sua consulta. No entanto, como não podemos antecipar o que o cliente solicitará aqui, não podemos sempre pré-carregar os dados.

graphql-batch

# app/graphql/types/post_type.rb
field :author, Types::UserType do
  resolve -> (post, _args, _context) {
    RecordLoader.for(User).load(post.user_id)
  }
end
Post Load (0.5ms)  SELECT  "posts".* FROM "posts" ORDER BY "posts"."id" DESC LIMIT $1  [["LIMIT", 5]]
User Load (0.4ms)  SELECT "users".* FROM "users" WHERE "users"."id" IN (1, 2, 3, 4, 5)

BatchLoader pode ser usado também.

Isso funciona bem para relacionamentos 1-para-1, mas e quanto a 1-para-muitos?

graphql-preload

# app/graphql/types/post_type.rb
field :tags, !types[Types::TagType] do
  preload :tags
  resolve -> (post, _args, _ctx) { post.tags }
end

Mas ainda assim, pode haver problemas de performance ao lidar com consultas mais complexas... E se pudéssemos prever dados consultados com precisão e criar um hash dinâmico para pré-carregar associações?

graphql: lookahead

field :users, [Types::UserType], null: false, extras: [:lookahead]

def users(lookahead:)
  # Do something with lookahead
end
query
└── users
    ├── id
    ├── name
    └── posts
        ├── id
        └── title

O objeto lookahead é como uma estrutura de árvore que representa as informações que você precisa para otimizar sua consulta. Na prática, é muito mais complicado do que isso.

Evite consultas complexas

query {
  teams(first: 1000) {
    users(first: 1000) {
      name
      posts(first: 1000) {
        tags(first: 1000) {
          tag_name
        }
        author {
          posts(first: 1000) {
            title
          }
        }
      }
    }
  }
}
  • Consultas podem facilmente se tornar muito aninhadas, muito profundas e até circulares

graphql: max_depth

# app/graphql/your_schema.rb
YourSchema = GraphQL::Schema.define do
  max_depth 4 # adjust as required
  use GraphQL::Batch
  enable_preloading
  mutation(Types::MutationType)
  query(Types::QueryType)
end

Aplicando timeouts

# Added to the bottom of app/graphql/your_schema.rb
YourSchema.middleware <<
  GraphQL::Schema::TimeoutMiddleware.new(max_seconds: 5) do |e, q|
    Rails.logger.info("GraphQL Timeout: #{q.query_string}")
  end

Cache de fragmentos

class PostType < BaseObject
  field :id, ID, null: false
  field :title, String, null: false, cache_fragment: true
end
class QueryType < BaseObject
  field :post, PostType, null: true do
    argument :id, ID, required: true
  end

  def post(id:)
    last_updated_at = Post.select(:updated_at).find_by(id: id)&.updated_at
    cache_fragment(last_updated_at, expires_in: 5.minutes) { Post.find(id) }
  end
end

Nossa própria abordagem para cache de campos para campos de alta demanda (baseados em eventos, meta-programação)

# app/models/media_rb
cached_field :last_seen,
  start_as: proc { |media| media.created_at },
  update_es: true,
  expires_in: 1.hour,
  update_on: [
    {   
      model: TiplineRequest,
      if: proc { |request| request.associated_type == 'Media' },
      affected_ids: proc { |request| request.associated.medias },
      events: {
        create: proc { |request| request.created_at },
      }   
    },  
    {   
      model: Relationship,
      if: proc { |relationship| relationship.is_confirmed? },
      affected_ids: proc { |relationship| relationship.parent.medias },
      events: {
        save: proc { |relationship| relationship.created_at },
        destroy: :recalculate
      }   
    }   
  ]

Até aqui, vimos consultas únicas...

Mas o que acontece se muitas consultas forem enviadas ao mesmo tempo?

Por exemplo, o agrupamento de consultas do cliente Apollo ou até mesmo Relay do React:

Então, o backend é capaz de processá-las de forma concorrente

# Prepare the context for each query:
context = {
  current_user: current_user,
}

# Prepare the query options:
queries = [
  {
   query: "query postsList { posts { title } }",
   variables: {},
   operation_name: 'postsList',
   context: context,
 },
 {
   query: "query latestPosts ($num: Int) { posts(last: $num) }",
   variables: { num: 3 },
   operation_name: 'latestsPosts',
   context: context,
 }
]

# Execute concurrently
results = YourSchema.multiplex(queries)

Multiplex:

  • Economiza tempo com autorização e sobrecarga HTTP
  • Quando habilitado, até mesmo uma única consulta é executada dessa forma (então, "multiplex de um")
  • Execuções de multiplex têm seu próprio contexto, analisadores e instrumentação
  • Cada consulta é validada e analisada independentemente. O array de resultados pode incluir uma mistura de resultados bem-sucedidos e resultados falhos.
  • Novamente, o monitoramento é importante para ter certeza de que uma consulta específica não está atrasando as outras

Isso é bastante para consultas GraphQL, e quanto às mutações?

Algumas dicas rápidas para isso:

  • Trabalhos em segundo plano (Sidekiq, SQS, etc.)
     
  • Operações em massa (INSERT de múltiplos registros, etc.)

Conclusão:

"Com grandes sistemas vem grande responsabilidade"

Não, sério, conclusão:

  • Priorize a otimização de desempenho para melhorar a experiência do usuário e a escalabilidade da aplicação.

  • Identifique e Resolva Gargalos: Monitore sua aplicação regularmente para identificar gargalos de desempenho, focando em consultas de banco de dados, execução de código e otimização de consultas GraphQL/web.

  • A otimização é um processo contínuo: A otimização de desempenho não é uma tarefa única; é um processo contínuo que requer monitoramento, análise e melhoria constantes.

Obrigado! :)

https://ca.ios.ba

@caiosba

Desempenho em aplicações web que utilizam GraphQL (mas não somente)

By Caio Sacramento

Made with Slides.com

Desempenho em aplicações web que utilizam GraphQL (mas não somente)

  • 34

More from Caio Sacramento