Backend JavaScript Developer: ¿Qué debe aprender?

B

Saludos, me gustaría crear un hilo para los que son o se quieren especializar en Backend JavaScript.

Es de sobra conocida la web de roadmap: https://roadmap.sh/backend/ (pdf: https://roadmap.sh/pdfs/backend.pdf)

Recomendaciones de @desu respecto a roadmap en #33:

spoiler

Pero me gustaría que gente con experiencia en el backend y en javascript nos dijera qué debe conocer todo backend developer.

Me gustaría que me dijeseis qué quitar o añadir a esta lista, y la voy modificando:

Uso de consola de comandos:
:black_small_square: Console Commands

Básico de HTTP para las respuestas, envíos, cabeceras, etc:
:white_small_square: HTTP
:white_small_square: HTTP Status Codes

Especialidad:
:black_small_square: JavaScript
:black_small_square: TypeScript
:black_small_square: Node
:black_small_square: Express
:black_small_square: Mongo / Firebase
:black_small_square: MySQL/MariaDB / PostgreSQL / ¿Redis?
:black_small_square: ORM (Mongoose, Prisma, typeORM)
:black_small_square: REST / GraphQL
:black_small_square: Nest
:black_small_square: Git / Github
:black_small_square: Testing: TDD/ EDD (Jest..)
:black_small_square: Documentar: Swagger
:black_small_square: Logs: ¿ npmlog?
:black_small_square: Docker / ¿kubernetes?
:black_small_square: CI/CD (¿GH Actions? / ¿AWS?)
:black_small_square: JWT / OAuth
:black_small_square: Socket.IO
:black_small_square: REGEX
:black_small_square: Cron

(Esto no sé si ya sería más de DevOps)
:white_small_square: NGINX (¿reverse proxy?)
:white_small_square: ¿Monitorizacion?

Y luego las cosas que todo programador o empresa creo que andan buscando a día de hoy así por encima:
:black_small_square: Clean Code
:black_small_square: Métodologías Ágiles (SCRUM)
:black_small_square: Principios SOLID

Herramientas:
:white_small_square: Editor de código: Visual Studio Code:
:black_small_square: nodemon (js) / ts-node-dev (ts)
:black_small_square: types (para ts en node, express, etc)
:black_small_square: standard (js) / ts-standard (ts) como linter con eslint.
:white_small_square: APIS: Postman
:white_small_square: Bases de datos: Tableplus

Idiomas:
:black_small_square: Inglés

¿Qué más creéis necesario que falta o que sobra para la tarea de un backend?

7
caporro8

Gran hilo :)

Erpotro

Yo estoy estudiando de a poco para entrar en el mundillo, recomiendo estos dos cursos, son gratuitos y muy completos con videos y anotaciones.

https://learning.edx.org/course/course-v1:IBM+CAD101EN+3T2022/home

https://learning.edx.org/course/course-v1:HarvardX+CS50W+Web/home

B

Actualizo un poco. Yo, al menos desde mi experiencia, es todo lo que conozco o he tocado alguna vez para tema backend.
Entiendo que conocer de todo eso ya debe ser un gran pedazo y puedes ser bastante bueno y experto si te especializas en todo esto, pero seguro que hay más cosas que se usen a menudo o cosas que se deban descartar porque sean más de devops u otras especializaciones.
A ver si alguien con conocimiento nos orienta.

kidandcat

Tendrás que manejarte bien con alguna herramienta para testear tus llamadas, tipo postman, pero en general esta muy bien la lista.

Si quieres trabajar en Go, tendrás que mirarte grpc

1 respuesta
B

#5 Cierto, añado al menos 3 herramientas que considero básicas.

Foxtreme

El gráfico de roadmap es bastante completo, consideraría imprescindible casi todo, aunque para un puesto junior quizás sea suficiente dominar hasta el apartado de Achitectural Patterns. A partir de ahí depende de en qué te quieras especializar (o en lo que te pueda hacer falta para un puesto/proyecto concreto).

Muy importante también conocer el ecosistema, toolchain, etc. del lenguaje que vayas a usar.

pantocreitor

Añade a la lista arquitectura hexagonal, es escucharlo y se le hace el culo agua a más de uno xD

A día de hoy se solicitan también muchos devs que sepan trabajar con brokers de mensajería (Kafka, rabbitMQ o pubSub)

1 respuesta
B

#8 qué son esos brokers?
Lo de arquitectura hexagonal lo he oído alguna vez pero ni idea en la práctica. Imagino que será una forma de distribuir el proyecto.

spud

Nodemon ya no se usa?

2 respuestas
B

#10 sí, y yo uso también ts-node-dev para TypeScript, además de types, lint como standard / ts-standard

Añadido

1 respuesta
JuAn4k4

Service mesh, service discovery, kubernetes/docker

Cosas de observability, Prometheus, Grafana, Métricas, SLAs, SLOs, etc
Cosas de comunicación: pub/sub, queues, streams, event bus, etc.

Patterns: Hexagonal, event sourcing, event driven, integration patterns

Redes: OSI Layers, udp, tcp, etc
Security…

2 3 respuestas
wdaoajw

#12 un dev sabiendo eso, no sé qué te metes pero pasate el contacto.

Devs que sepan de todo eso hay poquísimos.

1 respuesta
Kaledros

#13 Define "que sepan".

1 respuesta
wdaoajw

#14 saber siquiera usarlo, ya ni te digo montarlo

2 respuestas
LR

#10 #11 no se si con la última versión o con la penúltima de node ya metieron que puedas meterle un --watch y te lo hace sin meterle dependencias como nodemon.

Yo metería por ahí tdd y edd

1 respuesta
JuAn4k4

#15 En mi equipo somos 5, y 4 conocemos todo eso y más cosas, lo hemos usado, hecho y rehecho. En security no somos expertos pero sabemos hasta cierto nivel.

2 respuestas
LR

#17 También habría que definir primero el expertise al que se refiere #1

No es lo mismo tu que empezaste con las tarjetas perforadas que alguien que quiera meter cabeza ahora o lleve un par de años xD

Kaledros

#15 Usarlo, entendiendo como tal usar algo que utilice esas cosas y esté ya montado y pudiendo investigar los gaps que tengas, en mi curro actual uso el 80% de eso. Y mi plan de avance personal de este año incluye lo que me falta, que son redes y seguridad porque no he trabajado nunca con eso. Pero vamos, a poco que tengas suerte (u ojo para verlo en los procesos) con los proyectos, todo eso lo aprendes sin problemas en cinco-seis años de trabajo normal.

Y todos los de mi equipo saben más que yo de todo eso porque llevan más tiempo en el proyecto, claro.

1 respuesta
wdaoajw

#17 #19 pues debéis de ser la excepción, en mi experiencia la mayoría de la gente deja mucho que desear.

Devs que sepan montar clusters de kubernetes, montar la monitorización, montar servicemesh, etc etc... Que ojalá todos fueran igual, pero lo que yo he visto es justo lo contrario

1 respuesta
Kaledros

#20 Eh, que yo para montar todo eso las pasaría putas y necesitaría meses de aprendizaje, ¿pero usarlo una vez está montado? Unas horillas de pair programming con alguien que sepa, una documentación en condiciones y a funcionar.

Yandros09

Que buen hilo.

JuAn4k4

Claro yo al final le pongo temas, cacharrear un poco, montarlo “mal” y entender un poco cada cosa, entender que funcionalidades aporta cada cosa, etc.. No convertirse en un experto en Istio/Envoy, ni en cada cosa, pero si entender un poco de todo.

B

#16 sí pero para ts sigues necesitando algo no? O puedes hacer un tsc --watch que levante haga también el dev como el ts-node-dev?

Dios, en serio, creo que está última conversación es más de devops que de un developer de apis 🤷‍♂️

#12 Yo creo que desarrollar un backend no es desplegar una infraestructura como estáis poniendo. Ojo, no está de más saber siempre más, pero diría que se está llendo de tiesto esa "competencia"
No? Pero claro, desconozco si las empresas quieren un todo en uno de back/server. Yo veía el backend Developer como eso, un developer de backend (API, bd, test, documentación, etc) 🤷‍♂️

2 respuestas
LR

#24 no piloto de ts así que ni idea. En node a pelo si se que funciona bastante bien aunque avisan de que aún está en beta. De todas formas aún no me ha fallado por ningún lado.

B

¿Cómo se gestionan servicios distribuidos con colas, eventos, etc?

¿Qué se usa para ello? Lo veo como requisito en alguna oferta y no sé exactamente a qué se refiere 🤷‍♂️

1 respuesta
PaCoX

#26
lee CQRS https://martinfowler.com/bliki/CQRS.html , Event Sourcing https://martinfowler.com/eaaDev/EventSourcing.html

tmb esta bien esta guia https://learn.microsoft.com/en-us/dotnet/architecture/microservices/

2 respuestas
JuAn4k4

#24 A ver todo depende de lo que quieras ser, especialista o generalista, siendo typescript yo sería más generalista. Si fuese Rust o Go que hay menos gente entendería más especializarse.

1 respuesta
Wei-Yu

#28 tampoco creo que en la dicotomía que planteas el especialista sepa hacer más en su lang/runtime que el generalista. Qué expectativas tendrías tú sobre lo que defines como especialista?

Lo que entiendo que quieres decir es que el generalista tiene un conocimiento transversal del runtime de un sistema distribuido a nivel de componentes e interacciones entre ellos, pero si es así eso sólo me parece una especialización más. Generalistas tenemos que serlo todos de una forma u otra.

1 respuesta
B

#27 voy a ver gracias

Usuarios habituales