Feda /dev/ - No Javascript allowed

#61714 Si estuvieras en un equipo como el mio te volverias loco.

Aqui por ejemplo se decidio meter todo un cluster de Mongodb, porque habia que almacenar jsons. Y en cada cliente que se despliega, se tiene que desplegar todo un cluster, para almacenar 10mb de datos en json.

Mi iniciativa 2025 es que comprendan que esos mismos json pueden ir en la postgres como jsonb (postgres que usamos para el 99.9% de los datos) y que así no tienes que gestionar backups de dos bases de datos, administrar dos bases de datos, gestionar HA en dos bases de datos, hacer al cliente pagar el doble o triple...

Con kafka ya es una pelea perdida.

Cosas de fontaneros, no lo entenderias.

Me voy a poner esto en el profile de teams: https://grugbrain.dev/

#61715 Si tu propuesta, para un deployment local para almacenar 10mb de datos en JSON es PostgreSQL y no SQLite, entonces no puedes quejarte de tu equipo.

#61717 si lees asi no te auguro buen futuro en el sector...

ya hay un postgres con cientos de tablas, que da servicio a varios tenant, esta base de datos está en cloud y necesita HA, por el tipo de servicio que es

hacia falta almacenar unos datos en formato json, se decidio montar un cluster de mongodb, en lugar de simplemente usar la postgres y su formato jsonb

tu propuesta de usar sqlite en lugar de usar la postgres con HA que ya tienes, es igual de mala que usar una mongodb, aunque menos cara, implica que tienes dos sistemas de BBDD que debes coordinar a la hora de hacer backups, RTO/RPO, cuando ya tienes una postgres con HA, para que quieres montar una sqlite para crear dos tablas extra?!

https://ommd.info/ ... Funcionando en un servidor de 5 leuros de Heztner (2vCPU + 4GB Ram) con docker: Rust + SQLite. La base datos ocupa la friolera de 117.04 Mebibytes.

** Es un proyecto personal que voy haciendo un poco cada 6 meses... igual para verano del 2025 se ve bien en moviles y todo.

LOL, para 10mb de datos en serio vais a meter sqlite? Casi 2025 y la gente sigue sin aprender a montarse sus propias bases de datos custom para sus requerimientos

#61727 this but unironically

#61728 pues aquí estoy 100% con phdfailer, cuanto más se parezca tu local a dev mejor, y cuanto más se parezca dev a prod mejor. Todos ganan nadie pierde. Qué importa que vayas a meter 1mb en una db o que vayas a meter 1tb? El código que se ejecuta tiene que ser igual y si haces eso que dices no lo será.

Entrada: genera un código en javascript que funcione, pero que el cödigo sea horrible a ojos de un programador experimentado.

Copilot: var a=0;for(var i=1;i<=10;i++){a+=i;}console.log("La suma es: "+a);
** Copilot es un mojigato... te da esta chusta y luego va diciendo.. "Pero así estaría bien escrito... <aqui código mejor escrito>" ¿pero yo te he pedido algo bien escrito? quita coño!

Grok:

// Esto es un codigo muy malo, no lo copies jamas
var malVariable = prompt('Escribe un número'); // No validamos nada

function suma(x, y) { // No usamos arrow functions por que somos malos
    if(x==='' || y==='') { // Usamos == en vez de ===, que horror
        alert('No puedes dejar vacio'); // No manejamos errores, solo alertas
        return; // Return con nada, porque si
    }
    var resultado = parseInt(x) + parseInt(y); // parseInt sin validación
    alert('El resultado es ' + resultado); // Concatenación en vez de template strings
}

var otroNumero = prompt('Escribe otro número'); // Más prompts sin validación
suma(malVariable, otroNumero); // Llamamos a la función con variables mal nombradas

// No hay manejo de errores, no hay comentarios útiles, 
// usamos var en lugar de let o const, y simplemente es horrible

** Grok no sabe ni lo que hace xD, el comentario dice una cosa y el código es otra.

Y hasta aquí la dosis diaria de I.A. usada de la forma mas mongola que se me ocurre en el momento.