Richard34

Die API ist die Schnittstelle --> "Application Programming Interface" (to interface = verbinden, interface = Verbindung, Schnittstelle). Du hast vollkommen recht: von wem die Schnittstelle verwendet wird, ist erst einmal egal. Das kann eine Desktop-Anwendung, eine Browser-App, eine Smartphone-App, eine Server-Application, dein Smart-TV oder von mir aus auch ein intelligenter Lichtschalter oder eine Zahnbürste sein. Das ist ja auch der Zweck dahinter. Du machst nicht für jeden Zugriffs-Client eine eigene Zugriffsmöglichkeit, sondern alle nutzen dieselbe API. Und deshalb willst du ja auch davon weg, Webseiten serverseitig zu rendern (zB mit Symfony) hin zu APIs bereitstellen (die auch wiederum mit Symfony gemacht werden könnten) + einzelnen Clients. Deine React-Single-Page-Application hierbei ist auch nur ein Client.
Dein Symfony rendert dann keine HTML-Seiten mehr, sondern gibt die Daten in einem maschinen-lesbaren Format wie zum Beispiel JSON (JavaScript Object Notation) aus. Warum JSON? Einfach weil das am einfachsten in JavaScript zu verwenden ist (React ist ja auch JS).

Ja, du liegst da richtig.
Im Idealfall ist die UI komplett entkoppelt und stellt nur ein Detail in deinem System dar. Dann ist es egal, ob die UI eine Web-, Desktop- oder sogar nur eine Konsolenapplikation ist. 
Ich kenne dein Wissensstand nicht aber es kursiert schon länger der Begriff "Onion Architecture" bzw. "Clean Architecture" rum. Diese Softwarearchitekturen stellen die Businesslogik (auch genannt "use cases") in den Mittelpunkt. Also das, womit man auch eigentlich sein Geld verdient. Dort befinden sich dann auch Schnittstellen für externe Dienste, die sie dann implementieren müssen und so ein Dienst kann z.B. deine UI oder auch die Datenbank sein. Dies hat den Vorteil, dass die Businesslogik komplett entkoppelt ist und keine Abhängigkeiten besitzt. Somit lässt sich dann die UI oder auch die Datenbank austauschen und da die Businesslogik überhaupt keine Abhängigkeit zur Datenbank besitzt, lässt sie sich dann auch noch leichter testen. Somit ist es dann auch egal, ob du eine Web-, Desktop- oder nur eine Konsolenapplikation schreibst.

Hm okay.
Also im Prinzp könnte ich es so machen. Nehem wir an ne Anwendung mit Datenbank zugriff und dann soll die noch auf andere externe Dienste wie z.B Wetterdienste, Verkehrdienste e.c.t. zugreifen können, (egal was, haubtsache dafür gibts passende api's). Dann ist das alles, Datenbank, die Api's mit dem Backend verbunden, da geht alles über Symfoni, was mir im Prinzip dann gebündelt die rohen, nakten Daten bereit stellt, daran schleise ich dann irgend ein Frontend an mit z.B dieser Rest Api.
Sollte ich dann z.B ne App haben wollen oder ne Destop-Anwendung, kann ich die einfach nur an dieses Backend "Anschliesen" und muss da nicht erst alles neu einbinden sondern muss nur eine Schnittstelle dafür verwalten, so jetzt meine Grundidee, liege ich da dann in etwa so richtig mit meiner Denkweise?

Also die grobe Architektur, Frontend und Backend zu trennen und per API zu verbinden, ist der richtige Schritt. Der nächste Schritt is zu erkennen, dass dem Frontend (in dem Fall deiner React-Anwendung) es komplett egal ist, wie das Backend entwickelt wurde. Wichtig ist erst mal nur, wie du auf die Daten zugreifen kannst. Hier wäre zum Beispiel die Stichworte SOAP, REST oder GraphQL angebracht. Nehmen wir mal an, du entscheidest dich für REST (was so der erste logische Schritt wäre): eine Rest-API kannst du in allen möglichen Sprachen und Frameworks entwickeln. Da du selber von Symfony gesprochen hast: einfach mal nach "Symfony REST API" suchen. Du kannst aber auch JavaScript verwenden (Stichwort NodeJS und Express). Du kannst aber auch Python (die Alternative zu Express wäre hier Flask) verwenden. Oder NestJS (das eher wie Angular aufgebaut ist). Oder wenn du auf Java stehst, kannst du dir mal Spring Boot anschauen...
Wirklich "schlecht" ist wohl keine Möglichkeit. Es gibt halt Unterschiede. Wenn du zum Beispiel nur Express verwendest, kümmerst du dich erst mal um alles selber. Nimmst du Symfony, kannst du sicher aus deinen Modellen bestimmt irgenwie deine REST-Endpunkte definieren... Es gibt es auch kein "richtig" oder "falsch"...

Moin,
Jep! Je nach Anwendungsfall nutze ich für das Backend dann PHP (erste Wahl ebenfalls Symfony) oder Nodejs.
Nodejs nehme ich, wenn ich mir vorstellen kann, dass ich für das Projekt irgendwann Websockets nutzen möchte, oder wenn die Aufgaben im Backend einfach sehr trivial sind. 

Soweit ich deine Frage verstanden habe sollte dir dieser Abschnitt helfen:
https://reactjs.org/docs/hooks-faq.html#do-i-need-to-rewrite-all-my-class-components
 

Ich bin jetzt kein Profi in React, aber ein Blick in die Doku sagt mir, dass man mit UseState den (App-)State auch ohne Klasse nutzen kann. Ich weiß jetzt nicht, wie wichtig das für einen Anfänger ist, aber ich würde als erstes bei den Komponenten bleiben und dort die ganzn setState()-Sachen verwenden und noch gar nicht darüber nachdenken, wie man außerhalb einer Komponente auf den State zugreifen kann. Das ist dann evtl. für Edge-Cases interessant. Was nicht heißt, dass man sich nicht ums State-Management kümmern soll, das ist m.M. nach sehr wichtig, geht dann aber eher in Richtung Redux, MobX, etc. 

Und sobald eine schwammige Antwort kommt, auf eine konkrete Antwort bestehen. Sollte dann immer noch keine kommen: Abbruch!
"Ich habe Ihr Profil hier gesehen und finde, Sie passen gut auf eine von mir zu besetzende Stelle" - "Schön, wo würde die gehaltlich mindestens liegen?" - "Kann ich so nicht sagen, schicken Sie mir bitte Ihren Lebenlauf." - "Sehen Sie doch hier? Wie hoch ist das Gehalt mindestens?" - "Lassen Sie uns darüber telefonieren..." Danke aber nein danke. Externer Recruiting-Mitarbeiter eines Konzerns (mit @extern.firma.de-Adresse)

Nachdem ich keine Ausbildung zum Fiae absolviert habe, kann ich zum Antrag direkt nicht viel sagen, aber bitte überprüfe deine Zeitrechnungen. 
Hierbei handelt es sich zwar um keinen großen Fehler, allerdings ist das Leichtsinn, den man im Prinzip vermeiden muss. 

Offen gestanden: Schwierig, ist schließlich dein Projekt und ohne eine akkurate Beschreibung verstehen wir nur Bahnhof.
Was ich deinem Auszug entnehme: Du möchtest eine Art von Typo3-Verwaltung bauen, über die du verschiedene Aktionen vornehmen kannst. Allerdings fehlt mir da ein bisschen (eher: komplett) der wirtschaftliche Aspekt des Ganzen, außer "dass das sonst länger dauert". Da ist gefühlt alles schon in Stein gemeißelt und (wirtschaftliche) Entscheidungen scheinst du im Laufe des Projekts nicht mehr treffen zu müssen. Du entwickelst halt einfach irgendetwas, das ist aber nicht Sinn und Zweck der Projektarbeit. Dazu geht aus deinem Antrag nicht einmal ansatzweise hervor, womit du das Projekt umsetzen möchtest.
Gut, du hast irgendwelche Typo-APIs, immerhin, aber basiert dein Tool auch auf Typo? Irgendein anderes Framework? Datenbankanbindung? Und so weiter.
PS: Die Formulierungen haben bisweilen etwas von fiesem bla bla, mein Lieblingsbeispiel:
Uff. 😕

Rückblickend würde ich die Variante "Schritt - Doku - Schritt - Doku" wählen. Würde mir sicherlich deutlich viel mehr Stress und Zeit ersparen, als erst das Projekt und dann die Dokumentation. (Konnte mir nicht alles merken und musste mir müheseelig meine 0815 - Notizen zusammensuchen).
Wenn du dir viel und leicht merken kannst, kannst du am Ende auch die Doku schreiben. Musst du selbst entscheiden, was für dich besser ist. Eventuell hilft es dir, wenn du dir zu den jeweiligen Steps, Notizen machst. 
-> Deine eigene Wortwahl
-> Den Leitpfaden von deiner IHK unbedingt beachten!
-> Roten Pfaden beibehalten
-> Möglichst präzise und klar schreiben, was du sagen willst. 
-> Möglichst wenig Angriffsfläche für offene Fragen, die eventuell außerhalb deines Themengebietes liegen, zulassen
-> Wissen wovon du sprichst
-> Grammatik und Rechtschreibung (Bin selbst kein Ass, habe es mehrfach korrigieren lassen)
-> 100%iges Vertrauen in deine Arbeit stecken. Klingt blöd, ich weiß. Stell dir vor, du hast die Weisheit, sie nicht. Du möchtest denen es erklären und näher bringen. 
PS: So "blöd" es auch klingt, mir hat es zwecks Aufregung tatsächlich geholfen, als ich mir vorgestellt habe, dass die Prüfer in alten Unterhosen dasitzen und mir zu hören.  Kein Witz, manchen soll das helfen, wenn man daran denkt, wie "blöd" die Prüfer dasitzen und einem einfach nur zuhören. 

Es gibt tausende Seiten und Anwendungen die auf React, Vue, Angular oder sonst was setzten...nur weil ein neuer Hype um Framework XYZ kommt, heißt das nicht, dass so viele jetzt umsteigen.
Umstieg bedeutet Kosten...Unternehmen hassen kosten. Du wirst mit deinem Stack immer irgendwo was finden.
Klar, wenn irgendwas super neues rauskommt, solltest du mal 2 WE investieren um es dir mal anzusehen. Heißt nicht, dass du es können musst. 
Die meisten lernen ein Framework und können relativ schnell Konzepte aus Framework X in Framework Y erkennen.
Desweiteren lernst du IMMER weiter...wir sind in einer Branche in der du nicht einfach einen Stand lernen kannst und das wars. React bringt immer wieder neue Versionen raus...schon musst du lernen was sich geändert hat...kannst ja schlecht die Version von vor 4 Jahren für ein neues Projekt nutzen.
Wie gesagt: Hinter deinem Stack sind große Communities die auch entsprechend die Frameworks pushen und verbessern. Ich würde mir da keinen Kopf machen.

1.) Muss man eine Abmahnung nicht unterschreiben? Wenn ja geh doch mal zum Anwalt für Arbeitsrecht NACHDEM du mit deinen Leuten geklärt hast wofür diese Abmahnung sein soll
2.) Geh niemals an das Telefon eines Kollegen der einen ganz anderen Job hat als du.
3.) und wenn doch lass dir bessere Ausreden einfallen: "Aktuell bin ich der einzige Kollege im Büro und kann hier nicht weg um Sie vor Ort zu unterstützen, aber via Fernwartung kann ich ihnen bestimmt innerhalb von 10 min das Problem beseitigen..... eigentlich bin ich gerade im Projekt und wollte der Urlaubsvertretung ihres Ansprechpartners kurz unter die Arme greifen, kann ihnen daher nur eine Fernwartung anbieten oder die Urlaubsvertretung informieren Sie zurückzurufen...kann aber dauern da heute die Hölle los ist..."
4.) So freundlich wie möglich...und nein schleimen ist nicht freundlich...das merkt dein gegenüber. Tipp um grundsätzlich freundlicher am Telefon zu klingen: Lächel beim telefonieren.... wie oft mich schon Kollegen angesprochen haben: Hey, du meckerst heute schon den ganzen Tag, aber beim telefonieren lächelst du immer...was los?
5.) So emotionslos wie möglich: Manche Kunden legen es auf Streit an, wollen evtl. dir etwas entlocken was du für dich behalten solltest... daher immer über das Technische Problem sprechen.... "Ihre Software ist so scheisse...." "Wo hängt es denn genau?" ... "aber ihre Software ist einfach ein schlechter Witz und der Support grundsätzlich kacke..." "Ich versuche gerade das Problem zu reproduzieren können Sie mir nochmal Schritt für Schritt erklären wie es zu diesem Fehler kommt?" ...... und wenn derjenige zu aufdringlich wird: "Können Sie mir jeden einzelnen Schritt inkl. Screenshot detailliert per Mail beschreiben? Dann kann ich dies so an die Softwareentwicklung weiterreichen, ich kann das aktuell leider nicht reproduzieren...." danach Ticket auf und eine Mail mit diesem Satz nochmal an den Kunden mit dem Vorwort: Wie telefonisch besprochen: und es kann sich kein Kunde rauswinden das du ihm nicht helfen wolltest ...
 
PS: und wenn du den letzten Punkt beherzigst dann sehen deine Foreneinträge professioneller aus und der ein oder andere der sich hier beschwert hat liest sich alles durch und versucht zu helfen
 
 

Eigentlich gut quasi. Ja was jetzt? Dir fehlen 6 Wochen Praktikum, in welchen du den Projekt-Betrieb hättest kennen lernen sollen. Was sagt der Träger der Umschulung zu diesem Zustand?
Eher neu? Oder völlig neu? Was hast du vorher gemacht und worin kennst du dich aus?
 
Du sollst ein betriebliches Problem mit deinen in der Ausbildung erlernten Kompetenzen eines Fachinformatikers Anwendungsentwicklung lösen. Wenn eine Webanwendung dies kann, ja. Wenn es eine Großrechneranwendung kann, dann die. Es muss nur das Problem lösen, so dass der Anforderer damit arbeiten kann.

In dieser heiklen Situation würde ich mich nicht auf eine unbelegbare Aussage egal von wem verlassen, wenn die schriftliche Aussage des zuständigen Prüfungsausschusses mehrfach anders interpretiert wurde.

Der Prüfungsausschuss ist eindeutig:
Dem würde ich Folge leisten, ein neues Projekt finden und die in diesem Thread genannten Ratschläge berücksichtigen.
Auch daran denken, dass der PA Erfahrung mit den Projekten hat und demnach einschätzen kann, ob das Projekt taugt oder nicht. Wenn du jetzt mit "aller Gewalt" das Projekt durchringst und dann aber durchfällst ist auch nichts gewonnen.

Okay ja ich werde heute ja nochmal mit meinem Ausbilder sprechen und dann schauen wir mal was wir finden.