El problema del chat es que no refleja el tono y los detalles de la comunicación humana. Es fácil mal interpretar intenciones y estados de ánimo. Hay que dejarlo pasar.
Ome, @Yussef, le puse dos puntos pé porque de veras yo acá paso siempre con buena onda. Es igual que el martillo castigador de @gbianchi-enhuelga y esas cosas. No tengo más que hacer que pasarla bien con ustedes acá. Las cosas que yo comente en meta o en las preguntas y respuestas están allá, en las preguntas y respuestas. No me da nada "tener razón" o no tenerla.
Acá seguimos viendo a los mods marchando frente a la fábrica de SE
No osea quisiera que en esa tabla la segunda o primer que es igual las columnas pasen abajo
Las columnas de la tabla de ese componente basen abajo cuando es móvil y destock normal que se muestre todo
@Yussef la tabla de arriba y abajo es el mismo comenté, si no quisiera que en móvil no haga el scrollbar de las columnas de la tabla si no que pasen abajo
No soy experto en REST y lo que más ruido me hace es que la documentación y tutoriales que ví no llegan a plantear algo tan genérico, y me plantee si es un enfoque válido
@Yussef De graphql estuve viendo algunas cosas y me gustó mucho, el tema de este proyecto es transformar una app web local que le pega al servidor de DB por todos lados a una cloud que reemplace las llamadas a la DB por llamadas a una API Rest que mapee los mismos SP que se llaman hoy.
@PatricioMoracho técnicamente no se le ve lío alguno. La cosa es más semántica, los recursos podrían no estar exactamente identificados por un request (porque es genérico), pero posiblemente sí puede ser stateless y sí puede ser cacheable. Los puristas de REST suelen usar mensajes POST con un DTO en el body pa búsquedas complejas y eso...
@PatricioMoracho Quizas tengo que pensar mas el asunto. Pero a priori estas haciendo lo mismo que enviar los datos en un QueryParam, solo que con tu formato. Finalmente uno siempre envía los nombres de los campos con el valor de ellos, se en la url en un form o en el body
@gbianchi-enhuelga Ja ja, si eso el lo primero que pensé, no los SP van a tener que tener cierto formato y firma en los parámetros, cualquier cosa fuera de eso debería se error
@gbianchi-enhuelga tiene /generico/ConsultaProductos/nombre=tornillo y donde ConsultaProductos es tanto el SP a ejecutar y el Action del Controller, basta que el usuario tenga autorización para ese Action
@Alfabravo Eso es justamente es lo que me hacía "ruido", la documentación y tutoriales apuntan a cosas mas puristas y lo que me quiero mandar a hacer sale un poco de eso
@PatricioMoracho pues es que uno trata de que una operación se encargue de operar sobre una entidad ná más. Tener una operación buscarEnBaseDeDatos no es muy atómico, suena a un micromonolito je
@gbianchi-enhuelga Hoy hay una app web que corren en la lan que le pega directo a unos 200 sps, se quiere migrar a la nube, y que en vez de pegarle a esos 200 sps le peguen a una API
tengo un metodo get data... y va a 60 tablas distintas, depende lo que el usuario alla decidido mostrar en pantalla...
@PatricioMoracho eso no es problema.. lo que me hace ruido es ese engendro de rutas
yo lo trivializaria... guarda las guias de cada SP en algun lado... y solo envia un parametro que diga a que SP le queres pegar... con los parametros extra requeridos...
y devolves siempre una estructura de columnas con los headers y las filas...
@Yussef quiero ver como le explicas a C# como parsear esa ruta
@gbianchi-enhuelga Ok, te entiendo, una cosa que no aclaré es que me estoy montando sobre algo que ya está hecho, y los parametros se están pasando así
normalmente exponer algo via una API es una decisión consciente
acá estás por defecto abriendo la base de datos
que puede estar ok hoy, pero dependés que desde hoy hasta la eternidad, quien toque la base de datos sepa cómo se pueden ejecutar los stored procedures. Además, pueden haber stored procedures del motor de la base de datos
por que lo que podrías usarlos para crear usuarios con más privilegios, matar procesos, acceder a más información
@g3rv4 A eso apuntaba, entiendo el punto y estoy de acuerdo. Pero como siempre, el problema son los tiempos que son tiranos, la idea que estaba explorando era básicamente decirle al que consume la API, un proveedor que hizo la aplicación web, que solo tiene que hacer lo mismo que hace hoy llamando a los Sps, solo rehaciendo la llamada a una api y esperando un json como resultados.
@Yussef Hay una especia de firma, o parámetros ocultos que se le pasan a los SP que se invocan de esta manera, cualquier otro va a fallar, pero es cierto, también se puede armar un array de Sp´s válidos
@Yussef Por eso le decía a Patricio hace un rato, esas búsquedas complejas siempre prefieren hacerlas apuntándole a un recurso (una URL) y entregando un DTO (los parámetros) en el body, el JSON de toda la vida
Estoy teniendo problemas a publicar mi proyecto angular 14 en Azure en un app-service.
PROBLEMA:
Al momento de publicar y consultar la url de mi proyecfto me arroja los siguientes errores:
He consultado en diferentes fuentes y siempre sugieren lo mismo, agregar un archivo web.config, lo hice per...
@PatricioMoracho depende de qué tan confidencial sea la información que se maneja... si no manejás PII y tenés backups, puede tener sentido si :)
peor caso: alguien se hace con los datos (no hay problema) o alguien los modifica (y recuperás del backup). Mientras la gente que toma las decisiones entienda los riesgos y esté de acuerdo... siga siga!
@g3rv4 Tengo miedo.... Igualmente me estoy montando sobre algo que ya existe, solo estaría agregando métodos nuevos, con lo cual digamos que arrastro todas las fortalezas o debilidades de lo que ya existe, aunque posiblemente agregue algo más de riesgo por el lado de esta llamada tan genérica.
Retomando la idea de escribir los, digamos, 200 controladores, que se podría automatizar ¿Qué onda un servidor con tantos métodos?
hay muchos factores que pueden determinar que un servidor con 200 endpoints tenga un impacto alto en el rendimiento, entre ellos factores de recursos, factores de optimización del código, factores de complejidad de los endpoints y factores de concurrencia y escalabilidad
vos sabras cual de estos factores tiene mas importancia
@PatricioMoracho te vuelvo a repetir.. yo tengo un endpoint para 80 consultas distintas.. eso no es problema.. a mi lo que no me gusto es tu forma de armar las rutas jajaja
@gbianchi-enhuelga Ok. Te digo una cosa, mi escenario ideal es contar con el tiempo suficiente para estudiar los 200 Sps y construir un API que apunte tal vez a 4 o 5 recursos y que talvez solo tenga solo 20 métodos en total. Veremos.. gracias por las opiniones