¿Qué es más rápido? ¿Usando REST API o consultando una base de datos directamente?

Cuando agrega complejidad, el código se ejecutará más lentamente. La introducción de un servicio REST, si no es necesario, ralentizará la ejecución, ya que el sistema está haciendo más.

Resumir la base de datos es una buena práctica. Si le preocupa la velocidad, puede buscar el almacenamiento en caché de los datos en la memoria para que no sea necesario tocar la base de datos para manejar la solicitud.

Antes de optimizar el rendimiento, aunque analice qué problema intenta solucionar y la arquitectura que está utilizando, me cuesta pensar en una situación en la que las opciones de la base de datos sean de acceso directo frente a REST.

Si su preocupación es la velocidad, entonces sí, un servicio de Descanso será más lento por las razones expuestas anteriormente. Sin embargo, la velocidad del tipo que describe rara vez es la principal preocupación y, si lo es, puede abordarse de otras maneras. La optimización prematura es la raíz de todos los males .

Considere si su principal preocupación es la interoperabilidad (móvil, web, B2B), ahora REST es muy atractivo porque es agnóstico en tecnología.

Supongamos que usted codifica para una base de datos. ¿Qué haría si elige cambiar su almacén de datos subyacente? ¿Qué tan difícil sería hacerlo si está estrechamente vinculado a la tienda subyacente?

La respuesta real es depende , ¡pero espero que te haya dado algunas cosas en las que pensar!

Si le resulta difícil responder a esta pregunta.

La respuesta general correcta debe ser: depende.

  

La forma en que lo veo con REST:

     

1. Crea un objeto en su código para llamar al método REST
  
2. método http http
  
3. El código dentro de su API REST consulta la base de datos
  
4. La base de datos devuelve algunos datos
  
5. El código de la API REST empaqueta los datos en Json y los envía a su cliente
  
6. El cliente recibe una respuesta Json / XML
  
7. Asignar respuesta a un objeto en su código
  

Hay un error en tu pensamiento.

Y este error se deriva del hecho de que no entiende completamente a REST y sus principios. REST no se inventó, porque a algunos nerds les pareció genial (por supuesto que lo es) enviar objetos Javascript a través de HTTP. La principal ventaja de usar HTTP es la posibilidad de usar Caching . Si hace que sus resultados sean cacheables , entonces hay menos solicitudes para hacer a la base de datos. Y no hay ordenación involucrada. La respuesta podría ser entregada directamente.

En la medida en que @Klees la respuesta es no del todo bien :

  

Cuando agrega complejidad, el código se ejecutará más lentamente. La introducción de un servicio REST, si no es necesario, ralentizará la ejecución, ya que el sistema está haciendo más.

Cuando se trata de resultados cacheables, no hay impacto en su aplicación: la entrega de respuestas conocidas a preguntas conocidas podría hacerse a través de proxies inversos.

La introducción de un nivel de servicio adicional siempre tiene un costo en complejidad y sobrecarga de rendimiento. Existen algunos tipos específicos de arquitectura en los que la introducción de un nivel de servicio compartido (como una API REST) puede mejorar el rendimiento debido al almacenamiento en caché compartido, pero parece que no es el tipo de arquitectura que tiene.

Considere una arquitectura donde tenga múltiples aplicaciones web o múltiples aplicaciones de escritorio conectándose directamente a la misma base de datos. Si realizan las mismas consultas a menudo, puede mejorar el rendimiento para almacenar en caché los resultados de las consultas en un servicio compartido. Especialmente si tiene cientos de aplicaciones de escritorio que acceden directamente a la misma base de datos (¡no a través de una aplicación web!) Y realizan las mismas consultas, podría haber una gran mejora. Sin embargo, incluso en esta arquitectura, la razón principal para introducir un servicio compartido probablemente sea la seguridad y la abstracción de datos en lugar del rendimiento.

Pero parece que tienes una sola aplicación web que se conecta a la base de datos directamente. En ese caso, no es beneficioso introducir una capa de servicio adicional. El almacenamiento en caché, la abstracción de la base de datos, etc., podrían manejarse en la capa de acceso a datos en la misma aplicación.

Depende.

Obviamente, mientras más capas haya en tu código, más lento irá. Pero ... llega un punto en el que el rendimiento directo de extremo a extremo no importa tanto como la escalabilidad. Si tiene 1 usuario que accede a su base de datos en una PC local, puede ir rápido. Si tienes mil usuarios que acceden a la misma base de datos en la misma PC, es probable que los veas a todos frustrados. La solución es mover la base de datos a otra casilla, agregar una capa en el medio y aunque para 1 usuario, funcionará más lento, cuando los mil accedan a ella, irá más rápido. (Esa es una respuesta simplista pero verdadera en principio).

Hay otras razones para ocultar su base de datos detrás de un nivel intermedio, como la seguridad.

No sé dónde te pierdes, pero está bastante claro: cuando estás usando la API REST, estás haciendo un paso adicional, y el paso adicional "siempre" significa más lento cuando se involucra la programación.

Hay ventajas y desventajas, pero si puede acceder a la base de datos directamente desde su aplicación, siempre es mejor llamarla directamente en lugar de usar la API web. Por supuesto, si usa la API web, puede transferir fácilmente su aplicación a una plataforma diferente.

RESTO:

• abierto a varios frontends y 1 backend
• necesita crear su propia API (o usar una como Loopback)
• no funciona sin conexión

DB local:

• no está abierto a 'niveles', necesitan tener acceso a tu servidor para sincronizar
• no es necesario crear una API, use la interfaz DB
• trabajando fuera de línea

ESTA ES UNA DIFERENCIA MUY GRANDE, LAS PERSONAS A menudo OLVIDAN ESTOS PUNTOS