/coding-advanced-resources

Further Resources for the Programming Journey

Please find here some of my recommended resources for continuing your coding journey in JavaScript / TypeScript by self studying.

Following are some fields where you could go next (In case you do not have other plans already ;)):

Don't get overwhelmed by this huge amount of topics.

Each topic alone could keep one busy for weeks (like React TypeScript) up to months or even years (like Algorithms or Game Development).

So with that list you could extend your own self-study curriculum to several years.

This guide will get updated from time to time with new resources.

Most important JavaScript basics

These are the most essential JS concepts in order to start with Framework Development (e.g. React or Express)

  • Functions (Arrow Functions, Parameters, Return, Callbacks)
  • Array Methods: map, filter, find, reduce
  • Spread Operator ( the three Dots: ... )
  • Destructuring (to extract data from objects & arrays into new variables)
  • Event Listener ("click", "change")
  • Event object (=> e.g. event.target to grab a clicked item)
  • Promises (to "call" remote applications, e.g. an API or a database)
  • Fetch

React

App ideas for training (from simple to more complex)

Material UI

You have a project where you actually do not really care about an "original design"?

The use case is simply "clean & functional"?

Or you simply don't like spending to much time on styling at all?

Then give the "Material UI" package a shot.

With Material UI you can get - similar to Bootstrap - UI components out of the box, by simply "copy & paste & adapt".

Material UI components also often bring some JavaScript logic out of the box, e.g. for picking a date from a calendar.

The Material UI package uses the famous "Material Design".

The package was specifically developed for React.

Learning Material UI:

React with TypeScript

In a project React is very often used in combination with TypeScript instead of classical JavaScript.

Without getting into all the details, Typescript makes your code (much!) more robust by adding so called TYPES to your JavaScript code.

At the end of the day you can see your application as a big chain of calling functions, passing data around, changing data, returning data, displaying data. That is actually all there is.

So what do you guess is the most common ISSUE in our functions then?

In the IT world there is a famous meme called "SHIT IN -> SHIT OUT".

Meaning: Incorrect INPUT data passed to a function will return incorrect OUTPUT. It is that simple.

TYPES will assure that you call your functions with CORRECT INPUT PARAMETERS throughout your code and also makes sure functions always RETURN the correct, expected OUTPUT DATA format.

By this simple "hardening" of your functions, probably 80% of issues in your application code can already be eliminated. Sometimes more, sometimes less. But definitely: It will impact the stability of your code massively.

Of course, sometimes also our functions PROCESS the data incorrectly, because we used wrong logic. This is something TypeScript cannot solve. At the end of the day, also SOME debugging fun must be left for us ;)

Backend Topics

Before getting into backend development, it makes sense to WORK with backends from a frontend first in order to practice backend REQUESTS and how to process RESPONSES.

Understanding the request / response cycle for frontend / backend interaction and how to process the data in the frontend is critical and a good starting point for thinking and designing a backend.

Find here my API connect guide showing how you can:

  • connect to an API using a tool (=REST Client)
  • connect from JavaScript

API Connect Guide: https://github.com/losrobbos/api-connect-guide

For training these two resources are great:

Dealing with existing APIs will give you a good understanding of what the USE CASES of APIs are and how to deal with API resources before actually starting your dev journey.

Enjoy!

Firebase

Once you got the hang on working with an API, you might wanna setup and deploy your first own API.

In order to get started or in case you do not really want to dive deep into backend development, you might want to take one step back and take a look on how to create an API in the cloud without any coding and have a quick storage for your user generated data.

In that case, Firebase will likely be a very good fit to get started: https://www.youtube.com/watch?v=9zdvmgGsww0&list=PL4cUxeGkcC9jERUGvbudErNCeSZHWUVlb&index=2

For little pet projects or Portfolio Projects Firebase should be more than enough to store and maintain your data!

So in case you just wanna focus on Frontend Development, you could end your journey with "API development" here :)

MockApi.io

In order to setup an API where you can train HTTP requests using the "fetch" function in your frontend, you can checkout MockApi: https://mockapi.io/docs

Here you can setup a mini REST API with GET, POST, PUT, DELETE routes.

This is great e.g. to provide an out of the box REST backend for your portfolio applications.

Backend Development with JavaScript

JavaScript / TypeScript can be used to code backends too.

In case you are not sure so far, if you wanna specialize on frontend or backend development in your career, it would make sense to learn backend coding with JAVASCRIPT first. That will be a lot easier compared to learning a brand new language.

And you will learn all important backend concepts this way and will be able to also code backends in other languages at some point.

For the database MongoDB is a natural fit for your JavaScript backend, because in MongoDB you basically read & write JavaScript data. It will be very familiar.

Once you wanna FOCUS on backend development, so you wanna become a specialized backend developer, you will have to learn at least one further language. And additionally at least one SQL database (it doesn't matter much which one, but PostgreSQL or MySQL are natural first choices).

Most used languages for backend development:

  • Java
  • PHP
  • C#
  • Python
  • Go

Common databases:

  • PostgreSQL
  • MySQL

But the language, like usual, is not enough. Together with the language you need to learn a backend framework.

Popular Frameworks:

  • Java => Spring
  • PHP => Laravel, Symfony
  • C# => .NET
  • Python => Django / Flask

Caching & Messaging:

  • Redis

The two main API patterns

There are two main approaches how you can build a DATA SERVER (=API) for your frontend.

You can either build a REST or GraphQL API.

Both of these API patterns do the same thing at the end. But their setup & architecture is pretty different.

The difference explained + demo of both: https://www.youtube.com/watch?v=PeAOEAmR0D0

GraphQL solves one fundamental problem of REST though. It ships with a tool which will document the API out of the box. So it makes it way easier for frontend developers to checkout how to retrieve data from the API in the format they need and EXPLORE with requests online easily, before they do the same in code.

Building a REST Api with JS Step by Step
(the series is a bit dated in the used syntax, but the concepts are still valid & explained very well):
https://www.youtube.com/watch?v=0oXYLzuucwE&list=PL55RiY5tL51q4D-B63KBnygU6opNPFk_q

Building a GraphQL API Step by Step (PLayList): https://www.youtube.com/watch?v=Y0lDGjwRYKw&list=PL4cUxeGkcC9iK6Qhn-QLcXCXPQUov1U7f

Databases

Databases - Getting started: https://github.com/losrobbos/databases-getting-started

Data Modeling: https://github.com/losrobbos/data-modeling-guide

Futher topics

Prepare your frontend to integrate with an API. With API Prototyping: https://github.com/losrobbos/api-prototyping

Mongoose - Working with nested arrays and objects: https://www.google.com/amp/s/attacomsian.com/blog/mongoose-subdocuments%3famp

Deployment

Deployment simply means: Bring your app online :)

There are a lot of free providers for deploying your frontend & backend apps.

For frontends e.g. you can use Vercel, which works extremely well for REACT deployments.

For backend deployment render.com is one of the most solid options (even though you can also deploy simple backends using Vercel too!)

Team Development

Most projects these days get developed in TEAMS.

Developing in teams is fundamentally different compared to working alone. A lot more things need to be considered before even starting (!) coding, otherwise you will probably produce a lot of conflicts.

There are some fundamental decisions to take upfront:

  • How to align all team members to a certain design?
  • How to create & split tasks in the team?
  • How to schedule meetings to track progress & discuss issues? Daily? Two times a day? Once a week? Or pair programming the whole day?
  • How to use Git & GitHub in the team to bring our features together?
  • How to setup simple rules for code formatting in order to prevent accidental file changes & merge conflicts?
  • Assure usage of same versions of libraries for the whole team (e.g. no mix of React 17 and 18, Material UI 4 and 5, Node 12 and 16, etc)

And finally, for the role of the team lead: How to fill that role?

There are tons on books and articles on the subject of team leading, so this is pretty much out of scope here :)

But this video here nicely summarizes my own attitude how to interpret the leading role of a team (=the Servant): https://www.youtube.com/watch?v=jMpCF0Z623s

Design Mockup

In order to design an app with multiple pages, you usually create a MOCKUP.

A mockup is a first visual draft of ideally all your planned app pages / screens, maybe even adding the possibility to jump around in that draft by clicking links & buttons.

Especially in team development a mockup is very necessary to create a COMMON visual understanding of the app (and also the needed data and flow of data!) and agree on basic design choices, like used colors & fonts.

A free, pretty famous & solid tool for that job is Figma. https://www.youtube.com/watch?v=eZJOSK4gXl4

But of course there are several other tools available to do this, like Adobe XD, Balsamiq or others. Pick your prefered one.

A mockup does not need to stay FIXED, of course, it can still be adapted throughout the project. But ideally you still spend quite some time on discussing the fundamental design principles UPFRONT of coding :)

Take your time on this and do not rush it through within one day. It will pay of significantly later on.

Some terminology:

  • Wireframe: Just a very basics sketch of your screens, just sketching the LAYOUT
  • Mockup: A wireframe + added colors, fonts and images to already create a real page feeling
  • Prototype: An already ACTIONABLE version of the mockup where you can e.g. click on navigation links to get to other pages. Prototypes can either be just a basic, "clickable" design or already contain code for basic interaction.

Planning & Splitting tasks in a team

Planning of tasks nowadays is usally done using a Ticket system.

A ticket system simply collects TASKS - both urgent and more long term - from multiple sources (customer wishes / feedback, internal requirements).

In order to get a bit familiar on basic task management terminology, you might check out a short video first: https://www.youtube.com/watch?v=rIaz-l1Kf8w

A famous tool to get started with ticketing for a small project is Trello: https://trello.com/

Trello is really nice to quickly get started with basic ticket management terminology like Kanban.

In case you manage your code on GitHub you can also use GitHubs built-in "Trello" board: Github Projects.

Here you can link tasks in a repository to a Kanban board and can automate the movement of the tickets.

Nice Step by Step Playlist on GitHub projects: https://www.youtube.com/watch?v=idZyqNIrt84&list=PLiO7XHcmTslc5hGrbnnmHIb0SeJLTpOEu

Once you do work in Company teams, you will find out that JIRA is the most often used tool.

JIRA is practially an industry standard and universally used in Team projects.

It is slightly more complex than GitHub projects. But once you feel fine with GitHub Projects, you will also be quickly able to work with JIRA in a company.

You can also try out JIRA for free if you want:

https://www.atlassian.com/de/software/jira

But most likely it will not be necessary to have JIRA experience to get your first project position.

Scheduling Meetings

In company projects the so called "Daily" is a common term.

Daily = A short meeting in the morning, where we discuss our current status.

In case of a finished feature we settle what we want to focus on next.

And discuss any issues we have, both in code and in understanding (!) of tasks. Usually in a team we get fresh ideas on solving issues we would not have come up with alone.

Especially the point of understanding a task is super important.

Very often team members shy away from getting clarification on something they do not fully understand in an assigned task to prevent looking "dumb" or "weak".

Same for a bug we already tried to solve since days. Without any progress. And we just hate us and the world. But in the meeting we just tell "Everything runs fine". And noooo, we don't need help.

That false pride will sure-fire shoot you in the foot at some point of the project.

I love to torture people with clarification questions on given tasks, in order to get the best common understanding possible. Because I know from so many team projects, how much this is necessary.

Most of the time we do not need to discuss the nitty gritty implementation details on code level). But on high level it should be clear how things in the app should behave, especially from a user perspective. If we understand the user perspective it will also help a lot when coding the feature.

Additional to the Daily Progress Meeting you could arrange another daily or bi-weekly merge meeting.

Here we merge our finished feature branches and also solve all the appearing conflicts together.

Dealing with code merge conflicts can be a very intimidating task and usually also needs some clarification between at least two members in the team on how to deal with the conflicting code parts.

Therefore in the beginning of a project it is highly recommended to solve conflicting code parts together to prevent any nervous breakdowns :)

Lastly there is the possibility of "Pair Programming" where you code in pairs or even as a whole team together in a video session.

That can make a lot of sense if people work toegther on the same page or feature (e.g. the frontend & backend part of the login page)

Styling approach

One of the most fundamental decisions in the frontend tech stack is which library is gonna be used for styling.

There are first of all these general approaches:

  • Raw styling using CSS or SCSS
  • Styling using pre-made CSS Utility classes: The most famous library for this is Tailwind
  • Using a Component library for ready to use "plug & play" components with a base style: Like Material-UI, Reactstrap or React-Bootstrap
  • Using a library that allows us to directly write SCSS in components. Styled Components: https://styled-components.com/docs/basics

Picking one approach that fits all opinions & wishes is very hard to achieve, especially if we do not know these four approaches too well.

Also team members usudally defend their favorite library "religiously" :)

Ideally explore all options on one day together in the team: e.g. raw SCSS, SCSS in components using Styled Components and one component library like Material-UI.

Afterwards it will be much easier to make a decision in the team.

We will likely have to live with this decision for the whole team project, so do not rush the decision and rather experiment one day more :)

Code Formatting & Linting

In order to prepare for a Team project it is absolutely essential to have at least a basic understanding of the concepts of code formatting & linting.

Configure it just ONCE at the beginning of your project... and then forget about it and code happily ;)

Mini Guide to get going: https://github.com/losrobbos/code-formatting-and-linting

Git Development in a team

A guide with a real life, practical, hands-on process including all Git commands.

Setup and enjoy Team Development without worrying all the time about your next Git merge ;)

https://github.com/losrobbos/github-flow-guide

Git Commits & Aliases

How to formulate a Commit Message in a real company project?

Are there any rules or conventions?

A common stanard is the Semantic Commit Message

Semantic Commit Message Examples (fix, feat, docs, chore, etc...): https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716

Example Semantic Commit Messages in the VueJS Project: https://github.com/vuejs/vue/commits/dev

The 3 ways how to create a commit with a message:

  • git commit (opens text editor to write message)
  • git commit -m "Subject Message" (Subject only / Oneliner)
  • git commit -m "Subject Message" -m "Body Message (Subject and Body -> optional description)

Git Log

  • show all commits just with message, without any details: git log --oneline

How to set Git Aliases (for Git commands we use frequently ): https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases

Advanced

File Uploads

In most web applications where user can create contents, we need to provide FILE UPLOAD functionality.

E.g. the user can pick a personal AVATAR image for its profile or upload a recipe image for a recipe page.

File Uploads allow the user to pick an image from disk and send it over to a backend. The backend then stores it, either on DISK or in a DATABASE.

Find here a guide how you can realize a file upload fullstack, using React for the Frontend, Express.js as the backend and a file cloud provider to store the files in the cloud for free:

https://github.com/losrobbos/file-upload-guide

NextJS

NextJS is a React FRAMEWORK, so it is built upon React, adding some very handy extra features.

Features you get out of the box:

  • Routing (no React-Router-DOM)
  • Server Side Rendering (for Search Engine optimization)
  • API routes (integrated backend functions!)
  • Authentication between Frontend & Backend

NextJS makes you probably 50% more productive, compared to normal React development.

It takes away a lot of default work for me, which I usually need to setup & configure painfully on a new project, like routing or providing several authentication methods.

That alone makes it much more fun for me to develop in NextJS, because I can pretty much focus on my app logic right away, without all that draining "standard tasks" setup.

Learning NextJS:

React Native

With React Native you can build up on all your - earned by sweat, pain and nervous breakdowns - gained React knowledge... and now build smartphone apps!

I got a React Native "Getting started" guide here, which might be helpful as preparation, before you get into the official docs:

https://github.com/losrobbos/react-native-guide

Test Driven Development

Let's say you invested dozens of hours into this nice feature.

Your code works fine. The feature works in the browser.

You pushed it. It gets deployed. And it works.

The world is fine.

But then you realize: DAMN! This code is a bit messy.

It works. But probably it needs quite some restructuring and polishing.

But if we are working in a TEAM PROJECT we could get into a serious problem now.

Our feature is important.

In the meantime others have already built up new features BASED on your feature!

So work of others now DEPENDS on that feature to be working like expected.

So IF we change and re-organize the code of that feature (the term for this is REFACTORING), we must make sure, that the OUTPUT of our code after that refactoring is the same as before!

So all code which depends on that feature (either code from you or your team mates), will still work as before too!

In order to give you safety for your refactoring, you need to ASSURE a certain output of your function(s).

You need .... a TEST!

A TEST simply means: A piece of Code. A piece of code which checks if your feature code works like expected.

You can use that piece of test code to check - after you have done all your changes & cleanings - if the feature code still works exactly as before.

And the nice thing is: This TESTING can be automated. Meaning: Once you have written a test you can check AGAIN and AGAIN that your code works like expected, automatically.

And if you write tests for literally ALL your functions in your app, you basically have assured the OVERAL functionality of your app.

So with that process in place, everybody in the team can be safe to not just add but also CHANGE stuff in the app.

The TESTS will make (almost) sure, nothing gets broken in the system.

That is it.

That is the basic use case for testing:

ASSURING functionality, even after (a lot of) changes in the code structure

A famous approach in the software industry is therefore the so called TEST DRIVEN DEVELOPMENT, short TDD.

It is a process to - more or less - ENFORE testing of your application code right during development, as we code the feature.

We distinguish between writing a test AFTER we coded a feature or BEFORE we even start coding a feature.

The latter approach is called Test first. It is the strict mode of enforcing testing. This way you reach a high test coverage of your functionality.

Testing Concepts & types of tests - a nice introduction:

Testing JavaScript vanilla

Testing with JEST - Getting started guide:

Testing React

Playlist: https://www.youtube.com/watch?v=7dTTFW7yACQ&list=PL4cUxeGkcC9gm4_-5UsNmLqMosM-dzuvQ

Testing Antipatterns

Testing can also be overengineered: https://www.youtube.com/watch?v=UWtEVKVPBQ0.

Algorithms & Data Structures

In the "real world" you sometimes face problems that could not be solved by looping over an array or counting up some numbers.

Sometimes we get a bit more complicated structures, e.g. like this object:

  {
     "name": "Grandparent", children: [
        { name: "Sally" },
        { name: "Harry", children: [
            { name: "Melinda" }, { name: "Harry Jr" } 
        ]}, 
     ]
  }

Here we have a Granparent object with children, where again each child can have children. And so on.

Challenge: How can you now get a FLAT array with the names of ALL members out of this family "structure"?

Okay. You could use simply nested FOR loops to loop through each "level". And add each found item to a new array. That is it. Right?

But then you have to know IN ADVANCE, how deep the family tree goes!

In case we got three levels down, we need 3 for loops. But on another family we might need to go 8 levels down... and then we need 8 (!) nested for loops!

So how can we write just ONE piece of code, that will collect all the members on all levels independent on how many levels we have here....!

If we just know loops and functions it will not help much.

So we reached a classical "algorithmical challenge".

And therefore we need to understand a bit more on DATA STRUCTURES. E.g. the one above is a so called TREE.

And then we need to know a bit on how to work with these data structures, e.g. to search inside them or convert them into something else.

For that part we need to know about ALGORITHMS.

Coding Challenges online

Courses + Books

Game Development

Game development is a fantastic challenge to get your programming to the next level.

In Game Development also the topics of ALGORITHMs and DESIGN Patterns can be nicely trained (see the following chapters in the guide)

For little Games without "enemies" you can try to use VanillaJS / DOM in the Browser or React.

Examples:

For a little more interactivity (e.g. collisions with moving items or enemies) it will be a lot easier to use a game library (often called "game engine")

2D Game Engines

Examples:

3D Game Engines

Babylon Examples:

Examples Enable3D (with mouse movement you can change the view):

My currently preferred engine is BabylonJS, due to the superb documentation & easy to follow guides.

Gake Development with JavaScript (without game engine)

In case you want to take your programming skills to a whole new level, try to get into game development with vanilla JS (without libraries)

Here is a very great video playlist of someone building a variety of Games (Mario, Pokemon, Fighting game, Space Shooters, etc) using JS only, explaining all relevant concepts step by step:

Chris Courses PlayList:

https://www.youtube.com/watch?v=eI9idPTT0c4&list=PLpPnRKq7eNW16Wq1GQjQjpTo_E0taH0La

Design Patterns

Design patterns are patterns for designing the code for your application. Straight and simple.

We all know the design of a webpage in the browser. But what does "design the code" mean?

It sounds a bit weird. Does it mean to style your code with CSS? Nope :)

So let's start with the problem.

We all know - You often need to COMBINE functions and classes in a way to create an application that solves problems of a user.

Writing code that realizes some feature is ONE part of the game.

But often it is not straight forward, how to ARRANGE classes and functions to work together properly.

And even if we get our feature "somehow" working: That does not mean we are done with it forever.

Unfortunately we cannot just code our app features once and forget about it.

Once the app is deployed and users actually start USING it, we will need to CONTINUE working on the code.

Meaning: Fixing bugs of existing features. Refactoring not optimal code, e.g. for performance optimization. Adding new features on top of existing features.

So we get these common problems we need to tackle:

  • solve the user problems by CREATING & ARRANGING our classes and functions to work together properly
  • keep the code FLEXIBLE & EXTENDABLE, so we can add new features without the need to change all our code structure on new requirements

And we are lucky.

Most problems of these kind have already been solved in the past.

And the lessons and "patterns" that came out of that are: Design Patterns.

Design patterns are suggestions on how to write software to fulfill the goals above.

We have two base programming techniques of producing code:

  • Object Oriented Programming (OOP)
  • Functional Programming (FP)

For both of these "paradigms" we would apply different patterns, as OOP and FP code structures differ quite a bit.

Therefore the FIRST design choice is: Functional Programming vs OOP vs a mix of both (=hybrid)

For languages like JavaScript we could use patterns from BOTH worlds, because JS allows a mixture of functional & OOP programming.

So it makes sense to learn some OOP design patterns, even if you are mostly just coding functions. At some point classes might get handy too, to solve specific problems.

OOP Design Patterns

There is a very famous standard book for OOP design patterns just called "Design Patterns" by the "Gang of Four" (often called just GoF):

https://www.amazon.de/Design-Patterns-Object-Oriented-Addison-Wesley-Professional-ebook/dp/B000SEIBB8/ref=sr_1_2?keywords=gang+of+four+design+patterns&qid=1670749326&sprefix=gang+of+four+d%2Caps%2C108&sr=8-2

Another famous series of patterns are the SOLID principles.

Now getting into all that design patterns (several dozen) without any concrete real life use case at hand would probably be a bit overkill at first.

In order to get into design patterns, you can also start with a YouTube playlist which will make the topic a bit more accessible ;)

Playlist - Design Patterns - some famous "Gang of Four" design patterns + the SOLID design patterns:

https://www.youtube.com/watch?v=BWprw8UHIzA&list=PLZlA0Gpn_vH_CthENcPCM0Dww6a5XYC7f

Pure Functional Programming (no OOP)

In case you wanna do "all functional" or just mostly functional, it might make sense to dive a little bit into some functional programming paradims:

Domain Driven Design

There is one philosophy that goes a little bit beyond that "object oriented vs functional" approach.

There is a famous design technique - that has shaped a lot of code terminology in the whole IT industry - called Domain Driven Design (DDD).

It is not just a technique, but also kind of an "attitude" on how to approach code design by trying to align the whole team processes, spoken language (!), architecture and code to our real life problem as closely as possible.

Domain Driven Design - From real life problems to Code (Book): https://www.amazon.de/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?keywords=domain+driven+design&qid=1650536079&sprefix=domain+driven%2Caps%2C143&sr=8-1

And this topic is also the perfect bridge to our last section in this guide - and the ultimate last enemy: Application ARCHITECTURE.

Architecture

At some point you might be ready.

You coded all that little apps.

You worked in teams on bigger apps.

You mastered a lot of different code tasks in your life.

You have built code, maintained code, fixed code, refactored code.

You have seen already almost all bugs in your lifetime that you can think of. With your own code, other code, libraries and tools.

Are you ready to go all-in now?

For those wanna step a little bit "outside the box" of just coding a feature in a team or creating own small web apps... it is time to look at the broader picture on how to actually setup the INFRASTRUCTURE for more complex web projects.

Once you reach that step, you might be ready for an architect position or lead development.

Design Patterns are an important part of that. But design patterns just address the code itself.

How do we deal with the OVERALL (not just in code) rising complexity as more and more features get added... and added... and added?

Will our app still SCALE well, meaning: Will it not significantly SLOW DOWN or become more and more ERROR prone with more and more features, connected services, registered users and involved developers?

How do we make sure, our app does not turn into a gigantic ball of mudd, causing chaos, panic and disorder in our team?

For this we need to think, apart from the code and its organisation, also about broader factors:

  • Which parts of our app are performance critical and maybe need more resources than others?
  • How do we decouple (=split) & integrate parts of our app, so they can be scaled independently?
  • Which tech stack is best suited for our kind of user problems?
  • Which external services we need and how do we integrate them? Do we use Providers like AWS, Azure or Google Cloud for hosting & scaling our app / parts of our app?

All these are questions not primarily related to code. They are related to the overal plan, the overall ARCHITECTURE of our app.

Some nice resources:

Books:

Further Topics

Some topics that are not handled yet here, but maybe are of more interest for you:

  • Building desktop apps (like VsCode oder Slack) with Electron JS
  • AI & Machine Learning
  • Deployment Automation with CI / CD (Continuous Integration / Continuous Delivery)

I wish you a happy coding journey, may the code force be with you!