Feda /dev/ - No Javascript allowed

el problema de los backenders es que son tan buenos que su trabajo ya queda para lo posteridad y no hace falta hacer mantenimientos ni evolutivos

Pregunta de system design. Justifiquen su respuesta.

Que es mejor y porque. Control de versiones.

Imaginaos que teneis 2 modelos de machine learning, cada entrada requiere un esquema distinto.

• Opcion A ) tener un endpoint para cada modelo, api/v1/a y api/v1/b o si fuesen versiones distintas api/v1/a y api/v2/a

• Opcion B ) tener un unico endpoint y pasar como metadato la version del algoritmo dentro del esquema. si se requieren mas campos este field idAlgorithm se usaria para se/deserializar correctamente.

{
  idAlgorithm: "a"
...
}

{
  idAlgorithm: "b" // o "a-v2"
...
}

La A o la B???

Si todo el mundo aplicase YAGNI y KISS, viviríamos en un mundo mejor.

El b se usa y mucho, pero para no romper apis publicas. pero tambien se usa mucho porque esta el codigo mal, sobretodo en frameworks.

para mi entra en juego el data flow, la programacion funcional / side effects (metadatos modifican comportamiento) y el flujo de resolucion de dependencias en runtime.

Imagina el problema es que escribes un framework exponiendo unas funcionalidades y normalmente siguiendo un data flow invertido. (debido a usar patrones OOP). estos patrones en primera instancia hacen tu codigo muy atractivo y parecen muy faciles de usar. correcto. son faciles tambien de "modificar" correcto. problema? que no quieres modificar su comportamiento... normalmente queremos cambiar su signatura y sus funcionalidades re usando el maximo codigo posible.

si en lugar de usar un framework en este estilo, expones una serie de librerias con un data flow no invertido. puedes a;adir mas componentes sin problemas. pero para el usuario final requiere "mas trabajo". ya no hay magia negra como hace spring, si no que tienes que picarte un minimo de codigo para que todo este pegado y funcione.

bottom up vs top down design.

a nivel de API no veo ninguna justificacion a no usar los endpoints, por el mismo punto, a nivel modular o de sistemas podemos seguir un razonamiento de FP.

si llamo a /api/v1/a con un input, estoy siguiendo un input y un data flow lineal, una pipeline tonta y funcional que siempre hara lo mismo.
si en cambio envio metadatos a un endpoint para elegir el servicio/modelo/funcionalidad a invocar, estoy delegando la responsabilidad de resolver ese comportamiento al controller, he invertido el flujo de dependencias (1) y ademas estoy a;adiendo side effects (2), mi endpoint ya no es puro.

#25188 si claro puede ser distinto.

en el a puedes tener /api/v1/a que acepta InputA y devuelve outputA
ademas de tener /api/v2/a que acepta InputAv2 y devuelve outputAv2

en el b puedes tener un solo endpoint, pero tienes lo mismo InputGeneric y OutputGeneric. Y dentro de estos jsons segun un campo tener una estructura u otra.

nse yo creo que deberias tener muchos endpoints y muchos tipos. el DRY como dicen de tener solo un endpoint y que tenga esta complejidad a;adida, no usar la capa de HTTP al 100% y otros problemas no justifican.

otro tema es que tengas esta API publica que usan cientos de clientes y no puedes romper. o tengas un framework como spring o algo de data science que tambien funcionan como en el b inyectando metadatos.

la API publica creo que te la comes con papas.

el tema de framework es porque esta mal dise;ado, si no hubiesen hecho un framework y hubiesen hecho una libreria no tendrian este problema. problema? api mas compleja, el usuario tiene que escribir mas.

#25190 los archivos utils se deben

1) no usar bien los modulos/funciones, abusar de OOP usando metodos en lugar de escribir funciones
2) no tener function extensions (esto es un parche sobre la asquerosa OOP de mierdaaaaaaaaaa)
3) no usar bien el sistema de tipado y hacer type driven

normalmente es una combinacion de los 3 porque esto se suele ver en javas, python y demas lenguajes de mierda.

#25189 pues empieza por ahí xd si no es lo mismo por qué ibas a meterlo en el mismo sitio? Da igual que "se use para lo mismo" si no usa las mismas estructuras no tiene nada que ver uno con lo otro.

Yo estaba pensando en algo del palo a tengo un contrato y en runtime decido qué implementación necesito en base a unos datos/queries/lógica/loquesea.

#25198 Siempre existe un tradeoff depende del lenguaje en que estes.

Si tienes un lenguaje fuertemente tipado y de calidad pudes hacer type driven. Si por ejemplo tienes una String name, y quieres tener un type Name = String y expandirlo, esto es muy facil. La clave es que tengas inferencia de tipado para no tener que hacer wrapping a mano o anotar todo a mano como en java o kotlin.

Si no tienes una inferencia real tendras que wrapear todo con tu Name("my name") y es bastante palo.

Si no puedes hacer esto, lo suyo seria tener funciones dentro de tus modulos. si estas en python y tienes un modulo http-client que realiza conexiones http y tiene un cliente, ahi dentro pones utilidades y las escribes como funciones.

si en cambio estas en java, tienes el problema de que todo es un objeto, podrias tener la misma idea y tener un HttpClient y metodos estaticos, pero aqui suele haber muchisima verbosidad. al final puedes tener lo mismo que en python pero sera un poco mas verboso y tendras que vigilar mas con las referencias a tus objetos.

al final lo unico que quieres es

"my name".valide_is_right_name()

o

valide(Name("my name"))

y que sea type safe en compile y runtime

y esto puedes hacerlo con extensiones como te da kotlin u otros del estilo.
teniendo que "my name" es del tipo Name y escribir ahi el metodo.
o tener una funcion del estilo

Validator.validate_is_right_name("my name")

pero como ves, esto ultimo al final, es el principio del fin.
xq estas clases estaticas al no poder desacoplar bien los tipos de su comportamiento en java y similares.
terminan en clases dios. aka utils.java

yo lo tengo en mis modulos/clases como funciones estaticas, y si tengo que pasar una referencia nunca lo hago como metodo, lo hago como funcion aunque parezca redundante.