Help with JavaScript Learning Roadmap

Hi community, I need help and I believe that it can also help tones of people so i'll go straight to the point with the Use case:

A friend of mine wants to enter the project development world and he wants to be a JS full stack dev.

The end requirements would be:

• Javascript (^ES6)
• Services and Microservices
• React
  • Redux
  • Hooks
• Node.js
  • Express
  • PostgreSQL
  • Sequelize
  • Mongo DB
  • Mongoose
  • Apollo (after GraphQL)
• GraphQL

I'm always hands on tones of things and I would like to specialise myself on JS too because i'm coding since 10+ years ago but worked with java, php, asp, html, css, Sass, bootstrap, js, C++, react, preact, angular and other languages and libs, so I also need that (I feel kinda frustrated and I want to keep a main language and the overall environment), plus I love JS.

So here I am asking for your experience on this questions:

• Should I add (or remove) other stuff in the requirements? Which ones and Why?
• The learning roadmap I set (in order) would be fine and suffice or it lacks something?
• Do you think the roadmap would be the same for me (10+ years of coding experience) than for my friend (a complete begginer that knows something about HTML and CSS only)?
• Feel free to comment whatever you feel like about the topic

Comments

[David Pereira]

Hi @joelbonetr , the end requirements you specified are great 👍. Here is my opinion on each question:

Should I add (or remove) other stuff in the requirements? Which ones and Why?

Yes, you could add:

• RESTfull APIs - you only added GraphQL, which is completely fine and it empowers front-end devs. You can learn REST as another option
• Typescript - JS is great, but Typescript is better 😁... I'm joking, but I'd in fact recommend the use of Typescript in Node.js and/or in React.js.
• DevOps practices. CI/CD is important for any type of software development. You can also think about deployment into Heroku, AWS, Azure, or any other cloud provider you prefer.

The learning roadmap I set (in order) would be fine and suffice or it lacks something?

Maybe the services and microservices could change order and be last. It depends on the use case (as always) but the other skills should be prioritized, imo.

Do you think the roadmap would be the same for me (10+ years of coding experience) than for my friend (a complete begginer that knows something about HTML and CSS only)?

No, imo a beginner doesn't need to worry about microservices architecture. You can develop web apps that are monoliths just as well.

Also, it might be easier to start with an abstraction above databases, like an ORM. But later on I think it's important to understand what is underneath, in order to critically choose between using one or not.

The key would be to focus on one stack (e.g. MERN) and specialize on it.

Feel free to comment whatever you feel like about the topic

You didn't mention Next.js and Vercel, but it could be cool to check it out. You could do SSR with the stack you mentioned, but a framework could also help you with that 🙂

Resources
Here are some resources on the topic that may help.
Note: These aren't just about the JS ecossystem, but full-stack development as a whole

• Web developer roadmap
• How to Learn Software Design and Architecture | The Full-stack Software Design & Architecture Map

Hope it helps 😃

[JoelBonetR 🥇]

Thanks a lot @bolt04 for your deep insight, really appreciated!
You're right in some things I forget to mention because I'm already into it since some time ago such DevOps,

i'll definitely take a look at those links :)

[Adam Crockett 🌀]

PostgreSQL
Sequelize
Mongo DB
Mongoose

This is tricky, teaching about one ORM and one DB might be a better way, then explain about a handful of NOSQL databases, because there is so much happening in this space, it's tricky to cover

[JoelBonetR 🥇]

Yup but remember I said specialise and not learning the surface only.
At the end you'll work either on Relational or Non-Relational database (NoSQL is a tricky term) and you don't know if you'll have one ORM or another or even having one, isn't it?

When you work with non-relational database you usually design APIs that deals with a view, otherwise you'll need different calls to get what you need from the required entities so data architecture is a strong point on API design and architecture too, don't you think?