I am looking for guidelines like what things are considered as bad practices when using APIs, when to use components or not, which architectural pattern to use, etc.
In addition to what everyone else has already mentioned, you might want to check out http://mern.io/ and see how they are architecting their stack - it may give you more insights.
First I want say is - stop thinking that someone else is better than you, stop asking architecture, tool or perfomance questions before a real use case. It is same as asking what is better: bike or a plane, without providing a context. If your goal is, let say, to travel from London to a New York, then it would be a plane, if - get from your home to an office which is only few streets away, then - bike. What do you know the best, what team do you have, what your team knows the best, what business do you have, what design do you have, what are the requirements, budget and deadlines? That will determine the answers.
It is usually writen on API provider's website, if it's, facebook, for example, then you will be forced to follow Facebook guidelines if want your app to be approved.
The only one thing I would like to add - never store API keys, passwords in version control (Git), always store them in some .env file which is in .gitignore
From the software architecture - "component" is a general term and basicly means - part of a system. It can be almost everything, it can be small, can be large, doesn't matter, every system is composed from components, many components are constructed from sub-components also and so on.
Dividing you system (app) into components is not just a good practice, it is requirement, to make a system stable, maintainable, extendable, testable, durable and that list can be continued.
Always use components - and by that I mean - always plan and build your architecture ahead.
What I want to tell here is - always start from the lowest level without much abstraction. Make one small object at the beginning. Later, when you will be adding new method to it and will notice that you have, let say, now 300+ lines of code, then, probably, it's time to think about a small refactoring. But, please, don't write many intefaces, classes, objects, sub-components when you can just create a simple function or define a simple constant. So again - always start small and grow later when it will be really needed.
And here I will just say what I have said at the beginning.
It is impossible to answer this question without a detailed information about the business and a project. However, if I will tell you to use - 3-tier architecture, I will be right because you will use it anyway even if you will not know about that. Every software in the world which has UI is a subset of 3-tier architecture.