Feda /dev/ - No Javascript allowed | Página 1461

smarquezp #43801 Mar '23 Inocente

Si te pones así no se utiliza ningún lenguaje para programar

1 respuesta

pantocreitor #43802 Mar '23

#43801 aquí somos de cobol así que chitón

CaNaRy_r00lz #43803 Mar '23 Inocente

#43795 Tu me quieres joder la vida no? haha no solo tengo Java en el curro, sino c# en el college a parte de tener que lidiar con Jaspersoft

B

[Borrado] #43804 Mar '23

buenos días a todos menos a los pythoneros y a los que se hacen el nudo de la corbata con Notion

1 respuesta

fehnd #43805 Mar '23

#43784 Sorry! allevoy

Las operaciones como comentas son atómicas, pero si van al mismo recurso son dependientes entre ellas y el orden importa

RPV -> Lo que comentas en #43787 es mas o menos lo que quería decir yo, con el tema de que si separas mas de READ/WRITE hay mas retos, pero creo que acabo de pillar realmente lo que comentas y me ha venido a la cabeza tu frase de "hay que pensar a nivel de infra y no de negocio" la cual ahora entiendo más

Un buen viernes se queda

#43796 si el problema no es el GiB de RAM para las 200 req/s (que si, es un problema) es la cantidad de RAM que necesita para estar ahí, en idle, pasando el rato ( aunque con 200 req/s es un poco lo mismo ), y si, eso es un problema de spring boot ( al menos por mi experiencia )

1 respuesta

desu #43806 Mar '23

#43805fehnd:
pero si van al mismo recurso son dependientes entre ellas y el orden importa

Entiendo lo que quiero decir, es un tema interesante. Comentame si me equivoco en algo o asumo algo erronameante.

Asumo que estas pensando en tener una API HTTP RESTful o algo del estilo "puro" y yo no estoy de acuerdo en ese estilo. Para empezar, nadie en el mundo tiene una API restful bien hecha con hyperlinks y demas. No son muy practicas para backend la verdad. Todas las API HTTP del estilo son "restful like", que le suelo decir, donde mantienes ideas de REST pero absolutamente nadie lo lleva a la practica. Y no se lleva a la practica porque es una MIERDA.

Todas las API por HTTP habitualmente (casi 100%) seran algo del estilo RPC o "restful like", donde ambas cada endpoint ira asociado a una funcionalidad o caso de uso de producto. Esto es distinto a tener una API HTTP REST mas pura, donde cada endpoint va asociado a los recursos que gestionas. En mi experiencia una API restful like suele ser algo hibrido entre RPC para casos de uso y CRUDs REST para gestion.

Por ejemplo, en la todo list, al ser un caso muy simple de CRUD de listas se mappea muy facilmente a una REST pero no tiene porque serlo. Supongamos para añadir complejidad que en un futuro, un usuario puede tener multiples lists, y quiere borrar multiples todos de estas listas.

La manera REST seria hacer multiples llamadas para gestionar los recursos, estos recursos pueden ser las list o las todo:

Alternativa:

/DELETE todo_id0, todo_id5, donde el backend se encarga de buscar en que listas estan estos todos y lo gestiona por ti, rpc - restlike

Alternativa:

/DELETE al endpoint /list_0 el todo_id0, rest
/DELETE al endpoint /list_1 el todo_id5, rest

Alternativa:

/PUT /list_0, donde el contenido no contiene el todo_id0, rest
/PUT /list_1, donde el contenido no contiene el todo_id5, rest

Y asi, tendriamos varias alternativas que "logicamente" no son iguales, pero a nivel de "producto" para el usuario si lo son. El objetivo que nosotros tenemos como backends es elegir la mejor. Y si te fijas la primera alternativa bien podria ser una llamada RPC. Y las otras mas rest, pues podriamos debatir cual es la mas fina...

Tendriamos que poner mas condiciones e hipotesis, es este caso de uso muy frecuente? que impacto tiene en el backend a nivel de rendimiento y eficiencia? como vamos de recursos? como tenemos la "arquitectura actual" del backend y como la podemos gestionar para este cambio?

Pero vamos, yo seria partidario de empezar considerando la primera alternativa que puede ser tanto RPC como una HTTP Restlike porque para el usuario es 1 caso de uso, para el backend es 1 transaccion.

Si acoplas el diseño de tu backend a "negocio" como hemos hablado, tendrias algo mas REST, porque cada entidad seria un CRUD con su API, su capa de service y repository que termina mappeand o una DB... Y esto me parece que va a terminar mal.

1 3 respuestas

Farmijo #43807 Mar '23

#43806 Como todo en este mundillo, depende. Cuando empieces, seguro que va bien el concepto de tener vía libre en cuanto acceso/modificación de recursos (según el producto). Cuando la complejidad aumente, seguramente sea más fácil pensar en un estilo endpoint=caso de uso porque no le querrás dejar a un cliente externo gestionar la complejidad de tu sistema y querrás que ambos habléis el mismo idioma para entenderos.
Que ojo, al final es de lo que va DDD.

1 respuesta

JuAn4k4 #43808 Mar '23

#43806 vert.x está bien, yo quería probar activej a ver qué tal iba, básicamente han rehecho todo.

desu #43809 Mar '23

#43807 Completamente de acuerdo contigo mi amijo farmijo.

En eso consiste la serie de backend, que problema les ves al mapeo de endpoint a caso de uso? te pongo uno facil, imagina que un user hijo de puta tiene millones de listas y me hace un delete de cientos de miles de ids... pues eso hay que controlarlo. Mi solucion? No permitir a los users tener tantas listas XD Y si quieren tenerlas? Ponerlas de PAGO.

Pero en eso consiste la serie de backend, en poner casos de uso y simular escenarios y ver que problemas tienen. Evolucionar el sistema y repeat. Si el codigo no funciona? Pues se tira a la basuara y se mete un breaking change.

Farmijo #43810 Mar '23

Y hablando de ordenes que importan y llamadas a apis, muy fan de un fpero que se fue de la empresa hace poco y ha dejado un cacho de código espagueti por aquí que causaba un bug intermitente por algo como:

func ([]Id ids) Organization {
accounts := getAccounts(ids);
profiles:= getProfiles(ids);
....
mergedData := ids.map((id,index)=>{
  name: profiles[index].name
  organizationId: accounts[index].org,
})
......

}

Me cago en mi puta vida, que dolor de cabeza hasta que he visto eso por ahí perdido.

1 respuesta

desu #43811 Mar '23

#43810 cual es el bug? usar index en lugar del id? XD

1 respuesta

Farmijo #43812 Mar '23

#43811 Efectivamente. Contexto: getAccounts y getProfiles llaman a a apis externas que no te aseguran el orden de los datos en la respuesta.

1 respuesta

desu #43813 Mar '23

#43812 yo haria esto, suponiendo que ids son indices validos de 0 a len(ids):

func ([]Id ids) []Organization {
  accounts := getAccounts(ids);
  profiles:= getProfiles(ids);
  mergedData := vec![Organization; len(ids)]

  for id in ids:
    mergedData[id].name = profiles[id].name

  for id in ids:
    mergedData[id].organizationId = accounts[id].org

  return mergedData
}

ademas de ser mas facil de leer, imposible de equivocarte. Asi optimizas la cpu cache, dos bucles iras 10 veces mas rapido que con uno jodiendote la pages y ademas si quieres puedes tirarlo en paralelo.

de hecho te puedo hacer todo en una pipeline streaming si getaccounts y getprofiles devuelven un stream. asi no bloqueas nada. en pseudgo.

func ([]Id ids) []Organization {
  accountsChan := async getAccounts(ids);
  profilesChan := async getProfiles(ids);
  mergedData := vec![Organization; len(ids)]

  async {
  for id in ids:
    mergedData[id].name = profilesChan.get().[id].name
  }

  async {
  for id in ids:
    mergedData[id].organizationId = accountsChan.get().[id].org
  }

 accountsChan.WaitForClose()
 profileChan.WaitForClose() 
 return mergedData
}

1 respuesta

Farmijo #43814 Mar '23

#43813 Hay que crear dos maps antes porque la respuesta de ambas apis es un array y luego la creación de mergedData es algo más compleja que lo que he puesto aquí.
Pero vaya, que la solución es de cajón, no se que ostias hizo el muchacho este usando los indices en primer lugar.

1 respuesta

pantocreitor #43815 Mar '23

#43804 que cojones es notion? una termomix que hace nudos de corbata?

Por cierto, somos la cima del conocimiento tecnológico, que haceís hablando de código a estas horas en vez de estar tomándoos un café en starbucks con vuestro hyperdeportivo aparcado en la puerta?

1 respuesta

B

[Borrado] #43816 Mar '23

#43815pantocreitor:
que cojones es notion?

un bloc de notas para hipsters de tienen un macintosh y desayunan en starbucks

2 1 respuesta

Kaledros #43817 Mar '23

#43816 Dos de tres, los brebajes de Starbucks son una puta mierda.

1

desu #43818 Mar '23

#43814 es una broma farmijo, cuando alguien pone codigo me gusta siempre poner mi version data oriented. la solucion buena.

este truquito se lo enseñe a mitchell hashimoto en una sesion de pair programming.

fehnd #43819 Mar '23

#43806 asumes bien, pero muy bien xD y si, has dado en el clavo

1 respuesta

desu #43820 Mar '23

#43819 Nah, estoy acostumbrado a ver codigo de mierda y gente que no sabe de lo que habla como Miudev.

Hoy por ejemplo. Que cojones singifica que una API es asyncrona?

Que puta porqueria trabajar con fperos a veces eh... Os juro que no puedo.

Porque que una API sea asyncrona significa que se puede hacer peticiones a un endpoint para hacer "resume", "stop", "replay"... Como se explica en el mejor blog de engineering del planeta: https://arnaudiaz.com/blog/what-is-async/ Si tengo un endpoint async, significa que me devuelve un resultado parcial que podria parar la ejecucion y luego esperar en el mismo endpoint el resultado...

Creo que significa lo tipico de eventos que te devuelve un id donde consultar el resultado... y se procesa en background... Pero vamos. Por que la gente usa palabras que no saben que significa?

Google y me encuentro esta mierda: https://www.techtarget.com/whatis/definition/synchronous-asynchronous-API

Mezclando block/non-block con sync/async y api design... madre mia. Que porqueria de contenido.

2 respuestas

MTX_Anubis #43821 Mar '23 :psyduck:

#43741 Te respondo hoy que aye rno pude.

Creo que estamos usando la misma nomenclatura pero hablando de cosas distintas. Cuando yo digo que las decisiones de desarrollo las toma negocio no me refiero a que desde negocio me diga que tengo que hacer 3 servicios para hacer algo que hay que hacer en uno.

Me refiero a que las partes de negocio e ingeniería (o jardinería tecnológica) tienen que estar alineadas y que todo lo que se haga desde la parte de ingeniería es para aportar a negocio. La forma de hacerlo la decide exclusivamente ingeniería (aunque los qu eponen la pasta obviamente tendrán algo que decir) pero tendrá que supeditarse al valor que va a aportar al negocio.

De eso va DDD, no va de empezar a hacer servicios por casos de uso. Va de reunirte con negocio y sobre todo sacar procesos ocultos para hacerlos explícitos y que el software haga lo que se supone que tiene que hacer y se usan BC porque en cualquier negocio medio complejo va a ser casi imposible sacar un solo modelo que englobe todo el negocio y lo haga bien porque un negocio no es más de un conjunto de contextos cada uno con sus procesos y cada uno con sus reglas y un usuario no es lo mismo que un cliente al igual que no lo es lo mismo que un proveedor.

1 respuesta

JuAn4k4 #43822 Mar '23

#43820 Pues creo que es eso mismo que dices, devuelves un accepted con id, y dónde poder hacer las operaciones de parar, resumir, ver el estado, etc. Yo lo he hecho en general para endpoints de exportar datos y tal.
También puede referirse a que sin más, te devuelve accepted y te garantiza cierto nivel de servicio y el endpoint retorna antes de acabar la tarea. Por ejemplo: Envía esta notificación push, el servicio la guarda y se encarga de hacer el handling de forma asíncrona con un QoS=Best effort por ejemplo. Y te permite poner TTLs y demás.

Es lo que entiendo yo

1 respuesta

desu #43823 Mar '23

#43821 entiendo. prefiero mi teoria la verdad. mucho mas facil. 1 producto = 1 equipo.

si un negocio tiene multiples "contextos" entonces es que tienes multiples productos que deben JUSTIFICAR su existencia con ingresos. ingresos que deben estar por encima de los costes. y esto lo puede llevar un nuevo equipo o no dependiendo de la complejidad. añadir un equipo incrementaria los costes...

si yo tengo una todo-list y quiero añadir una funcion de busqueda o algo similar, pues lo primero te dire es cuanto dinero vas a hacer con el feature... como no lo sabemos podemos tirar un mvp y probarlo... si eso no da resultados fuera.

estoy en contra de tener requerimientos por cierto, soy de la escuela de YC como ya sabeis.

timestamp meme de 0:23, hacer surveys a usuarios, a/b testing, tomar requerimientos de negocios... MALA INGENIERIA. Haz un MVP mide el dinero y los costes... es rentable? bien. No lo es? mal.

si estas en una empresa donde esto es lo comun... lo siento. estas en una empresa de POLITICA no de PRODUCTO. o es que estas en un plato donde da bastante igual lo que hagas y seguramente sobras.

#43822 con toda la gente que he hablado de otros equipos y otras empresas. cuando te piden que algo es async, significa que ellos no "quieren bloquear el cliente". Y yo siempre les respondo que eso no tiene nada que ver con el endpoint... para ellos sync = block, async = non-block, y ademas implica esperar o no en el cliente...

hay gente que no entiende que tu puedes hacer un GET al frontend de una imagen, que el endpoint sea sync y NO BLOQUEAR el front end esperando a la imagen...

tambien he visto gente que no gestiona los errores HTTP, asume que siempre sera un 200.

Farmijo #43824 Mar '23

hay gente que no entiende que tu puedes hacer un GET al frontend de una imagen, que el endpoint sea sync y NO BLOQUEAR el front end esperando a la imagen...

Esto es de gente que le falta cierta idea aún.

tambien he visto gente que no gestiona los errores HTTP, asume que siempre sera un 200.

Esto de ser inutil

1 1 respuesta

desu #43825 Mar '23

#43824Farmijo:
Esto es de gente que le falta cierta idea aún.

Pues no se, mi dia a dia es constantemente esto. Gente con 10, 20, 30 años de experiencia... Engineering managers, senior engineers, staff engineers...

El caso que mas roto me ha dejado es el de mi equipo no entender que es una cola... No se. Entiendo la confusion con la terminologia async/non-blocking porque esta muy extendida. Pero lo de la cola? Que excusa tienes?

#43824Farmijo:
Esto de ser inutil

Gente de Ebay ganando +100k anuales.

Seguro que @isvidal no sabe lo que es un HTTP status code. El tambien gana 6 cifras y su codigo no lo usa nadie.

1 respuesta

Lolerpopler #43826 Mar '23 Cinturón negro

#43820 En ese contexto entiendo que la API que hay que diseñar va a hacer operaciones/peticiones que se pueden dejar ejecutando sin bloquear el resto de la logica. Y que deberia de ser compatible con protocolos asincronos (http2 por ejemplo). Al menos una de estas dos cosas

Pero es un poco "buzzword" y muchas veces no saben ni para que lo quieren. Como tu dices, si el cliente no esta aprovechando para paralelizar o las operaciones en el servidor te fuerzan a esperar