Feda /dev/ - No Javascript allowed

Alguno sabeis de alguna web donde puedas pillar los típicos templates de tablas, listas, menús con estilos chulos con angular y bootstrap(este opcional) para una web que estoy trasteando?

Soy programador full backend y estoy haciendo una movida personal para mi y ando bastante perdido para ponerme a toquetear los estilos de una tabla en angular.

Hace años si que utilizaba bastante una web que te daba muchos diseños en bootstrap, pero ahora parece que todas son de pago. ¿conoceis alguna free de calidad?

Una idea (nada nueva, hay estandards y todo) con la que he jugado en el pasado y que ya recordareis es el exponer todas las API como vfs.

Tengo una API mediavida.com y quiero integrarla en mi servicio. Por ejemplo lo que hizo @overflow de sacar detalles de los usuarios.

Podriamos listar usuarios:

ls mediavida.com/users

Y que nos devuelva una lista como hace ls, donde la estructura es columnar separada por espacios

eZpit
desu
W0rd
OnLy

Y luego parsear los posts de thredas con algo como:

ls mediavida.com/threads/threads/1234 | parallel cat mediavida.com/posts/{}

Suponiendo que threads nos devuevle una lista de post, y para cada post le hago un cat para obtener el contenido. Y tiro de parallel para hacerlo todo en parallelo automaticamente. La gracia es que puedo usar la shell y todas las librerias habituales sin tirar de curl y parsear. Y toda la logica de gestionar HTTP ademas, en lugar de implementarla en el consumer, la proporcionaria la libreria de vfs por ti. Que no tiene porque ser HTTP, puede ser un protocolo propio transparente para ti.

Y luego si no quieres usar shell puedes hacer codigo como:

  mediavidaFS = mediavida.FS()
  users = mediavidaFS.getUsers()
  threads = mediavidaFS.getThreads()
  posts = mediavidaFS.getPosts(threads[0])

Donde la gracia obvio, es que puedes usar la stdlib para file, que io_uring ya soporta muchas cosas interesantes que nos importan

#include <stdio.h>
#include <stdlib.h>

int main()
{
   FILE *fptr;

   //  add a post to threads/1234
   fptr = fopen("mnt/mediavida/threads/1234","w");
   fprintf(fptr, "write some post");
   fclose(fptr);
   return 0;
}

Que esto es el ejemplo que hice en el pasado y creo que os enseñe.

Que up/downs le veis?

Veo un approach interesante para la serie de backend.

No seria exponer un fs la manera mas simple, facil y rapida de integrar y exponer una API?
Porque tengo que exponer una API mediante metodos HTTP/RPC publicos?

#43778 Es una idea interesante de como exponer una API de manera simple e interoperable. Si. Tiene cons? Si claro, performance y gestionar la network a bajo nivel. Y como bien dices. Re-emplazar? eso nunca. todo tiene su caso de uso concreto. En este caso seria una manera "universal" de exponer una API.

Volviendo a mi idea, que es tener una todo list de backend. Voy a empezar guardandolo en un .json en local, luego quizas una sqlite y luego quizas paso a s3... cuando pase a la s3 pense, o incluso antes, porque no hago que la funcionalidad de leer y escribir sea un vfs? Esto se me ocurrio pensando en s3, porque se que hay gente pro como el que enlazo ahora que hace estas cosas. Y muchismos sistemas criticos en FAANG trabajan a nivel de kernel/userspace usando vfs o herramientas que expone el kernel que para la mayoria de programadores que no somos "sistemas" no conocemos.

Asi que google y de ahi encontre: https://www.rath.org/s3ql-vs-zfs-on-nbd.html

Que solo leer su post ya ves que tiene toque. Entro en su linkedin y staff SRE en Google, Google de los de verdad, central team y de ads... De los que ganara 750k anuales y su trabajo es hacer lo que le sale de la polla.

Volviendo al backend, lo que iba a hacer es terminar por integrar S3 (mediante localstack o minio) a mi backend, y una de mis ideas era exponer una funcionalidad mediante un vfs o algo del estilo. Pero pensandolo bien, si la idea de la serie es analizar a bajo nivel TODO el backend, desde UDP vs TCP, porque no hago toda la API un VFS desde el principio?

Lo de UDP vs TCP por ejemplo creo que es facil entender porque usamos TCP, el tema de tener la conexion abierta y tener un ACK para saber si has recibido el mensaje o no, evita que el cliente este mandando mil mierdas en UDP. Lo que ha pasado con los años, pasando por SSE, re-utilizar conexiones para PUSH desde server y finalizanco con QUIC y HTTP3, es que nos hemos dado cuenta que tener "udp" de server a cliente va muy bien para muchos casos de uso.

Otro tema "arquitectura" que estoy pensando, es como sabeis estoy en contra del modelado de negocio. SI voy a usar HTTP en mi sistema y por dentro todo sera comunicacion HTTP. Porque no tengo 1 servicio por methodo HTTP? Esto llegando al punto donde rompo mi monolito y necesito tener microservicios para escalar y optimizar de manera aislada.

• post-service
• get-service
• delete-service
• head-service
• put-service
• patch-service
• ... no se cual me falta XD options?

Porque lo que suele pasar es que un POST o un DELETE son mas costosos que un HEAD o GET .

Y que un GET o HEAD son por definicion CACHEABLES a todos los niveles (no?), por tanto sabre que todos esos endpoints de esos servicios van a tener una CDN => CACHE => get-service

Y si en el futuro tengo un bottle neck en mi delete-service. Por ejemplo, una operacion para borrar en batch, podria tener delete-batch-service como microservicio.

Que opinais de esta teoria? Yo la veo interesante y me gusta bastante. La he pensado 5 minutos ayer en la ducha.

#43779 Mmm puedes separar las lecturas de las escrituras, pero no las escrituras entre ellas

Corrígeme si me equivoco pero al final por coherencia en la inserción y modificación de datos necesitarías que esas operaciones fuesen secuenciales o acabarás teniendo problemas por condiciones de carrera.

Vamos, que no descubro nada, es lo que plantea CQRS

#43784 Pero el post-service irían todos los posts de la empresa? Eso elimina el sentido de los micro servicios, que no son más que un mecanismo para escalar la empresa, dividiendo los ms por equipos para evolucionarlos, que se atañen a un bounded context o dominio o lo que sea.

Si tienes un equipo que se encarga de los deletes, pues es un poco complejo a no ser que el dominio de la empresa sea pequeño o único. Ya que sino tendrías a todos los equipos metiendo mano en el mismo microservicio, y si ya con 4 se monta un pifostio…

#43785 Estamos partiendo del caso de que estamos empezando de 0 un producto = una empresa y escalando. Y partimos de que 1 equipo = 1 producto = 1 "empresa". De momento tenemos 1 producto que es una todo-list. Entonces. Si todos los POST de mi todo-list en el post-service, porque no? Y todo eso seria un equipo.

Y obviamente no haria falta separar todos los metodos al principio. Esto lo veriamos analizando el trafico y detectando bottlenecks. Y yo estoy convencido de que los get/head vs post/put/delete habra diferencias que pueden justificar esa "arquitectura". De hecho, el tener APIs de READ y WRITE que es lo habitual, sirve para separar un poco lo que yo estoy haciendo. Podria empezar con un read-service y un write-service tambien. Eso lo podemos discutir e implementar y analizar diversos casos de trafico. El tema es que el tener READ y WRITE, si te fijas esta muy acoplado con el dominio de "negocio", y queremos re-plantear esto, porque lo tecnico es hablar de metodos HTTP.

• READ/WRITE nos dice QUE QUIERE EL USUARIO HACER. Casos de uso para LEER, casos de uso de GESTION/ESCRITURA
• METODOS HTTP nos dice COMO funcionan esos metodos, son detalles tecnicos. Si el usuario quiere LEER o GESTION/ESCRITURA es IMPLICITO al metodo HTTP.

Depende de tu trafico no tienes porque separar en READ/WRITE... Quizas es mas optimo separar por HTTP primero y escalar los POST/DELETE/GET por separado porque son costosos y tener el resto en un servicio unico. Si separas en READ/WRITE, los WRITE son POST + DELETE. Quizas los DELETE no son ningun problema y son mas criticos los POST.

La gracia es ir escalando y analizando las cosas desde otros puntos de vista en lugar de hacer la solucion fpera por defecto. No he pensando en como evolucionar la todo-list a algo mas complejo, que ideas se os ocurren? Un b2b con todo-list que permitan editar? Feeds de todo-list a lo twitter entre cuentas? No se... Busquedas? No se... Deberiamos sacar otro caso de uso y ver si lo metemos en el producto, o es un producto nuevo. Y aqui es donde entraria la gracia de COMO ANALIZAMOS si algo es un feature o un producto nuevo? Y por tanto otro equipo...

#43786 creo que no, pero podríamos hacer uno de Kotlin

#43790 ya lo siento, para mi te ha tocado dar un paso atrás

Lo bueno de empezar por Java es que luego pasas a Kotlin y te llevas una alegría y te preguntas por qué no lo hiciste antes. Si empiezas por Kotlin pues no aprecias la suerte que has tenido de no tocar Java XDDD

#43786 hay un hilo para el mejor lang de la jvm
https://www.mediavida.com/foro/dev/scala-hilo-general-solo-personas-funcionales-distribuidas-677907

#43798 Te pones la máquina más tocha y ya está. Pero si hay algún framework lightweight que consigue buenos benchmarks, pero no son aptos para pajeets.

Mi equipo tampoco sabe programar, usan también clases abstractas y nada, no hay manera.