Consultas e mutações GraphQL em versões de Parse distintas

À medida que o Parse evolui com o tempo, alguns de seus aspectos mudam para melhorar o desempenho, a compatibilidade e facilitar o desenvolvimento.
Um desses aspectos é o suporte ao GraphQL, que evoluiu do Parse 3.5.0 ao longo do tempo para a versão mais recente disponível, a 3.9.

Aqui na Back4app, temos três versões principais que implementam alterações nas consultas e mutações GraphQL, especificamente: 3.7.2, 3.8 e 3.9 e, hoje, vou orientá-lo sobre as diferenças entre essas versões, mostrando o que mudou e o que não mudou.

Introdução

A evolução é obrigatória quando se implementa soluções de longo prazo para os clientes, e o Parse não é exceção.

À medida que os padrões GraphQL começaram a se tornar mais populares e usados, a comunidade exigiu melhor integração, uso simplificado e intuitividade. E como mantenedores e colaboradores ativos do Parse, a Back4app ouviu essas vozes e se esforçou muito para alcançar esses resultados na plataforma de código aberto Parse.

Nossos desenvolvedores trouxeram novas funcionalidades ao longo do tempo, como a integração com o Cloud Code, mas a comunidade continuou pedindo uma sintaxe GraphQL mais consistente em relação a estruturas e plataformas e, com o Parse 3.9, conseguimos isso e o entregamos à comunidade para que ela se beneficiasse.

Enquanto essa sintaxe evoluía, algumas mudanças importantes foram feitas, portanto, dependendo da versão do Parse que você usa, é preciso escolher a sintaxe correta para ela: 3.7.2, 3.8 e 3.9 têm sintaxes ligeiramente diferentes para obter os mesmos resultados.
Por esse motivo, estou escrevendo este artigo para que você tenha tudo documentado em um só lugar e, enquanto faço isso, recomendo enfaticamente que os usuários atualizem seu Parse para a versão 3.9, juntamente com a nova sintaxe, nossa versão mais compatível com a sintaxe de várias plataformas e estruturas até o momento.

Abaixo, mostrarei alguns exemplos.

Saúde da API

A consulta de integridade da API não mudou entre as versões, e você pode chamá-la de forma consistente consultando:

o que resultará na mesma resposta entre as versões:

Criação de um objeto

A mutação para a criação de um objeto foi alterada ao longo do tempo para ser mais consistente entre as diferentes estruturas GraphQL e incluir alterações significativas que você deve considerar antes de alterar a versão do Pare.

Uso de uma mutação genérica

No Parse 3.7.2, você poderia simplesmente solicitar a criação de um objeto e uma classe seria automaticamente criada para você:

No Parse 3.8, há uma pequena alteração, pois a consulta de objetos foi removida, mas você ainda pode solicitar a criação de um objeto e a classe será criada automaticamente:

No entanto, no Parse 3.9, você deve primeiro criar sua classe, adicionando explicitamente seus campos:

e só então poderá salvar um objeto usando seu método específico (abaixo).

Uso de um método específico (mutação de classe)

Os métodos específicos (métodos de classe, neste caso, uma mutação de classe) também mudaram:

No Parse 3.7.2, eram:

No Parse 3.8, a propriedade objects foi removida:

E, finalmente, no Parse 3.9, o ObjectId foi renomeado para id, para que pudesse estar em conformidade com os padrões:

Obtenção de um objeto

A recuperação de objetos também evoluiu com o tempo para melhorar a consistência e a compatibilidade.

Uso de uma consulta genérica

Você poderia especificar o nome da classe e o ID do objeto para recuperar um objeto específico, usando o método GET genérico, que funcionaria para qualquer classe.

Parse 3.7.2:

Posteriormente, o Parse 3.8 removeu os objetos, permitindo uma chamada mais simples:

Parse 3.8:

Com a chegada do Parse 3.9, o método genérico GET foi removido e você deve usar o método específico da classe para recuperar objetos (mais sobre isso abaixo).

Uso de um método específico (Class Query)

Os métodos específicos também mudaram de acordo com a versão do Parse.

No Parse 3.7.2, tínhamos:

Posteriormente, no Parse 3.8, também removemos a propriedade objects para facilitar a chamada:

E no Parse 3.9, o objectId foi substituído por id para melhorar a consistência entre as estruturas:

Localização de um objeto

A localização de objetos também evoluiu com o tempo para melhorar a consistência e a compatibilidade.

Uso de uma consulta genérica

Você poderia especificar o nome da classe para recuperar uma lista de objetos, usando o método FIND genérico, que funcionaria para qualquer classe.

Parse 3.7.2:

Posteriormente, o Parse 3.8 removeu os objetos, permitindo uma chamada mais simples:

Parse 3.8:

Com a chegada do Parse 3.9, o método genérico FIND foi removido e você deve usar o método específico da classe para recuperar objetos (mais sobre isso abaixo).

Uso de um método específico (Class Query)

Os métodos específicos também mudaram de acordo com a versão do Parse.

No Parse 3.7.2, tínhamos:

Posteriormente, no Parse 3.8, também removemos a propriedade objects para facilitar a chamada:

E no Parse 3.9, o objectId foi substituído por id para melhorar a consistência entre as estruturas:

Atualização de um objeto

A atualização de objetos também teve de ser alterada para melhorar a consistência e a compatibilidade.

Uso de uma consulta genérica

Você pode especificar o nome da classe e o ObjectID para atualizar um objeto, usando o método UPDATE genérico, que funcionaria para qualquer classe.

Parse 3.7.2:

Posteriormente, o Parse 3.8 removeu os objetos, permitindo uma chamada mais simples:

Parse 3.8:

Com a chegada do Parse 3.9, o método genérico UPDATE foi removido e você deve usar o método específico da classe para recuperar objetos (mais sobre isso abaixo).

Uso de um método específico (Class Query)

Os métodos específicos também mudaram de acordo com a versão do Parse.

No Parse 3.7.2, tínhamos:

Posteriormente, no Parse 3.8, também removemos a propriedade objects para facilitar a chamada:

E no Parse 3.9 a chamada foi mantida semelhante à do 3.8, mas o objectId foi renomeado para id na chamada:

Métodos de aplicativos

Os métodos de aplicativos tiveram de acompanhar as mudanças e se adequar aos novos padrões. As consultas e mutações específicas do aplicativo também foram alteradas.

Inscrição de um usuário

O registro de novos usuários seguiu o protocolo ao longo do tempo e foi ajustado de acordo:

Parse 3.7.2:

Posteriormente, o Parse 3.8 manteve a chamada:

Parse 3.8:

Com a chegada do Parse 3.9, a propriedade objectId mudou para id para ficar em conformidade:

Registro em um usuário

O login de um usuário foi alterado da mesma forma:

Parse 3.7.2:

Posteriormente, o Parse 3.8 manteve a chamada:

Parse 3.8:

Com a chegada do Parse 3.9, a propriedade objectId mudou para id para ficar em conformidade:

Obtenção de um usuário conectado

A recuperação de informações sobre um usuário conectado também teve que mudar. Ainda é necessário passar o cabeçalho “X-Parse-Session-Token” junto com um Session Token válido para esse usuário, mas a consulta em si foi alterada:

Parse 3.7.2:

Posteriormente, o Parse 3.8 alterou a consulta ME para o novo formato VIEWER:

Parse 3.8:

Com a chegada do Parse 3.9, a propriedade objectId mudou para id para ficar em conformidade. Se você não precisar dela, a sintaxe é a mesma da versão 3.8:

Conclusão

Com a evolução do Parse e de outras plataformas e formatos ao longo do tempo, era natural que o Parse continuasse mudando para simplificar o desenvolvimento e manter a consistência e a interoperabilidade.

À medida que surgiam novos padrões, o Parse tinha de aplicar mudanças para não diferir dos principais componentes aos quais se integrava.

Como um ávido usuário do Parse, eu mesmo esperaria mais algumas mudanças ao longo do tempo. Boas mudanças. Mudanças que façam sentido e permitam que todos alcancem seus objetivos.

Nós, da Back4app, estamos orgulhosos de ter ajudado nessa evolução e aconselhamos todos os usuários do GraphQL a atualizar o Parse para a versão 3.9, juntamente com suas consultas e mutações GraphQL. Você se beneficiará de uma linguagem de consulta muito mais consistente.

A versão 4.0 está no forno. O que ela trará?