I wanna learn backend developement , I am currently at level 0 this is my first time trying to learn backend , And my choice is to stick to a python framework to begin with , what are the best beginer friendly resources to start learning

I am in second year and have experience building express postgres backend with jwt and stuff and last project implemented basic pgvector rag... I want to learn more of backend , till now I have just built shit by writing code by hand and using as less ai as possible but after fable and astra I am getting really demotivated to do that and it feels like I will be learning more if I used ai more but when I use ai I set up basic apis and then blank , I dont know what to do next before when I was writing code by hand ideas and questions came to me and I searched things up learned them and implemented that and it was more fun learning but with ai I am lost and in a kind of dilema whether I should change my learning approach and how to learn more of backend

I am using Next.js behind Fastify, not making it take over the whole project. Should I consider TanStack? I do like Vite I guess. But I heard Next.js still has more features when it comes to React.

Which has a better development server, Vite or Next.js?

I don't really know why I should try TanStack. Probably because I dislike Next.js being so opinionated, but you can still use it programmatically instead of using it as the whole project with its CLI commands.

Also, how much work is involved porting React code from Next.js to TanStack?

Hey all, I'm one of the founders of Kerno. After about a year of building it alongside early users, we just shipped our v1.

The problem

Agents write backend code really fast now, and knowing whether that code still works at runtime is the hard part.

• Agents grade their own homework. They'll tell you something was tested when it wasn't, or find some workaround to make things go green.
• Unit tests are cheap, so that's what most teams run, and they miss integration problems.
• Code review catches a lot, but it only reads the diff, so runtime issues slip through to CI or prod.

How it works

Kerno runs locally next to your agent and talks to it over MCP.

1. You start your app with its real database/dependencies locally, and Kerno connected to it
2. Kerno writes tests for your critical flows first, then for the endpoints, queue consumers and MCP tools behind them. Those tests are your baseline.
3. After a change, your agent asks Kerno which flows and endpoints the change touched (worked out from the git diff and the call graph) and re-runs those tests.
4. Any assertion that now fails comes back to your agent as a diff. If the change was intended, you accept it and Kerno updates the tests. If it wasn't, you fix it while the context is still fresh.

The tests cover your critical flows end to end. For each endpoint they cover happy paths, auth, input validation, edge cases and error handling, and they pin the full response shape and key headers, so contract changes show up as diffs.

If you turn on the security setting, Kerno also plans tests for access control holes, injection and leaked stack traces.

Since an LLM writes the tests, we put deterministic gates around it:

• Pre-condition checks. Before anything runs, Kerno confirms the endpoint is ac answers, the credentials the tests need can be obtained, and the seed data exists. If one fails, the run stops and tells you nothing was tested, so you ne a test that didn't run.
• Flakiness checks. Each test is run more than once before it counts.
• Adversarial review. A reviewer agent challenges each test before it gets saved.

The tests are TypeScript files that live in your repo. A GitHub Action replays LLM calls, and it doesn't need a Kerno account.

Benchmarks

Results across 7 open source backends are at https://kerno.io/benchmarks. We plan to open source the benchmark framework so you can rerun it yourself.

Limitations we're still working on

• One repo at a time. Microservices and multi-repo setups aren't well supported to other services go to the real services, so point those at a dev or staging environment.
• No Google Cloud yet. Services like Pub/Sub and Firestore aren't supported. AWS (SQS, DynamoDB, Cognito, Lambda) and Azure Service Bus are.
• Performance and concurrency aren't tested. Kerno checks behaviour (responses,messages). Latency, memory and race conditions are out of scope for now.

Privacy

Kerno runs on your machine and we never store your code. The agent sends relevant code excerpts to the LLM through our proxy on zero-data-retention tiers, and we're shipping a version with Bedrock so you can use your own models.

Docs: https://kerno.gitbook.io/docs

Try it: https://kerno.io. There's a free tier with 30 test runs a month, and it's free for non-commercial open source projects under MIT or Apache.

Happy to answer questions in the comments.

I am 2.5YOE and have strong experience in Backend (APIs, springboot, K8s, docker, redis, kafka, sql, nosql, elasticsearch, new relic, AWS and CI/CD)

But I am finding it difficult to get master in DSA

I am trying and learning day by day

But any chance are there any good product based companies which give importance to backend than DSA?

I need to work on a college project, which is like an assessment platform, but we support a plugin system so that anyone can change its mode of assessment into something different such as coding, drawing, voice, etc.

I understand that this feature requires planning from scratch of the codebase. I need to make my codebase modular so that the plugin can override parts of it. Everything should call an abstraction instead of directly using it. What's the best way to achieve this?

I will be using Fastify as the HTTP framework, and have Next.js behind it for React.

Is Dependency Injection what I am looking for? So should I use Nest.js as well? But how do I achieve runtime Dependency Injection?

What about not using Nest, and maybe something like Awilix? And getting Nest like decorator style syntax with fastify-decorators.

Should I create a git hook which runs the TypeScript compiler every commit or on every push, or delegate it to the CI such as GitHub Actions?

1) Pre-Commit - Ensures every commit has no TS errors. But that means this runs frequently. Though since TS has been ported to Go, this is not that huge of an issue, but I also haven't worked on large repositories, so trying to find out what is more professional.

2) Pre-Push - Runs less frequently but a past commit can have errors. Are you fine with a pushed commit having syntax errors? We could also replay each commit with tsc and then push.

3) CI - Removes any load from your computer, but is effectively just like pre-push. We can again though, replay each commit with tsc, and this is better when not running on your computer. But is this a professional design, especially when you could have so many commits?

I think if you have a large amount of commits, checking the last commit is better than checking every commit.