firebase - pricing - graphql gcp

Firebase y GraphQL?

Question

¿Alguien tiene experiencia con el uso de los dos juntos?

Me imagino que uno colocaría las llamadas de Firebase en el resolutor del campo relevante, pasando algunas variables de los accesorios de los componentes a los argumentos de la consulta.

¡Háganos saber lo que piensas!

Answer 1

¿Tienes que usar firebase? Hay servicios más específicos para GraphQL que pueden ofrecer lo que está buscando. https://scaphold.io es una YC Fellowship Company que parece particularmente prometedora y le brinda una experiencia similar a la de Firebase, pero está impulsada por GraphQL.

Answer 2

Para responder a su pregunta, hay tres formas de lidiar con esto.

1. Firebase y GraphQL

Si está configurado para usar Firebase, puede hacer un mapeo uno a uno de la API de Firebase en consultas y mutaciones GraphQL.

Seguramente puede envolver la API de Firebase en los solucionadores de GraphQL y realizar llamadas de esa manera. Este es un buen ejemplo de eso :

const ref = path => firebase.database().ref(path)
const getValue = path => ref(path).once(''value'')
const mapSnapshotToEntities = snapshot => snapshot.val().map((value, id) => ({ id, ...value }))
const getEntities = path => getValue(path).then(mapSnapshotToEntities)

const resolvers = {
    Author: {
        posts(author) {
            return getEntities(''posts'').then(posts => filter(posts, { authorId: author.id }))
        },
    },

    Post: {
        author(post) {
            return getEntities(''authors'').then(posts => filter(authors, { id: authorId }))
        },
    },
};

Esencialmente, lo que está haciendo aquí es usar Firebase como una base de datos, que funciona hasta que desee consultar sus datos de manera relacional en sus resolvers . Sin la capacidad de realizar uniones en el lado del servidor en la parte superior de su almacén de datos, realizará toneladas de solicitudes de ida y vuelta a Firebase en sus resoluciones para cumplir con una sola solicitud.

La razón por la que la mayoría de las personas usa Firebase es por sus capacidades en tiempo real, y no principalmente como un almacén de datos, ya que las herramientas de modelado relacional de datos en este aspecto son bastante insuficientes. Con eso, probablemente sea mejor migrar a GraphQL utilizando una fuente de datos diferente.

2. GraphQL Backend como servicio

Teniendo en cuenta que está abierto a usar productos BaaS como Firebase, podría considerar cambiar a una BaaS GraphQL.

3. GraphQL autohospedado

Si está abierto a cambiar a una solución autohospedada utilizando su propio almacén de datos, también hay muchos beneficios. Aquí hay algunos grandes bateadores:

• Flexibilidad de usar su propio almacén de datos y quizás múltiples para satisfacer las necesidades específicas de su aplicación

• Consultas personalizadas y mutaciones

• Agregue de forma nativa lógica personalizada en lugar de a través de microservicios conectados a webhooks en su API

• Roll sus propios mecanismos de autenticación y permisos

• Probablemente una solución de menor costo

Answer 3

Estoy totalmente en desacuerdo con algunas recomendaciones aquí. GraphQL se puede usar de forma relacional, pero también se puede usar de forma no sql. Firebase, con su RTD (Base de datos en tiempo real) y su almacén de incendios, debe modelarse como una base de datos sin sql porque es una base de datos sin sql !, existen inconvenientes para este enfoque:

1. Lectura optimizada:

Como una base de datos no SQL, las colecciones deben modelarse como sus vistas en sus clientes (móviles o web), por lo que cuando realiza una consulta, todo ya está fusionado y no tiene que hacer accesorios calculados en el cliente ni firebase funciones Este enfoque hace que la lectura sea REALMENTE rápida.

2. Escritura no optimizada:

La principal desventaja aquí es que es su responsabilidad actualizar todos los documentos de la base de datos si toca datos relacionados (como actualizar el nombre de usuario, la foto de perfil, etc.). En este caso, debe encontrar todos los documentos en su base de datos (IE: publicaciones, comentarios, etc.) y garantizar la atomicidad. Se recomienda este enfoque si tiene una aplicación que va a tener muchas más operaciones de lectura que operaciones de escritura (como un blog, 7000 lecturas a 1 escritura como ejemplo)

3. Fácil de escalar:

Como sus colecciones no tienen relaciones difíciles con otros documentos, puede tener una colección completa en un solo servidor o dividirla entre muchos de ellos (es por eso que firebase es barato de escalar, como dynamoDB).

GraphQL es solo un lenguaje de consulta, debería facilitarle la consulta de cosas, pero no debería dictar cómo modelar su base de datos, debe dictar cómo modelar su base de datos, sus consultas y mutaciones.

Answer 4

Puede usar graphql y firebase localmente . Todo el trabajo pesado se puede hacer en un trabajador web para evitar bloquear la interfaz de usuario al resolver la solicitud.

Una palabra acerca de los "muchos viajes de ida y vuelta necesarios para resolver la solicitud": si no le importan los datos transferidos, eso no es un gran problema ya que todos los "viajes de ida y vuelta" se fusionan en el mismo marco de socket. Pero si quieres evitar grandes marcos, solo tienes que poner un pequeño dataloader de datos frente a tu base de datos de Firebase.

Para actualizaciones en tiempo real, solo tiene que suscribirse a eventos en tiempo real desde firebase y enviarlos al trabajador web para convertirlos en suscripciones de graphql reales que se puedan resolver a través de su esquema.

Puede encontrar más información sobre este mismo problema en mi publicación mediana: aplicaciones web en tiempo real "solo del lado del cliente" con Firebase, GraphQL y apollo-client 2.0

Espero que ayude !

Answer 5

TL; DR: GraphQL brilla donde Firebase se queda corto. Potente modelado de datos, consultas flexibles y eficientes y la especificación abierta son partes esenciales de GraphQL que faltan con Firebase.

Potente modelado de datos

Firebase ha recibido muchas críticas basadas en su modelado de datos limitado. Básicamente, sus datos están estructurados como un único JSON enorme que establece los mismos datos varias veces. Lo que parece conveniente al principio da como resultado un código de cliente inmanejable cada vez que necesita actualizar datos, ya que debe realizar un seguimiento de todas las referencias a los mismos datos manualmente.

La estructura de datos utilizada en GraphQL, por otro lado, es muy intuitiva y familiar, ya que está modelada como un gráfico. Usando la sintaxis IDL podemos describir fácilmente nuestro modelo de datos, llamado esquema GraphQL. Para una aplicación de Twitter, el esquema podría verse así:

type Tweet {
  id: ID!
  title: String!
  author: User! @relation(name: "Tweets")
}

type User {
  id: ID!
  name: String!
  tweets: [Tweet!]! @relation(name: "Tweets")
}

Aquí definimos dos tipos de Tweet y User con algunas propiedades escalares y también una relación de uno a muchos entre User y Tweet . Los elementos de datos individuales se denominan nodos, y un nodo de usuario se puede conectar a muchos nodos de tweet. Esta estructura de datos es simple y flexible, aparte del enfoque JSON de Firebase.

Consultas flexibles y eficientes

La capacidad de consulta flexible de GraphQL es uno de sus principales beneficios. Las consultas son jerárquicas, lo que significa que puede especificar los requisitos de datos que reflejan la estructura del gráfico. En nuestro ejemplo de Twitter, podríamos tener una consulta para buscar todos los usuarios y sus tweets:

query {
  allUsers {
    id
    name
    tweets {
      title
    }
  }
}

Tenga en cuenta que podemos incluir o excluir libremente los campos que queremos consultar, e incluso podemos consultar entre relaciones. Esto significa que no necesitamos hacer múltiples consultas ni estamos consultando datos innecesarios, lo que hace que las consultas GraphQL sean extremadamente eficientes.

Al agregar argumentos de consulta a la mezcla, podemos agregar características como un orden personalizado o filtros para obtener una potente API GraphQL .

Todo eso simplemente no es posible con Firebase.

Datos en tiempo real

Las capacidades en tiempo real de Firebase lo han hecho tan popular, pero dado que la comunidad GraphQL está a punto de llegar a un consenso con respecto al tiempo real , la mayor ventaja de Firebase también se anula. Recomiendo este video tutorial sobre suscripciones GraphQL para comprender mejor los conceptos subyacentes.

Conclusión

Entonces, para responder a su pregunta: GraphQL supera a Firebases en la mayoría de los aspectos, por lo que es la opción preferida.

Si está interesado en GraphQL, le recomiendo que consulte Graphcool, que combina las fortalezas de GraphQL con potentes funciones como la autenticación integrada y los enganches flexibles para AWS Lambda u otras funciones sin servidor para implementar una lógica empresarial personalizada.

Descargo de responsabilidad: trabajo en Graphcool :)