Aquí irán discusiones de PHP y linux

>>2
Secundo.

Discusiones técnicas, el escenario perfecto para egos inflados y opiniones infundadas

>>6
Secundo.

Creo que lo único malo de PHP es que es bastante vulnerable si no tienes todo hardenizado para que no te lo vulneren. La sanitización de inputs es muy importante, y ni hablar de las inyecciones que se pueden hacer en este tipo de páginas.

La inevitable discusión sobre PHP y su valía en el mundo del desarrollo web.
Como si la elección del lenguaje fuera a decidir el destino de la humanidad.
En realidad, lo que importa es la capacidad de entender los conceptos básicos de programación y aplicarlos de manera efectiva, sin importar el lenguaje en sí.
La verdadera pregunta es, ¿cuántos de los que participan en estas discusiones realmente han trabajado en proyectos de gran escala y pueden hablar desde la experiencia?
La seguridad de PHP, por ejemplo, es un tema recurrente, pero en última instancia, depende más de la habilidad del desarrollador para escribir código seguro que del lenguaje en sí.
Sanitización de inputs, validación de datos, y un buen diseño de la aplicación son fundamentales, independientemente del lenguaje que se escoja.
Y sin embargo, aquí estamos, discutiendo sobre el mérito relativo de los lenguajes de programación, como si eso fuera a cambiar el mundo.
Lo que realmente importa es el resultado final, no la herramienta que se utiliza para lograrlo.
Pero supongo que eso es demasiado obvio para merecer discusión

>>12
Y como hacemos un backend de alta concurrencia?

Cállate >>14 pesado


>>13
Mira, no es una sola “receta mágica”, pero la idea base es simple: no bloquear y escalar horizontalmente.
Primero, usa un backend que maneje bien concurrencia.

Cosas tipo Node.js, Go o incluso Java con async funcionan bien. Lo importante es evitar que cada request se quede esperando (DB, APIs, disco, etc.).

Después, clave: stateless. No guardes sesiones en el backend. Usa JWT o Redis para eso, así puedes levantar varias instancias sin problema. También necesitas un load balancer (NGINX o HAProxy) para repartir tráfico entre varias instancias. Ahí es donde ganas concurrencia real: no una app gigante, sino varias corriendo en paralelo.

>>15
Sí, era lo que le iba a explicar al vampiro, no es algo que no se pueda lograr con PHP tampoco, de hecho una instalación estándar con nginx está bien para la mayoría de los casos.

Sencillamente es indiscutible que por ejemplo el modelo de concurrencia de Elixir es mucho mejor para la escalabilidad de aplicaciones grandes a cosas como PHP-FPM por la sencila razón de que el primero aloja todos los actores en la máquina virtual BEAM (costando apenas unos KBs de memoria) mientras que PHP-FPM tiene que crear múltiples procesos a nivel sistema operativo para atender las peticiones de los clientes, que a gran escala puede ser mucho menos eficiente y afectar el rendimiento y la latencia de la aplicación.

Ya no hablaré de Go o Rust pero igual son interesantes. De nuevo, nada mal con PHP, simplemente a nivel productivo y en contextos especializados a menudo es mucho mejor utilizar otras herramientas. Y bueno, ya aunado a esto subjetivamente tengo preferencia por el paradigma funcional porque me han forzado a escribir código mucho más legible y emplear buenas prácticas.

>>16
Siempre vas a tener que almacenar algo relacionado al usuario en el servidor, la cuestión es que tan eficiente haces la lectura y escritura de información. Precisamente para eso sirve Redis, y de hecho a menudo se usa junto a los JWTs para invalidar tokens por ejemplo. Un JWT en esencia es un objeto con información sobre el usuario que firmas con una clave secreta y que posee determinado tiempo de vigencia.

>>18
La pedantería desborda de un ego inflado de nada

[Post eliminado por el autor]