[xmprt]

Definitely a great idea. gRPC has been a huge benefit for us. I'd also get rid of learning NoSQL databases. It's good to know but in 99% of situations you should be dealing with them especially not before you learn about things further down the list like Docker, RESTful APIs, Auth, etc.

[databrecht]

NoSQL is not less important than others. Especially not with the rise of many startups that want to scale and want their sites to be lightning fast (e.g. available at the edge). Many companies I worked lately actually thought the non-traditional databases are becoming more important.

Also distinguishing NoSQL and SQL is quite old and still dating from the CAP theorem which is also becoming obsolete. You have traditional databases and the rest since 'NoSQL' are incorporating SQL features (ACID, joins, etc) and vice-versa, soon it will just be databases with feature X,Y,Z. If you want to add something I would rather add 'distributed databases'. Learn relational databases probably boils down to 'learn SQL'

Knowing which database to use in the landscape is extremely important.

It should imo be: - Learn SQL - Learn GraphQL (becoming the new SQL quickly) - Learn gRPC - Learn about database features (consistency, distribution, replication, sharding, OLTP, OLAP) and what database to use in which situation.

[brillout]

"becoming the new SQL quickly" - Prisma, who led the way on that front, abandoned this pursuit.

"Learn GraphQL" - I'm not sure you need to learn GraphQL. You need to now that GraphQL is a powerful tool for APIs consumed by third party devs, such as the GitHub or Facebook API. But for internal APIs (and more than 98% of APIs are internal!), GraphQL (and even REST) is overkill and you'd be better off with RPC, such as Wildcard API [1] or gRPC [2]. Many developers will never have to build a GraphQL API in they entire career. Only few companies need to expose their data to third parties.

[1]: https://github.com/reframejs/wildcard-api

[2]: https://grpc.io/

[threeseed]

I would hope new developers ignore comments like yours.

NoSQL databases are just a tool like other tools. And you should know when and why to apply such tools not just dismiss learning them altogether.

Also every developer goes on their own journey. So if someone wants to build a social network then a graph database is going to make more sense even at the beginning than a relational one.

[xwdv]

I’ve seen way too many junior developers fall in love with NoSQL databases to recommend them as a starting point. NoSQL is a niche tool whereas relational databases will be the bread and butter in a vast majority of cases. Many junior devs try to use NoSQL for everything and then fuck it all up.

Postgres even supports using NoSQL concepts with JSONB so there’s no reason not to start with it.

I’m sure I’ll get downvoted since HN has been very hostile to real talk lately but I don’t care.

[majewsky]

Yes, but the current version of the roadmap makes it seem like NoSQL databases are way more important than they are (IMHO). I would say a junior backend developer needs to know about web servers, REST, AuthN/AuthZ and even Docker way before they need to know about NoSQL.

[oakejp12]

I'm interested as to why junior developers even need to learn Docker. I'd say learning Docker would be a "nice-to-have," but you can go years, or even forever, without having to deal with it, or even having a need for it. I'm not saying learning Docker is fruitless, just that Junior Developers might not get enough out of learning Docker to put it in good use.

As for NoSQL. I'd say that definitely should be on the roadmap. I've assumed that they've already learned RDBMS, but knowing when to use the two is essential. Most companies now are working with data lakes and unstructured data (e.g. user and session data). Knowing how to get around that flexibility, how to structure your business logic and models, and what tool to pick (i.e. Redis for caching), etc. goes alongside NoSQL knowledge.

[wdroz]

Using docker force you to declare step by step what you need to build/use your code. If you combine that with good CI/CD, that easier to provides help to the junior developer if you can quickly reproduce the environment.

I had a bad experience with a project that I was assigned to "help". The build steps documented used incompatible lib version. It's hard to help if you can't even build/run their codes.