Sí. Seguro.
Es importante conocer el SQL real que hace el trabajo por usted
Aunque hemos estado viviendo en el mundo de las ORM y las bibliotecas que encapsulan las consultas SQL subyacentes que se forman cuando interactúa con un RDBMS.
- ¿Puedes explicar en términos simples el back-end de aplicaciones como Facebook, Instagram o Snapchat?
- ¿Cuál es la mejor manera de asegurarle al usuario que el código que se ejecuta en el backend es el mismo que se anunció?
- ¿Cuáles son las diferencias entre un rol de PM de front-end y un rol de PM de back-end?
- ¿Qué es un lenguaje de fondo?
- ¿Es node.js la razón por la que vemos una disminución en otros idiomas de back-end?
En la superficie, consultar la base de datos con el SQL generado parece sencillo, pero a menudo nos perdemos una posible optimización y deberíamos estar en condiciones de decir las deficiencias del ORM que se está utilizando.
Durante mucho tiempo, antes de darse cuenta de este cuello de botella, los marcos web populares como Rails y Django solían enviar ORM que encapsulaban las interacciones de DB del usuario, lo que facilitó a un ingeniero promedio el desarrollo del lado del servidor.
Habilitar las interacciones a través de las API REST fue una cuestión de pocos golpes de tecla.
Sin embargo, hay momentos en que estos ORM no generan SQL optimizado y los usamos en todas partes sin pensar que son solo nuestras consultas las que están ralentizando el sistema.
Un ejemplo clásico
Una tabla de Alumno se asignaría directamente a un recurso de Alumno. Habilitar CRUD y agregar algunas configuraciones fue pan comido.
pero digamos que quería hacer API ligeramente complicadas.
Querías buscar estudiantes y debajo de cada estudiante querías información anidada sobre su escuela.
La mayoría de los ORM consultarían la base de datos por alumno y buscarían los detalles de su escuela y luego generarían el resultado combinado.
Uno no se daría cuenta de esto si la aplicación hasta que la aplicación se vuelve viral y recibe muchos éxitos, los nodos desaparecerían en poco tiempo y vería que las solicitudes caducan con bastante frecuencia.
Esto se puede optimizar fácilmente obteniendo los detalles de los estudiantes de una vez y luego obteniendo los detalles de las escuelas de esos estudiantes en una segunda visita y luego combinando los resultados en código para generar el resultado.
Claro … Por ahora, tanto Django como Rails han optimizado sus ORM para tales casos de uso, pero puede haber más casos en los que uno debería estar en condiciones de decir cuál es el cuello de botella y qué está causando problemas.
Y eso es lo que separa a los ingenieros promedio de los que pueden mirar más allá de lo que el marco hace por ellos.
Y no solo se limita a MySQL y Postgres.
Incluso si está interactuando con MongoDB / Redis o, para el caso, ElasticSearch, debe saber qué está haciendo la biblioteca y estar al tanto de los posibles errores y fallas.
