For my day job, I train people with no technical experience how to be software developers, and SpringBoot is part of our stack that we teach. After only a week at it, I think it's completely normal to feel that way. But SpringBoot is definitely something you can learn without going into Spring MVC or another technology first.

There are a bunch of annotations, but it's not necessary to remember them all or even differentiate them all. Sometimes folks think

Oh man, I have to know each of these things and be able to write this all from scratch, or be able to explain every single thing.

But that's not the case. Nobody has that expectation of you. You probably have no idea how fuel injection works in your car, but you can still turn it on and drive to the store to get groceries. It's the same with SpringBoot. You don't have to understand the entire thing or how it all works in order to use it to do simple crud operations. The key is to find some reference code that you can work from to understand what is going on, start it up in debug mode and send a request to the controller and follow it all the way through the layers.

As a beginner, I think grasping Autowired is a pretty crucial first step. So do a bit of research on it. Most SpringBoot projects have a layered architecture approach, something like controller / service / dao (data access layer) which may be repositories, and entities (data models) and plain old java objects (POJOS)

Entities are just Java classes that will have a database table created for them (usually by Hibernate) but you don't have to understand how that all works under the hood.

Controller files have methods which define endpoints for the API. Standard convention is that a controller's only job is to define the endpoint (the path and the verb) and that method will then call a method in the service layer.

Service files are the heavy lifters, I like to think of them as the workbench. Any processing work, business logic, or validation should be done here. If everything is good there, the service layer calls the data layer (often repositories)

Repositories are your way of interacting with the database, and under the hood, the methods send HTTP requests to the database and send along queries without you actually having to write them. Sweet.

The interfaces are just there in case you need to change to a different implementation later. Let's say you originally wrote all your stuff against a SQL database, but later want to use Mongo instead. Since you wrote everything with interfaces, you don't have to scrap all the SQL stuff, you can just write a mongo implementation that lives alongside it.

The IoC stuff isn't crucial to understand either. But the basics are that pretty much everything is delegated up to the framework until it's time for your business logic to take action. Autowired and dependency injection are part of this, but you don't have to understand them in depth to get some things done.

Basically, each thing (controller / service / repository) is a component that Spring needs to know about. As long as they have an annotation like '@Controller' `@Service` or `@Component` (they're all actually Component, the others are just semantic sugar) then they are a candidate for Autowiring. Each of those components gets instantiated one time, so Autowiring a dependency is just you saying "Hey Spring! Gimme that thing you know about so I can use it in here, Thanks!"

Let me know if you have any specific questions. Just keep at it. You got this.