When you generate a fresh angular app, you get over 300MB of supporting characters. Feels heavy for a hello world. What’s it all do? Looking in the project there are 8 json files for configuring node, the typescript compiler, the linter and the Angular CLI itself. There’s a node_modules folder for holding all your third party dependencies, an e2e folder to house all of your end to end tests and the src folder where the magic happens. In the src folder, you’ll find 3 more folders and some files you’re not super likely to want to edit.
The index.html file is less interesting than you’re probably expecting. It’s got a weird app-root tag, but doesn’t have a single script tag. This is because this file is essentially a template that webpack will follow to generate an index.html file when you build your project. That file will be adorned with all the angular goodness you need and placed in the dist folder when you run ng build.
This file exists to bootstrap a healthy angular environment. You don’t often edit this file. It imports your app module, your environment config and a bits of angular to get you up and running.
Here is where your global styles can live, but it’s more responsible to put the bulk of your sass in the assets directory and simply use this file to to include them.
This file is there to support unit tests. Again, you won’t often edit this.
So far we’ve seen a couple dozen files and folders and not seen any of the good stuff. Finally, one level deeper, in the app folder, we see where our code will go. To my sensibilities, that's a lot of digging to get to where you put your actual code. If you're just getting started you can and probably should largely ignore all the files outside of the app folder. Inside this folder, you see a bunch of files with the word component in the file name and a couple with module in the filename.
Modules are as boring as they are important. The primary job of a module is to wire up your dependencies. Modules also provide a means controlling how your code is broken up at build time for lazy loading purposes.
A component is your basic unit of functionality. A component can exist as a single file like you tend to do in React and Vue, but by default the CLI splits components into html/css/ts files that work together to voltron you up a component.
Most of the stuff you can do in a service, you could do in a component. This is much the same as in MVC, your model logic could be found in your controller. Just as "fat model skinny controller" is a good mantra, you'll want to bring business logic and state into your services and simplify your component code. In addition to a sensible place for buisiness logic, a service is a good tool for sharing state between components. Http requests probably should happen in a service, then expose the results to consumers of the service. Note that services are not necessarily singletons. If you wire them up via the @Injectible decorater with providedIn: 'root' they are singletons.