Hey guys,

I’m currently a front-end React developer with around 3-4 years of experience.

I originally started programming with C# and .NET, so I do have some backend experience, but it’s pretty vague at this point. At work I’m mainly focused on the frontend, and only occasionally touch the .NET API for smaller fixes to finish tasks.

Lately I’ve been wanting to become more of a full-stack developer using Node.js instead of .NET, since Node interests me a lot more.

The problem is that most Node.js courses start completely from scratch, which doesn’t really work for me because I already have programming experience. I’m looking for something more intermediate/advanced or at least more practical.

I know project-based learning is usually the recommended approach, but I’m struggling with creating a proper roadmap for myself - what projects to build, what concepts to focus on first, and how to progress from “I can build an API” to actually becoming a solid Node.js backend developer.

For people who already made a similar transition:

\\- What helped you the most?
\\- What kind of projects would you recommend?
\\- What topics should I focus on beyond basic CRUD APIs?
\\- Any courses/resources that are better suited for experienced developers instead of beginners?

Would really appreciate any advice!

I have a good experience with typescript and little knowledge about rust.

But i dont feel like doing rust now, so i wanted to explore either go or elixir but im confused rn, idk what to choose. Idk which helps more for my career growth

Please share your suggestions

Edit - i dont have any particular projects in mind, i just want to explore other than typescipt( im bored of it because i dont write code anymore claude does)

So im just confused, even if i learn elixir now after 6 months or 1 year or so ill learn golang too. So the better question is which one shall i explore first go or elixir?

Also it should help me for my career growth, and make me a better developer too.

Sorry for the rant and for my current state of confusion! 🥲

Edit 2: thank you all for your suggestions, i decided to go with golang as it better suits with my long term goals

p99 sitting at 600ms. we checked everything. execution plans, indexes, N+1s, connection pool. added Redis caching on the heaviest endpoints. hit rate came back at 4% because param variation meant almost nothing reused. three weeks in and we'd basically just added a round trip to every request.

then someone looked at the NGINX config. keepalive_timeout was 2 seconds. keepalive_requests was 10. under real load, connections were tearing down and renegotiating constantly, every upstream request paying SSL handshake and TCP setup overhead. gzip wasn't on for API responses. upstream keepalive between NGINX and the app wasn't configured at all. fix was a config file. 40 minutes. p99 dropped to under 200ms. some endpoints hit sub-100ms. zero application changes.

the answer was sitting in a config file the whole time while we were rewriting cache invalidation logic. if your app looks healthy and your db looks healthy, check what's sitting between them before you touch anything else. what's the most embarrassing place you've found a bottleneck?

Say I have a table with users:

USERS

-----

ID

EMAIL

PASSWORD

CREATED_AT

UPDATED_AT

then I also create a table to track changes:

USERS_LOGS

----------

USER_ID

TIMESTAMP

ID

EMAIL

PASSWORD

CREATED_AT

UPDATED_AT

Does it make sense to have CreatedAt and UpdatedAt on the USERS entity if there is already a "TIMESTAMP" field in USERS_LOGS?

Trying to prioritize building rather than complexity and was looking for some suggestions.

Ive noticed at my company a trend of hiring a lot of juniors devs or ppl who don’t have dev backgrounds and having them exclusively churn out AI code. I see this as a way to undercut salaries, they hire junior or non-devs and pay a fraction of what they pay mid-senior. My questions are, is this a sustainable model? And how can I as someone with 5ish years experience stand out from this?

From a c-suite/management perspective they are all about cost savings, if they can hire a junior/non-dev using AI to build out their codebase why hire a mid-senior at 2-3x the price?

What is the selling point/secret sauce that warrants paying a mid-senior dev if a junior/non-dev can churn out code now with AI?

Hi everyone. I'm a backend developer working with Java/Spring Boot, and I'm also a fresher. I'm starting to figure out a lot of things and realizing the skills I need to do well in my day-to-day job. One of those things is having a strong understanding of the business rules behind a project, which helps write solid and reliable logic. So I'm trying to work on that.

But here's the thing: if I'm not working on a project for a client who explains all the processes of their organization, where do I find those rules? For example, if I want to work on a finance, banking, or stock management project — where do I find the right business rules? By "right," I mean realistic ones, actually used in the real world.

I feel like this is a big differentiator when it comes to developer levels. So if you guys know any resources that could help, it would be greatly appreciated.

I used synchronize: true in a NestJS project for way longer than I should have. It was fine in development. But when I renamed a column in an entity, pushed to production, and TypeORM dropped the old column and created a new one on the next restart., data was gone.

You can fix this with migrations, but the TypeORM + NestJS migration setup is very confusing because the TypeORM CLI doesn't know about NestJS's dependency injection. You end up needing two configs, one for AppModule, one for the CLI, and getting them to share the same values without duplicating everything takes a bit of work.

The piece that finally made it click for me was the data-source.ts file. It's a standalone TypeORM DataSource that reads from your .env directly, no NestJS involved. The CLI uses that. NestJS uses ConfigService in AppModule. Both point to the same database, same entities, same migrations folder.

we had this ai feature working pretty nicely in staging. clean json coming in, small files, predictable prompts, response time was fine and the model was giving decent answers. logs were clean too, so honestly we thought we were mostly done with the risky part.

then actual users started using it and the whole thing got messy pretty fast. first week only and we were already seeing stuff we never tested properly. pdfs with weird formatting, tables copied from excel, prompts with half the info missing, random extra context pasted in, all that kind of stuff. the annoying part was that most of it still passed validation. api returned 200, latency looked fine, no scary errors in logs. so from backend side it looked healthy.

but the answers were not always healthy. some were slightly wrong, some missed important sections because the parser skipped chunks, some retrieval results were just not relevant enough, and our fallback logic was basically too polite. it kept trying to answer instead of saying it did not have enough clean input for this. we were tracking uptime and token usage like that was enough, but we were not really tracking retrieval misses, low confidence outputs or bad answer patterns.

so yeah, lesson learned the hard way. an ai demo working in staging does not mean the feature is ready for real users. staging tests the happy path. production tests every weird thing people can possibly upload or type. curious what broke first for you after shipping an ai feature?

Im front-end leaning dev but Im trying to pick up more backend tickets to expand my backend skills.

I am wondering, what are the responsibilities? Id like to bring it up to my manager and push similar iniatives as well.

So far I have done:

- Done database migration by creating new tables or add/modify columns

- Create and adjust endpoints, so that the client can say update a new column in the database with new API versioning

- Logging and monitoring to some degree

- I only worked on repositories where it's the API and API gateway itself. I don't touch other stuff like Kafka setup, Redis, etc.

I have not done:
- Query optimization. I think for Query optimizaiton I will have a chance if people are reporting the backend to be slow.

Im only doing simple shallow backend tickets now, I think I am missing alot of the 'beef' of backend

[removed]

Hello! doing interviews again, so I wanted to ask here 😄 thanks !

I am stuck at the level where it’s hard to control the number of tokens while team is trying to use it effectively, one day it is good other day it eats up so many tokens for no reason but tries to include more files than it should, any basic idea how to segregate the work like feature or folder or related files only etc will be cool??

I’m still focusing on JavaScript for now.

I still need to cover these topics in JavaScript before moving on to the next stage:

- async/await

- selectors

- DOM

The most important thing for me right now is to practice, I really need to do that

*I'm also catching up on other topics

If anyone has advice or suggestions, I’d really appreciate your feedback.

Hi everyone! I'm starting now as a backend developer and I will be very happy if you guys share some of your experinces on the development area. Now I'm learning more about building APIs using node.JS and using JSON as a databank. I'm a Brazilian developer trying my best to lear everything about the area, hoping to find my first opportunity. I greatly appreciate your time, and sorry, It's been quite a while since I've written in English.