Stel­len Sie sich einen Kell­ner im Restau­rant vor. Ein “blo­ckie­ren­der” Kell­ner nimmt eine Bestel­lung auf, bringt sie in die Küche und war­tet dort, bis das Essen fer­tig ist, bevor er die nächs­te Bestel­lung auf­nimmt. Ein “nicht-blo­ckie­ren­der” Kell­ner (so wie Node.js) nimmt eine Bestel­lung auf, gibt sie in der Küche ab und nimmt sofort die nächs­te Bestel­lung auf. Sobald ein Essen fer­tig ist, wird er benach­rich­tigt und ser­viert es. Die­ser Ansatz ist dra­ma­tisch effi­zi­en­ter und ermög­licht es Node.js, mit einem ein­zi­gen Thread Tau­sen­de von Anfra­gen (wie API-Calls von mobi­len Apps) gleich­zei­tig zu bedie­nen.

Für extrem CPU-inten­si­ve Auf­ga­ben (z.B. kom­ple­xe wis­sen­schaft­li­che Berech­nun­gen oder Video­kom­pres­si­on) gibt es Spra­chen, die bes­ser geeig­net sein kön­nen. Die Stär­ke von Node.js liegt in der Bewäl­ti­gung von I/O‑intensiven Auf­ga­ben (also allem, was mit Netz­werk-Anfra­gen, Daten­bank-Zugrif­fen oder Datei-Ope­ra­tio­nen zu tun hat). Da 99% der Auf­ga­ben eines mobi­len Backends I/O‑intensiv sind, ist Node.js für die­sen Anwen­dungs­fall eine exzel­len­te Wahl.

Ja, abso­lut. Obwohl Node.js oft im Zusam­men­hang mit NoS­QL-Daten­ban­ken wie Mon­goDB genannt wird, gibt es exzel­len­te und hoch­per­for­man­te Biblio­the­ken (soge­nann­te ORMs wie Pris­ma oder TypeORM) für die Zusam­men­ar­beit mit rela­tio­na­len Daten­ban­ken wie Post­greS­QL oder MyS­QL. Wir ana­ly­sie­ren die Daten­struk­tur Ihrer Anwen­dung und wäh­len die Daten­bank-Tech­no­lo­gie aus, die für Ihren spe­zi­fi­schen Fall am bes­ten geeig­net ist.