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

B

[Borrado] #21151 Abr '21

.

1 respuesta

Lolth #21152 Abr '21

#21150 Para mi, B tiene que parsearse la información de acuerdo a lo que necesita, A puede dejar los datos preparados para otros servicios, no tiene que dejarselo en bandeja a B.

1 respuesta

desu #21153 Abr '21

#21151 #21152

A ver leed el enunciado y pensad en las consecuencias.

Si a A no reconoce la existencia ni requerimientos del servicio B, que impide a B dejar de funcionar con el tiempo? Solo que cambie cualquier cosa de A va a romper el servicio B. Estas acoplando todo el funcionamiento del servicio de B, en un servicio A.

Si tienes un caso de uso explicito y una dependencia entre A y B que nunca se debe romper debes garantizarlo. Si necesitas cambiar el formato de los datos, como B esta consumiendo y B nunca lo podrás tocar, deberás replicar los datos de usuario en A para no romper el servicio...

La respuesta correcta es A -> B pero esta no es gratis

Lo que pasa es que A antes era un servicio "propio" y ahora se convierte en un "proveedor" o de "infra".

Si lo miramos a nivel solo de la pipeline de datos, lo que requieres es ir puliendolas no? Pues con 2 servicios igual. Quien tiene los datos los pule y expone.

Y si tuvieses algo mas grande tendrías estas pipelines especificas como servicios a parte para no acoplarlo a servicios/casos de uso. Pero no es el caso XD O si lo es, es la responsabilidad de la empresa A hacerlo.

3 respuestas

B

[Borrado] #21154 Abr '21

.

1 2 respuestas

desu #21155 Abr '21

#21154 Obviamente estamos trabajando conjuntamente en un proyecto.

El contexto ya lo he puesto, A y B debéis colaborar como una sola y hacer lo mejor para el proyecto conjunto.

Además lo he dicho en la ultima frase, pregunto por lo correcto no por lo que a ti te conviene.

No os ense;an a leer en el FP?

En fin, que como vosotros piensan todos los pajeets y asi salen los proyectos de mal hechos. Pero bueno, espero mas opiniones de alguien no Fpero.

1 respuesta

Fyn4r #21156 Abr '21 Inocente

#21153 por qué te inventas restricciones en la respuesta? XD

1 respuesta

desu #21157 Abr '21

#21156 Cual?

Lolth #21158 Abr '21

#21155 Un proyecto que dejara el servicio A invalido para cualquier otra función

1 respuesta

isvidal #21159 Abr '21

Os dejo un temazo para motivaros esta ma;ana fria de martes

spoiler

desu #21160 Abr '21

#21158 No hombre, el servicio A se ha convertido en un servicio proveedor por tanto debe proveer. Pero que ahora sea proveedor no significa que deje de hacer sus funciones.

Es el servicio A el que crece y cambia, no el servicio B que solo tiene una razón de existir. Si otro servicio C requiere de datos intermedios que solo tiene B entonces, B debe ser un nuevo proveedor.

B

[Borrado] #21161 Abr '21

.

eondev #21162 Abr '21

#21154 Yo entiendo lo que dice #21153 y estoy con que debe ser la primera opcion. En mi caso tenemos un servicio que depende de A y es una mierda, una putísima mierda tener que transformar todos los datos hechos una cochinada que es como nos los dan para ofrecer servicio y dependemos y hemos diseñado entorno a como tienen A montado y no a como debe ser el servicio que deberíamos ofrecer en conjunto entre los 2. Al final el que pringa es B, el servicio es más deficiente, continuamente están rompiendo cosas que hacen que dejen de funcionar en B etc.

Si tan guarro tiene todo A, que se preocupe A de meter entre medias un servicio o pipeline o l que sea para parsear o tratar los datos para que sea negocio-friendly macho, así toda la mierda que cambieis se quedará en casa entre A y C, y a B le comerá los huevos. Además que B también pone de lo suyo apra que A o quien sea consuma correctamente.

2 respuestas

B

[Borrado] #21163 Abr '21

.

desu #21164 Abr '21

#21162 Correcto.

Luego hay que desacoplar bien los servicios y tener claro las dependencias entre ellas. Crear dependencias y acoplamientos imaginarios porque alguien no quiere trabajar es algo muy común en la industria.

Lo he preguntado porque quiero saber si alguien hace bien las cosas o es un mal muy extendido por culpa de los pajeets y managers de turno. Yo creo que es un mal TAAAAAAAN comun que la gente como kazulo lo ve normal.

Si en lugar de considerar que son 2 servicios piensas que son 2 funciones. Pienso que la gente ve mas fácil que la función B debe ser una función pura y que haga solo lo que se supone que le toca hacer.

Porque solo he hablado del tema de acoplamiento de los datos. Pero imaginaros que requiero escalar el servicio B...... tendría que separar la pipeline? si me meto en un sistema distribuido es aun mas problemático hacer las cosas mal... Por eso he hecho el simil.

Es mas facil pensar a bajo nivel para entender los trade offs.

Función -> modulo -> servicio -> sistema distribuido con replicas

Lolth #21165 Abr '21

Vale, Lo entiendo así:

Vas a la empresa A montáis un funcional para que te entregue lo que quieres y donde tu quieras.

B lo consume tal como habéis definido y todo muy bonito.

Si el funcional se rompe te cagas en ellos.

B

[Borrado] #21166 Abr '21

.

3 respuestas

Lolth #21167 Abr '21

#21166 Nah, tu tienes tu propia API y pagas a terceros para que hagan una integración para lo que pide B, no hay que ensuciar tu código.

1 respuesta

B

[Borrado] #21168 Abr '21

.

desu #21169 Abr '21

#21166 Que cojones haces? No te has enterado de nada y has ido a coger el ejemplo que menos sentido tiene.

Cada servicio se encarga de un caso de uso diferente..............

Si es que no aprendo, por que respondo a un fpero? me tendría que haber esperado a ver si respondía alguien con estudios superiores.

B

[Borrado] #21170 Abr '21

.

2 respuestas

Fyn4r #21171 Abr '21 Inocente

#21170 Tenía un profesor que hacía lo mismo, nadie le iba a clase

aren-pulid0 #21172 Abr '21

Para crear una pequeñisima empresa, ¿ microservicios o monolito ?

1 respuesta

desu #21173 Abr '21

#21170 Si hasta @eondev lo ha entendido a la primera.

He borrado el ejemplo porque no creía que lo ibas a entender.

Se entiende mejor con este ejemplo.

La dependencia de datos siempre va de raw -> servicio -> servicio refinado.

Si tienes una dependencia A -> B. A se encarga de los datos, procesarlos y exponerlos para el caso de uso que toque...

1 respuesta

Wei-Yu #21174 Abr '21

se está quedando buena mañana

3

danao #21175 Abr '21

#21150 puf, la eterna. Parece sencillo pero las consecuencias de elegir mal es una mierda.

Yo tendría un servicio que mete los datos a Bo que B pueda consultar, pero que no sea el servicio A.

A hace sus cosas bien, que las siga haciendo y que su negocio siga sin tocarse. Lo interesante sería tener un servicio C que consulte Storage A y que sirva a B y a todos los servicios que requieran de datos de A.

La razón de hacer esto es no tocar A para hacer modificaciones a un servicio que no es su core de negocio y que si alguien la lía puede terminar afectando al servicio principal o que B sobre cargue A a base de peticiones o si le metes el pooling a A tal vez le sobrecargues, además de tener que gestionar posibles errores de cortes de conexiones, reintentos, datos que no llegaron... por eso tener un servicio C que vaya a Storage A y de servicio a terceros siempre y cuando sean fuera del negocio (como análisis de datos).
Tampoco vas a tener métricas de calidad en el servicio A si tienes procesos que no son de su negocio en especial de consumo.

Pero solo soy de FP y de sistemas así que ni puta idea.

5 1 respuesta

Leos #21176 Abr '21

Sí da igual lo que contestéis, es una pregunta trampa, si dices una edita o saca requisitos para favorecer a la otra, es de primero de desu

3

Kaledros #21177 Abr '21

Hay dos tipos de personas, los que viajarían atrás en el tiempo para asesinar a los padres del inventor del pair programming y los que desperdiciarían el viaje en alguna estupidez.

desu #21178 Abr '21

#21175 Este servicio al que tu llamas C, asumo que es un modulo de A.

Lo habia puesto inicialmente pero lo he quitado en un edit para no liar con tema balanceo/routing/servicios... Pero si estas en lo cierto, aunque tu vocabulario puede generar confusión... No entiendo porque razonas a nivel de microservicios y no a nivel de servicios o modulos dentro del monolito. XDDDD

Doy por hecho que un caso de uso = un endpoint y que A tiene una manera de balancear el trafico y de tener el codigo entre los distintos modulos (casos de uso) completamente separados. Asii que estas diciendo lo mismo que yo digo y lo que yo considero que es correcto. Pero en lugar de un monolito, por algun motivo NO TE GUSTA y haces otro servicio independiente cuando no es necesario para nada...

No entiendo porque conceptualmente no comprendeis que A puede tener multiples servicios/modulos y que solo tengas que tocar esos modulos para cada caso de uso... No se porque estais asumiendo codigo sphagetti y que todo este acoplado en un mismo servicio y endpoint... Es que si no sabéis dise;ar un monolito ya vamos mal. Pero bueno, te compro que un monolito no te gusta y lo quieres en un "servicio a parte".... aunque sea lo mismo.

Entonces, todos estamos de acuerdo en lo que es lo correcto, ahora. cual es la realidad?

PS; eso de las metricas no es cierto, tu puedes tener la misma funcionalidad sean servicios A y C independientes, o que C sea un submodulo de A. Porque para empezar deberias explicar que entiendes por servicio... proceso independiente? porque me cuesta entender donde puedes tener una duda ahi.

1 respuesta

Wei-Yu #21179 Abr '21

le he ido dando a F5 cada poco y cada vez que le daba aparecía un párrafo nuevo

1 respuesta

desu #21180 Abr '21

#21179 Es que de verdad no entiendo porque ha tenido que decir lo mismo que he dicho y y @eondev pero en lugar de un monolito le mete un servicio independiente con las consecuencias de complejidad que eso implica.

Porque no puede tener un servicio+controller por caso de uso?

No entiendo xq ha tenido que decir lo mismo pero en una complejidad de un sistema distribuido.

Porque todo lo que ha dicho lo puedes hacer en un monolito.

2 respuestas

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales