HAHA .. Du bist so genial. Gleich in der EInleitung habe ich mich wiedergefunden. Schepp und Krumm - aber ich wollte diese verdammte Schraube da in der Wand haben (Hatte gerade keinen Bohrer hier ;)). Steckt jetzt komplett verbogen seit über einem halben Jahr in der Wand - und hält! ;)
Auch gute Metapher, denn das passiert wenn man das falsche Werkzeug für die falsche Arbeit anwendet. Es wird zwar irgendwie gehen, optimal ist es net :D
Hey, es ist ein sehr interessantes Video und ich wollte gerne auf eine Punkte (vielleicht auch etwas kritisch) zu sprechen kommen :) Zum ersten, würde ich gerne wissen, warum nur JSON in einer DB gespeichert werden sollte, bzw. was damit konkret gemeint ist. Denn theoretisch kannst du auch XML einfach in die Datenbank packen. Deswegen würde ich das nicht als Nachteil für JSON werten. Zum zweiten muss man sagen, dass PHP das ganze an sich nicht direkt nativ mitliefert, sondern ebenfalls eine Library (auf anderer Ebene) mitinstalliert werden muss. Außerdem ist Swagger/Open API immer mehr vertreten, was genauso gut zur Validierung von JSON dienen kann und womit sogar noch einen Schritt weiter gegangen werden kann, undzwar Request Validierung. Also eher ein Vorteil für JSON/Open API. Gibt es bezüglich der Performance vielleicht Vergleichswerte, wie viel schneller die Verarbeitung von XML stattfindet? Wäre auf jeden Fall interessant zu sehen und wie sich dies mit Zunahme der Datengrösse skaliert. Außerdem finde ich das Beispiel mit Doctrine Models (was für mich repository und findAllProducts impliziert haben) hier sehr ungünstig gewählt, da immer noch Proxy-Klassen drunter liegen und es bei beiden nicht einfach ist, das Objekt in das jeweilige Format zu serialisieren. Außerdem kann JSON auch wunderbar mit stdClass umgehen, was bedeutet, dass man nicht zwangsweise ein Array aufbauen muss, es ist aber der durchaus üblichere Weg. Der Weg über ein Template zu gehen bei XML ist erstmal keine doofe Idee, allerdings kannst du diesen Weg ebenfalls für JSON nutzen. Was ich hier bei dem Beispiel mit dem XML Writer auch unpassend finde ist die Nutzung einer nicht näher definierten „asXml“ Funktion, wäre interessant was innerhalb dieser noch für Sachen passieren. Auch interessant wäre zu wissen, wie man ein File Segmentweise Parsen würde, weil du bei Minute 5:50 gesagt hast, dass man eine große Datei nach und nach Auslesen kann und dann verarbeitet. Dies würde hier evtl. den Geschwindigkeitsvorteil von XML beim Verarbeiten wieder zu Nichte machen. Es gibt als Gegenspieler zu XPath auch JSONPath, wenn das wirklich benötigt wird, aber vielleicht auch nicht ganz so performant. Den Punkt würde ich deswegen XML gönnen :) Bei dem Escaping von JSON habe ich Tatsache noch nie Probleme gehabt, tatsächlich finde ich hier das Arbeiten mit XML wesentlich unangenehmer, da du meistens explizit festlegen musst, dass du als value cdata nutzen möchtest. Das macht json_encode automatisch für dich :) Sorry für den vielen Text, ich bin bereit für Gegenstimmen! ;)
Hey danke für das Feedback, alles valide Punkte und man soll ja auch diskutieren können. Am Anfang mit JSON das sollte nur eine Anspielung sein auf den Datentyp JSON in MYSQL. Klar kann man auch XML in einer DB speichern, niemand würde es aber machen da eine Datei besser dafür gemacht ist. Bei JSON sehe ich das halt immer mehr und mehr in kommen dass man in SQL statements Dinge sieht wie WHERE field->"$.somevalue" = irgendwas . Dass mysql JSON Field hat und man immer mehr und mehr extreme Verwendungsbeispiele davon sieht, zeigt mir wie verrückt alle nach JSON sind :D Ich weiß das PHP intern LibXML verwedet, das gleiche gilt auch für die JSON Library in PHP. Aber die LibXML bietet halt mehr möglichkeiten an, gerade im Bereich validierung. Swagger und Open API sind mir natürlich auch bekannt, arbeite ja täglich damit. Aber auf der Consumer Seite muss ich extra ein Package installieren um eine Validierung durchzuführen. Aus Erfahrung kann ich sagen dass Entwickler immer den Weg gehen, der mit geringsten Wiederstand. Sprich es wird nur dann Validiert wenn es Explizit danach gefragt wird, bzw verlangt. Genau mit diesem Gedanken werden auch die OpenApi erstellt. Auch nur "Steifmüterlich". Die Performance merkst du eigentlich nur im Arbeitsspeicher, bei einem JSON objekt musst du das komplette Objekt reinladen in eine Variable. Der XML Reader nutzt wie bei fopen einen Zeiger auf ein element und kann dann weiter springen zum Kind Element oder nächsten Element. Du siehst es auch schön am Memory Usage. Du liest ein Wert aus der XML aus, speicherst es in DB und kannst weiter den nächsten Auslesen. Wenn dein Server aber ein 3GB JSON File kriegt, gibts erstmal ein Absturzt, du kannst eine JSON datei nicht ohne weiteres splitten. Das heißt deine API muss eine Paginierungsmöglichkeit einbuauen oder einen Delta, was dann wiederum extra Logik auf verbraucher und anbieter Seite bedeutet. XML Kann man in einem Rutsch befüllen, downloaden und einlesen ohne groß arbietsspeicher zu verwenden. Das einlesen einer Großen datei geht wie gesagt sehr schnell denn es wird immer nur ein XML element eingelesen. Bei pagnierten Requests habe ich das Problem, wie soll ich mich verhalten wenn cih nach page 25 von 100 zwei Datensätze nicht richtig eingelesen habe? lese ich nur diese eine page ein? was wenn ich 25 pages eingelesen habe und auf page 1 schon daten dazu gekommen ist? und so weiter. vom code her ist es einfacher eine Riesen XML DAtei zu nehmen die ein mal zu erzeugen und den stand einzufrieren und dann anschließend in einem Rutsch zu übernehmen. Du hast sozusagen nur die eine Wahrheit und somit ist dein code einfacher aufgebaut. Wegen Escaping. Ich nutze für Doctrine MIgration meinen SQL client der mir einen INSERT INTO statement generiert. (In heideisql zwei spalten markeiren und INSERT INTO generieren) wenn du da ein JSON feld hast, werden dort hochkommas escaped, das musst du wiederum in eine PHP MIgration file übertragen und später wenn die MIgration dann auf Produktivsystem ausgeführt wird, fehlen im JSON feld nacher immer irgendwelche Daten. du musst das jedes Mal bedenken und drauf achten. Ist ein Luxus problem aber neft ungemein :D Wenn das JSON Feld noch Dateipfade hat wird es richtig hässlich. in doctrine migration im SQL hast du vier backslashes, damit nach der migration nur ein backslash in die DB landet. Und deshalb bin ich der Meinung dass wenn man einen Fullimport von Systemen hat, dann sollte man lieber XML nehmen.
danke für das video. eine frage, ich suche einen ausbildungsplatz zum fa anwendungsentwickler und hab gesehen, dass viele agenturen in meiner umgebung die azubis während ihrer ausbildung zum typo3 entwickeln ausbilden. sollte man um typo3 zu entwickeln, erst einmal die grund lagen der web entwicklung kennenlernen? ich finde typo3 ein ziemlich kompliziertes cms
Also typo3 wird und kann dir sicherlich nicht direkt im ersten Ausbildungsjahr beigebracht werden, vermutlich wirst du in der Ausbildung das erste und zweite Jahr die Grundlagen von der Webentwicklung lernen. Klar ist Typo3 nicht einfach, man kann auch nicht erwarten ohne einer Ausbildung so ein CMS zu erlernen. Wenn es einfach wäre dann wäre unser Beruf als Informatiker obsolet. Es ist also völlig okay dass es für jetzt noch sehr kompliziert erscheint und nein du wirst sicherlich nicht NUR das CMS lernen in der Ausbildung Typo3 nutzt auch das Symfony Framework und ich denke davon wirst du generell sehr viel Profitieren.
Wir haben übrigens auch ein Discord (auf dem Kanalbanner unten Rechts ist der Einladungslink) da sind viele Informatiker aus der Webentwicklung und wenn mal nicht weiterkommst, schadet es nicht jemanden zu haben den man direkt fragen kann ;)
Was heißt hier "noch" überall ist XML im Einsatz. Mein Symfony Projekt ezeugt XML für die Konfiguration. Wenn ich große Datenmengen exportieren muss nutze ich XML. RSS Feeds muss ich auch einlesen. XML ist überall
@@heikoimburo7509 ah sorry, misverstädnis, nein XSLT habe ich viel zu spät entdeckt, die Logiken habe ich in PHP umgesetzt und via Xpath die Daten herausgesucht. Als ich über XSLT das erste Mal gehört habe, hatte ich schon keine Usecases mehr wo ich eine XML editieren musste sonsten nur komplett einlesen. Wenn aber wieder der Fall aufkommt dann werden schon XSLT erst mal Probieren:D
Sehe ich tatsächlich vollkommen anders. Da du primär über APIs redest geht es doch hauptsächlich um eine Schnittstelle, welche reine Daten übertragen soll - hierfür ist JSON explizit gedacht. XML hat sicherlich eine höhere Mächtigkeit, wie du es ja beschreibst, jedoch sind APIs primär nicht für diese Funktionalitäten gedacht. Im allgemeinen finde ich es auch sinnvoller, wenn der angefragte Content-Type auch geliefert wird. Sprich, ob ich als Client der API mit JSON, XML oder anderen Formaten arbeiten möchte, sollte bei mir liegen. Deine Argumentationen kann ich wie gesagt vollständig verstehen - sehe ich aber in der modernen Web-Entwicklung immer mehr die Anforderung (was ich persönlich gut heiße), dass Schnittstellen-Dokumente wie eine Swagger/OpenAPI bereitgestellt werden sollen. Aus diesen Dokumenten ist es ja möglich automatisiert die entsprechenden Models generieren zu lassen für jede Sprache die man benötigt - oder auch mit zum Beispiel Mustache-Templates einfach erweiterbar. Alles in allem würde ich sagen, kann ich verstehen, dass man in bestimmten Anwendungsbereichen auf XML setzen möchte, um ein Datenformat zu haben, welches vielseitige Möglichkeiten besitzt - andererseits haben wir im Web hauptsächlich die Aufgabe, reine Daten zwischen Systemen zu übertragen - hier benötigt es nicht den Overhead, den XML mit sich bringt. Und abschließend wollte ich noch da lassen, dass du für XML die Mächtigkeit von XPath erwähnt hast - soweit auch korrekt, jedoch gibt es auch Programme für JSON-Dokumente wie jq auf der Kommandozeile - auch ein Tool, welches C geschrieben ist ;-)
Mir sind die Dinge mit Swagger und Open APi bekannt, auch dass es json schema gibt. Es bei JSON aber gefühlt so dass die meisten es nicht benutzen oder es irgendwie auto generieren was dann zu noch mehr Problemen führt und auf der Endseite muss ich mir noch weitere Tools installieren um das ganze zu Prüfen. Es ist nicht nativ eingebaut wie es der Fall in der XML Library ist. Die LibXML liefert alles sofort mit. Das größte Problem was ich mit JSON habe ist dass ich das gesamte Dokument parsen in Arbeitsspeicher laden muss und somit der Overhead beim Client in Rechenzeit besteht. Ein wenig mehr Text im Response ist meiner Meinung nach nicht der Rede wert da ja auch responses gut gezipped werden können. Wir benutzen zb in riesen Online Shops (Tamaris Shoe Store) XMLs, mit einem XML Writer können wir uns an einen Knotenpunkt im Dokument hinbewegen und einen Eintrag hinzufügen ohne jetzt ein komplettes Dokument einzulesen. Dann hast du eine 3-5 GB XML Datei. Im anderen System wird diese Heruntergeladen via curl und liegt erstmal als Datei vor und auch diese kann mit mit XMLReader einlesen und das Zeilenweise. Wieder entsteht beim Verbraucher der API kein Overhead im Arbeitsspeicher. Hingegen habe auch mit größeren APIs zu tun die Pagination haben, ich muss mehrere Requests versenden, muss mir merken welche Seiten ich bereits bearbeitet habe, welche Seiten nicht funktioniert haben. Ein Delta dafür Programmieren um zu schauen was sich verändert hat usw. Ich finde JSON ist super wenn es um kleine Datenmengen geht und wenn man im JavaScript Context arbeitet. Wenn ich aber eine API habe eigentlich eine Datebank Replikation aus einem anderen System ist, dann ist XML viel besser dafür geeignet.
@@VitalijMik Wenn man mit einer API arbeitet, die eigentlich eine Datenbank-Replikation ist, ist meines Erachtens nach etwas architektonisch ziemlich schief gelaufen :-D Ja, ich weiß, dass man immer wieder solche Dinge tun muss, weil niemand die alten Legacy-Systeme erneuern möchte - trotzdem sollte man meines Erachtens nach versuchen Systeme zu modernisieren und damit auch die Architektur hinter all dem =) Das System, welche die 3-5 GB Daten (im XML Format) hält, sollte als datenverwaltendes System meiner Meinung nach sich darum kümmern, dass die Integrität der Daten erhalten bleibt und auf Anfrage Berechtigter (zum Beispiel durch eigene Logik oder vorgeschalteten Diensten) nur benötigte Daten liefern und nicht immer alles, was es gibt - klar könnte man hier nun argumentieren, dass es einen Overhead durch eine gestiegene Request-Menge bei trotzdem großen Datenmengen geben wird, jedoch sind solch simple Systeme auch leichter skalier- und orchestrierbar (Thema Microservice-Architekturen).
@@diggerdadon nein da ist nichts schief gelaufen, du hast einen Großen Laden da kommen Produkte über wareneingang rein und sind in einem riesen System geschrieben was aus C# und ABAB usw zusammengebaut ist mit JAVA drin. Und dann hast du auf der anderen Seite ein online Shop was seine eigene Daten hat. die 3-5 GB Daten sind richtig, wir sprechen hier von einem größten Schuh verkäufer der DACH länder. Der Aufwand um herauszufinden warum am ende im Shop etwas angezeigt wird oder eben nicht ist viel einfacher wenn du einen Datenbestand hast und da stehen die Daten drin. Microservice Architektur habe ich durch. Schrecklich fürs aufsetzen mit den ganzen Docker Container, schrecklich zu debuggen wenn einer Daten sendet, der andere die verarbeitet und weiterreicht und am ende niemand mehr weiß wieso die da so stehen. Eine Riesen Datei, da stehen alle Daten drin, wird in 10 MInuten reinimportiert. Kannst auch wunderbar skalieren, legst die Datei an einer Stelle ab und X systeme bedienen sich der Datei und können sogar parallel die daten einlesen. Wie gesagt das ist das wovon ich am Anfang gesprochen habe, ein Tool um alle Probleme zu lösen ;)
Es gibt ja sogar XML query language. Was ähnliches wie SQL funktioniert um Inhalte zu suchen und es gibt java Datenbanken die das auch erlauben. Damit kann man daten in der db versionieren
Ich versuche mir gerade eine Library zu schreiben mit dessen Hilfe ich in meinem Spiel erzeugte Objekte speichern kann. Allerdings habe ich absolut keine Ahnung welches Datenformat dafür am besten geeignet wäre. Es müssen sehr viele Parameter pro Objekt gespeichert werden und das bei nicht wenig Objekten. Zudem müssen diese Dateien dann auch noch verschlüsselt werden, damit die Spieler nicht einfach im Ordner neue Objekte anlegen oder vorhandene Objekte verändern können. (Das ganze ist für eine Offline-Speicherung weswegen ich keine Datenbank verwenden möchte/kann). Kann mir da vielleicht jemand weiterhelfen und mir einen Tipp geben welches Datenformat am besten dafür geeignet sein könnte?
es gibt keine Sicherung, wenn die Daten da liegen, wird es irgendwann immer jemanden geben der die Daten entschlüsseln kann. Viel Schlimmer wird es sein dass deine Performance da drunter leiden wird und du wirst viel Zeit dafür verschwenden und nicht am eigentlich spiel arbeiten. Ich würde sagen du verwendest das was du am besten verstehst und bemühst es gar nicht zu verschlüsseln etc ein Spiel zu entwickeln ist schon ein Task der nicht ohne ist, konzentriere dich lieber da drauf
Ich experimentiere schon wieder. Dieses Mal mit dynamischen Loops, also Loops deren Grundlagen sich während des Loops ändern kann. zB wegen Einschüben. Der xml-Pointer hört sich interessant an.
ja diese Pointer kommen aus dem Iterator Pattern, damit kannst du eine Schleife in beide Richtungen durchgehen wegen dem Pointer. Ich habe dazu sogar ein Video auf meinem Kanal ;)
Interessante Punkte. Irgendwie ist mir XML immer zu fummelig. Wobei wenn man es öfter nutzt, mit der Häufigkeit auch die Gewohnheit und Normalität käme. Danke fürs Video.
@@VitalijMik ich glaub ich hab XML einfach nie verwendet und wollts auch nie verwenden. Weils einfach keinen Spaß macht sich mit sowas zu beschäftigen. JSON dagegen versteht eigentlich jeder nach wenigen Minuten und Daten mit PHP zu verarbeiten ist ein Kinderspiel. Man kanns auch sofort lesen... Mir war auch bis zu diesem Video gar nicht bewusst das XML überhaupt noch relevant ist. Für mich war das eben einfach ein verstaubtes Relikt das von manchen Entwicklern verwendet wird weil sie das halt immer schon verwendet haben^^
@@Meinungsmacher ja das denken viele, deshalb habe ich das video gemacht. JSON hat einen großen nachteil bei großen Datenmengen. Übrigens brauchst du gute XML Ketnisse wenn du auch daten aus einem Word Dokument auslesen willst. Dann gibt es RSS Feeds diese sind auch mit XML Aufgebaut. Wenn du bei Google größere Produkte hinterlegen willst mit Bewertungen, erwartet Google auch XML. Im Wissenschaftlichen Bereich wenn man Paper veröffentlicht, da wird XML sehr stark benutzt weil es maschinenlesbar ist. Ich habe in den letzten 8 Jahren sehr viel mit XML gearbeitet und kann nicht nachvollziehen wieso man damit nicht gearbeitet hat :D Das schöne ist, lernst du einmal mit XML umzugehen, dann ist das Parsen der Daten aus einem HTML Dokument gar kein Problem mehr.
Oh, YAML ist schon extrem tricky zu lesen. nur mit Einrückungen zu arbeiten ist schon sehr sportlich. Ich tue mich damit doch oft sehr schwer und wenn ich nicht über Symfony so sehr dazu gezwungen würde, dann wäre es nicht mein Format. Für einfache Configs ja, aber wenn es etwas komplexer wird ist das schon tricky
Achja - nochwas vergessen. Solltest Du mal ein Buch mit all Deinen Tipps schreiben - dann denke bitte an mich. Ich hätte bitte gerne das erste Exemplar - signiert und mit Herzerl ;)
Ich finde das ist nicht wirklich hilfreich für mich. Habe mich Jahrelang mit XML herumgeschlagen als ich in der EDI tätig war. Niemand gab mir eine gültes XSD. Ich fand das alles scheisse. PHP kenne ich nicht. Was ich davon gehöt habe, macht mir keine Lust das auch nur aus der Ferne anzuschauen. Ich glaube für die Probleme, die du ansprichst, ist GRPC die Zukunft.
tut mir echt leid das zu hören, ich habe im Gegenteil nur gutes von XML erlebt. Nur dass die Dokumentationen halt davon hässlich ausgesehen haben. Was auch immer du über PHP gehört hast ist sicherlich veraltet und ich finde nur derjenige kann schlecht über eine Programmiersprache reden der sie auch jeden Tag einsetzt, ansonsten hat er keine Ahnung. Schau auf das Datum von deinen Quellen, als IT-ler müsstest du wissen dass alles was älter als ein Jahr ist, ist nicht mehr gültig ;) Kann sein dass die GRPC die Zukunft sein wird, solange ich aber in Gegenwart lebe muss ich das verwenden was da ist und wenn sich GRPC durchgesetzt hat, mach ich ein Video darüber wie cool es ist ;)
Sehr schön mein Freund vielen Dank
Danke fürs Kommentar:D
HAHA .. Du bist so genial. Gleich in der EInleitung habe ich mich wiedergefunden. Schepp und Krumm - aber ich wollte diese verdammte Schraube da in der Wand haben (Hatte gerade keinen Bohrer hier ;)). Steckt jetzt komplett verbogen seit über einem halben Jahr in der Wand - und hält! ;)
Auch gute Metapher, denn das passiert wenn man das falsche Werkzeug für die falsche Arbeit anwendet. Es wird zwar irgendwie gehen, optimal ist es net :D
Danke, wahre Worte...
Dankeschön
...aus berufenem Mund...sorry den musste ich jetzt einfach mal nehmen hehe
Hey, es ist ein sehr interessantes Video und ich wollte gerne auf eine Punkte (vielleicht auch etwas kritisch) zu sprechen kommen :)
Zum ersten, würde ich gerne wissen, warum nur JSON in einer DB gespeichert werden sollte, bzw. was damit konkret gemeint ist. Denn theoretisch kannst du auch XML einfach in die Datenbank packen. Deswegen würde ich das nicht als Nachteil für JSON werten.
Zum zweiten muss man sagen, dass PHP das ganze an sich nicht direkt nativ mitliefert, sondern ebenfalls eine Library (auf anderer Ebene) mitinstalliert werden muss. Außerdem ist Swagger/Open API immer mehr vertreten, was genauso gut zur Validierung von JSON dienen kann und womit sogar noch einen Schritt weiter gegangen werden kann, undzwar Request Validierung. Also eher ein Vorteil für JSON/Open API.
Gibt es bezüglich der Performance vielleicht Vergleichswerte, wie viel schneller die Verarbeitung von XML stattfindet? Wäre auf jeden Fall interessant zu sehen und wie sich dies mit Zunahme der Datengrösse skaliert. Außerdem finde ich das Beispiel mit Doctrine Models (was für mich repository und findAllProducts impliziert haben) hier sehr ungünstig gewählt, da immer noch Proxy-Klassen drunter liegen und es bei beiden nicht einfach ist, das Objekt in das jeweilige Format zu serialisieren. Außerdem kann JSON auch wunderbar mit stdClass umgehen, was bedeutet, dass man nicht zwangsweise ein Array aufbauen muss, es ist aber der durchaus üblichere Weg.
Der Weg über ein Template zu gehen bei XML ist erstmal keine doofe Idee, allerdings kannst du diesen Weg ebenfalls für JSON nutzen.
Was ich hier bei dem Beispiel mit dem XML Writer auch unpassend finde ist die Nutzung einer nicht näher definierten „asXml“ Funktion, wäre interessant was innerhalb dieser noch für Sachen passieren.
Auch interessant wäre zu wissen, wie man ein File Segmentweise Parsen würde, weil du bei Minute 5:50 gesagt hast, dass man eine große Datei nach und nach Auslesen kann und dann verarbeitet. Dies würde hier evtl. den Geschwindigkeitsvorteil von XML beim Verarbeiten wieder zu Nichte machen.
Es gibt als Gegenspieler zu XPath auch JSONPath, wenn das wirklich benötigt wird, aber vielleicht auch nicht ganz so performant. Den Punkt würde ich deswegen XML gönnen :)
Bei dem Escaping von JSON habe ich Tatsache noch nie Probleme gehabt, tatsächlich finde ich hier das Arbeiten mit XML wesentlich unangenehmer, da du meistens explizit festlegen musst, dass du als value cdata nutzen möchtest. Das macht json_encode automatisch für dich :)
Sorry für den vielen Text, ich bin bereit für Gegenstimmen! ;)
Hey danke für das Feedback, alles valide Punkte und man soll ja auch diskutieren können. Am Anfang mit JSON das sollte nur eine Anspielung sein auf den Datentyp JSON in MYSQL. Klar kann man auch XML in einer DB speichern, niemand würde es aber machen da eine Datei besser dafür gemacht ist. Bei JSON sehe ich das halt immer mehr und mehr in kommen dass man in SQL statements Dinge sieht wie WHERE field->"$.somevalue" = irgendwas . Dass mysql JSON Field hat und man immer mehr und mehr extreme Verwendungsbeispiele davon sieht, zeigt mir wie verrückt alle nach JSON sind :D
Ich weiß das PHP intern LibXML verwedet, das gleiche gilt auch für die JSON Library in PHP. Aber die LibXML bietet halt mehr möglichkeiten an, gerade im Bereich validierung. Swagger und Open API sind mir natürlich auch bekannt, arbeite ja täglich damit. Aber auf der Consumer Seite muss ich extra ein Package installieren um eine Validierung durchzuführen. Aus Erfahrung kann ich sagen dass Entwickler immer den Weg gehen, der mit geringsten Wiederstand. Sprich es wird nur dann Validiert wenn es Explizit danach gefragt wird, bzw verlangt. Genau mit diesem Gedanken werden auch die OpenApi erstellt. Auch nur "Steifmüterlich".
Die Performance merkst du eigentlich nur im Arbeitsspeicher, bei einem JSON objekt musst du das komplette Objekt reinladen in eine Variable. Der XML Reader nutzt wie bei fopen einen Zeiger auf ein element und kann dann weiter springen zum Kind Element oder nächsten Element. Du siehst es auch schön am Memory Usage. Du liest ein Wert aus der XML aus, speicherst es in DB und kannst weiter den nächsten Auslesen. Wenn dein Server aber ein 3GB JSON File kriegt, gibts erstmal ein Absturzt, du kannst eine JSON datei nicht ohne weiteres splitten. Das heißt deine API muss eine Paginierungsmöglichkeit einbuauen oder einen Delta, was dann wiederum extra Logik auf verbraucher und anbieter Seite bedeutet. XML Kann man in einem Rutsch befüllen, downloaden und einlesen ohne groß arbietsspeicher zu verwenden.
Das einlesen einer Großen datei geht wie gesagt sehr schnell denn es wird immer nur ein XML element eingelesen. Bei pagnierten Requests habe ich das Problem, wie soll ich mich verhalten wenn cih nach page 25 von 100 zwei Datensätze nicht richtig eingelesen habe? lese ich nur diese eine page ein? was wenn ich 25 pages eingelesen habe und auf page 1 schon daten dazu gekommen ist? und so weiter. vom code her ist es einfacher eine Riesen XML DAtei zu nehmen die ein mal zu erzeugen und den stand einzufrieren und dann anschließend in einem Rutsch zu übernehmen. Du hast sozusagen nur die eine Wahrheit und somit ist dein code einfacher aufgebaut.
Wegen Escaping. Ich nutze für Doctrine MIgration meinen SQL client der mir einen INSERT INTO statement generiert. (In heideisql zwei spalten markeiren und INSERT INTO generieren) wenn du da ein JSON feld hast, werden dort hochkommas escaped, das musst du wiederum in eine PHP MIgration file übertragen und später wenn die MIgration dann auf Produktivsystem ausgeführt wird, fehlen im JSON feld nacher immer irgendwelche Daten. du musst das jedes Mal bedenken und drauf achten. Ist ein Luxus problem aber neft ungemein :D Wenn das JSON Feld noch Dateipfade hat wird es richtig hässlich. in doctrine migration im SQL hast du vier backslashes, damit nach der migration nur ein backslash in die DB landet.
Und deshalb bin ich der Meinung dass wenn man einen Fullimport von Systemen hat, dann sollte man lieber XML nehmen.
danke für das video.
eine frage, ich suche einen ausbildungsplatz zum fa anwendungsentwickler und hab gesehen, dass viele agenturen in meiner umgebung die azubis während ihrer ausbildung zum typo3 entwickeln ausbilden. sollte man um typo3 zu entwickeln, erst einmal die grund lagen der web entwicklung kennenlernen? ich finde typo3 ein ziemlich kompliziertes cms
Also typo3 wird und kann dir sicherlich nicht direkt im ersten Ausbildungsjahr beigebracht werden, vermutlich wirst du in der Ausbildung das erste und zweite Jahr die Grundlagen von der Webentwicklung lernen.
Klar ist Typo3 nicht einfach, man kann auch nicht erwarten ohne einer Ausbildung so ein CMS zu erlernen. Wenn es einfach wäre dann wäre unser Beruf als Informatiker obsolet. Es ist also völlig okay dass es für jetzt noch sehr kompliziert erscheint und nein du wirst sicherlich nicht NUR das CMS lernen in der Ausbildung
Typo3 nutzt auch das Symfony Framework und ich denke davon wirst du generell sehr viel Profitieren.
Wir haben übrigens auch ein Discord (auf dem Kanalbanner unten Rechts ist der Einladungslink) da sind viele Informatiker aus der Webentwicklung und wenn mal nicht weiterkommst, schadet es nicht jemanden zu haben den man direkt fragen kann ;)
@@VitalijMik cool danke
XSL Transformation ist auch ein großer Pluspunkt für XML. Verwendest du sowas noch? Tolles Video weiter so.
Was heißt hier "noch" überall ist XML im Einsatz. Mein Symfony Projekt ezeugt XML für die Konfiguration. Wenn ich große Datenmengen exportieren muss nutze ich XML. RSS Feeds muss ich auch einlesen. XML ist überall
Ich meinte eigentlich, ob Du noch XSLT-Templates verwendest.
@@heikoimburo7509 ah sorry, misverstädnis, nein XSLT habe ich viel zu spät entdeckt, die Logiken habe ich in PHP umgesetzt und via Xpath die Daten herausgesucht. Als ich über XSLT das erste Mal gehört habe, hatte ich schon keine Usecases mehr wo ich eine XML editieren musste sonsten nur komplett einlesen. Wenn aber wieder der Fall aufkommt dann werden schon XSLT erst mal Probieren:D
Sehe ich tatsächlich vollkommen anders. Da du primär über APIs redest geht es doch hauptsächlich um eine Schnittstelle, welche reine Daten übertragen soll - hierfür ist JSON explizit gedacht. XML hat sicherlich eine höhere Mächtigkeit, wie du es ja beschreibst, jedoch sind APIs primär nicht für diese Funktionalitäten gedacht.
Im allgemeinen finde ich es auch sinnvoller, wenn der angefragte Content-Type auch geliefert wird. Sprich, ob ich als Client der API mit JSON, XML oder anderen Formaten arbeiten möchte, sollte bei mir liegen.
Deine Argumentationen kann ich wie gesagt vollständig verstehen - sehe ich aber in der modernen Web-Entwicklung immer mehr die Anforderung (was ich persönlich gut heiße), dass Schnittstellen-Dokumente wie eine Swagger/OpenAPI bereitgestellt werden sollen. Aus diesen Dokumenten ist es ja möglich automatisiert die entsprechenden Models generieren zu lassen für jede Sprache die man benötigt - oder auch mit zum Beispiel Mustache-Templates einfach erweiterbar.
Alles in allem würde ich sagen, kann ich verstehen, dass man in bestimmten Anwendungsbereichen auf XML setzen möchte, um ein Datenformat zu haben, welches vielseitige Möglichkeiten besitzt - andererseits haben wir im Web hauptsächlich die Aufgabe, reine Daten zwischen Systemen zu übertragen - hier benötigt es nicht den Overhead, den XML mit sich bringt.
Und abschließend wollte ich noch da lassen, dass du für XML die Mächtigkeit von XPath erwähnt hast - soweit auch korrekt, jedoch gibt es auch Programme für JSON-Dokumente wie jq auf der Kommandozeile - auch ein Tool, welches C geschrieben ist ;-)
Mir sind die Dinge mit Swagger und Open APi bekannt, auch dass es json schema gibt. Es bei JSON aber gefühlt so dass die meisten es nicht benutzen oder es irgendwie auto generieren was dann zu noch mehr Problemen führt und auf der Endseite muss ich mir noch weitere Tools installieren um das ganze zu Prüfen. Es ist nicht nativ eingebaut wie es der Fall in der XML Library ist. Die LibXML liefert alles sofort mit.
Das größte Problem was ich mit JSON habe ist dass ich das gesamte Dokument parsen in Arbeitsspeicher laden muss und somit der Overhead beim Client in Rechenzeit besteht. Ein wenig mehr Text im Response ist meiner Meinung nach nicht der Rede wert da ja auch responses gut gezipped werden können.
Wir benutzen zb in riesen Online Shops (Tamaris Shoe Store) XMLs, mit einem XML Writer können wir uns an einen Knotenpunkt im Dokument hinbewegen und einen Eintrag hinzufügen ohne jetzt ein komplettes Dokument einzulesen. Dann hast du eine 3-5 GB XML Datei. Im anderen System wird diese Heruntergeladen via curl und liegt erstmal als Datei vor und auch diese kann mit mit XMLReader einlesen und das Zeilenweise. Wieder entsteht beim Verbraucher der API kein Overhead im Arbeitsspeicher.
Hingegen habe auch mit größeren APIs zu tun die Pagination haben, ich muss mehrere Requests versenden, muss mir merken welche Seiten ich bereits bearbeitet habe, welche Seiten nicht funktioniert haben. Ein Delta dafür Programmieren um zu schauen was sich verändert hat usw.
Ich finde JSON ist super wenn es um kleine Datenmengen geht und wenn man im JavaScript Context arbeitet. Wenn ich aber eine API habe eigentlich eine Datebank Replikation aus einem anderen System ist, dann ist XML viel besser dafür geeignet.
@@VitalijMik Wenn man mit einer API arbeitet, die eigentlich eine Datenbank-Replikation ist, ist meines Erachtens nach etwas architektonisch ziemlich schief gelaufen :-D Ja, ich weiß, dass man immer wieder solche Dinge tun muss, weil niemand die alten Legacy-Systeme erneuern möchte - trotzdem sollte man meines Erachtens nach versuchen Systeme zu modernisieren und damit auch die Architektur hinter all dem =)
Das System, welche die 3-5 GB Daten (im XML Format) hält, sollte als datenverwaltendes System meiner Meinung nach sich darum kümmern, dass die Integrität der Daten erhalten bleibt und auf Anfrage Berechtigter (zum Beispiel durch eigene Logik oder vorgeschalteten Diensten) nur benötigte Daten liefern und nicht immer alles, was es gibt - klar könnte man hier nun argumentieren, dass es einen Overhead durch eine gestiegene Request-Menge bei trotzdem großen Datenmengen geben wird, jedoch sind solch simple Systeme auch leichter skalier- und orchestrierbar (Thema Microservice-Architekturen).
@@diggerdadon nein da ist nichts schief gelaufen, du hast einen Großen Laden da kommen Produkte über wareneingang rein und sind in einem riesen System geschrieben was aus C# und ABAB usw zusammengebaut ist mit JAVA drin. Und dann hast du auf der anderen Seite ein online Shop was seine eigene Daten hat. die 3-5 GB Daten sind richtig, wir sprechen hier von einem größten Schuh verkäufer der DACH länder.
Der Aufwand um herauszufinden warum am ende im Shop etwas angezeigt wird oder eben nicht ist viel einfacher wenn du einen Datenbestand hast und da stehen die Daten drin. Microservice Architektur habe ich durch. Schrecklich fürs aufsetzen mit den ganzen Docker Container, schrecklich zu debuggen wenn einer Daten sendet, der andere die verarbeitet und weiterreicht und am ende niemand mehr weiß wieso die da so stehen.
Eine Riesen Datei, da stehen alle Daten drin, wird in 10 MInuten reinimportiert. Kannst auch wunderbar skalieren, legst die Datei an einer Stelle ab und X systeme bedienen sich der Datei und können sogar parallel die daten einlesen.
Wie gesagt das ist das wovon ich am Anfang gesprochen habe, ein Tool um alle Probleme zu lösen ;)
XSD und XSL sind einfach klasse. Ich denke genau wie du.
Es gibt ja sogar XML query language. Was ähnliches wie SQL funktioniert um Inhalte zu suchen und es gibt java Datenbanken die das auch erlauben. Damit kann man daten in der db versionieren
Ich versuche mir gerade eine Library zu schreiben mit dessen Hilfe ich in meinem Spiel erzeugte Objekte speichern kann. Allerdings habe ich absolut keine Ahnung welches Datenformat dafür am besten geeignet wäre. Es müssen sehr viele Parameter pro Objekt gespeichert werden und das bei nicht wenig Objekten. Zudem müssen diese Dateien dann auch noch verschlüsselt werden, damit die Spieler nicht einfach im Ordner neue Objekte anlegen oder vorhandene Objekte verändern können. (Das ganze ist für eine Offline-Speicherung weswegen ich keine Datenbank verwenden möchte/kann). Kann mir da vielleicht jemand weiterhelfen und mir einen Tipp geben welches Datenformat am besten dafür geeignet sein könnte?
es gibt keine Sicherung, wenn die Daten da liegen, wird es irgendwann immer jemanden geben der die Daten entschlüsseln kann. Viel Schlimmer wird es sein dass deine Performance da drunter leiden wird und du wirst viel Zeit dafür verschwenden und nicht am eigentlich spiel arbeiten.
Ich würde sagen du verwendest das was du am besten verstehst und bemühst es gar nicht zu verschlüsseln etc ein Spiel zu entwickeln ist schon ein Task der nicht ohne ist, konzentriere dich lieber da drauf
@@VitalijMik Danke für die schelle Rückmeldung. 😇
Ich experimentiere schon wieder. Dieses Mal mit dynamischen Loops, also Loops deren Grundlagen sich während des Loops ändern kann. zB wegen Einschüben. Der xml-Pointer hört sich interessant an.
ja diese Pointer kommen aus dem Iterator Pattern, damit kannst du eine Schleife in beide Richtungen durchgehen wegen dem Pointer. Ich habe dazu sogar ein Video auf meinem Kanal ;)
@@VitalijMik , sehr inspirierend. Heißt das irgendwas mit Pointer?
@@MeinDeutschkurs nein Iterator Pattern
@@VitalijMik , danke!
Interessante Punkte. Irgendwie ist mir XML immer zu fummelig. Wobei wenn man es öfter nutzt, mit der Häufigkeit auch die Gewohnheit und Normalität käme. Danke fürs Video.
Wenn man HTML bereits in seinem Projekt generiert, braucht man ja nur ein paar andere Tags und schon ist es das selbe ;)
Ich mag xml nicht.
@@sven2529 was hat dir denn XML angetan dass du es nicht magst?
XML is für mich ein Relikt aus der Steinzeit^^
warum?
@@VitalijMik ich glaub ich hab XML einfach nie verwendet und wollts auch nie verwenden. Weils einfach keinen Spaß macht sich mit sowas zu beschäftigen.
JSON dagegen versteht eigentlich jeder nach wenigen Minuten und Daten mit PHP zu verarbeiten ist ein Kinderspiel. Man kanns auch sofort lesen...
Mir war auch bis zu diesem Video gar nicht bewusst das XML überhaupt noch relevant ist. Für mich war das eben einfach ein verstaubtes Relikt das von manchen Entwicklern verwendet wird weil sie das halt immer schon verwendet haben^^
@@Meinungsmacher ja das denken viele, deshalb habe ich das video gemacht. JSON hat einen großen nachteil bei großen Datenmengen. Übrigens brauchst du gute XML Ketnisse wenn du auch daten aus einem Word Dokument auslesen willst. Dann gibt es RSS Feeds diese sind auch mit XML Aufgebaut. Wenn du bei Google größere Produkte hinterlegen willst mit Bewertungen, erwartet Google auch XML. Im Wissenschaftlichen Bereich wenn man Paper veröffentlicht, da wird XML sehr stark benutzt weil es maschinenlesbar ist.
Ich habe in den letzten 8 Jahren sehr viel mit XML gearbeitet und kann nicht nachvollziehen wieso man damit nicht gearbeitet hat :D Das schöne ist, lernst du einmal mit XML umzugehen, dann ist das Parsen der Daten aus einem HTML Dokument gar kein Problem mehr.
Das sind zwar gute Gründe für XML, trotzdem bevorzuge ich weiterhin für REST APIs mein Lieblingsformat YAML. Change my mind ;)
Das eignet sich doch eher als config Datei. Ich kann mit JavaScript nicht einfach yaml benutzen. JSON schon.
yaml wird in Symfony Frameworks nach und nach aufgelöst. Doctrine unterstützt es ab Version 3 nicht mehr.
PHP arbeitet mit XML nun mal besser ;)
@@sven2529 www.npmjs.com/package/js-yaml
Oh, YAML ist schon extrem tricky zu lesen. nur mit Einrückungen zu arbeiten ist schon sehr sportlich. Ich tue mich damit doch oft sehr schwer und wenn ich nicht über Symfony so sehr dazu gezwungen würde, dann wäre es nicht mein Format. Für einfache Configs ja, aber wenn es etwas komplexer wird ist das schon tricky
Achja - nochwas vergessen. Solltest Du mal ein Buch mit all Deinen Tipps schreiben - dann denke bitte an mich. Ich hätte bitte gerne das erste Exemplar - signiert und mit Herzerl ;)
Freilig, wenn es soweit :D
Ich finde das ist nicht wirklich hilfreich für mich. Habe mich Jahrelang mit XML herumgeschlagen als ich in der EDI tätig war. Niemand gab mir eine gültes XSD. Ich fand das alles scheisse. PHP kenne ich nicht. Was ich davon gehöt habe, macht mir keine Lust das auch nur aus der Ferne anzuschauen. Ich glaube für die Probleme, die du ansprichst, ist GRPC die Zukunft.
tut mir echt leid das zu hören, ich habe im Gegenteil nur gutes von XML erlebt. Nur dass die Dokumentationen halt davon hässlich ausgesehen haben.
Was auch immer du über PHP gehört hast ist sicherlich veraltet und ich finde nur derjenige kann schlecht über eine Programmiersprache reden der sie auch jeden Tag einsetzt, ansonsten hat er keine Ahnung. Schau auf das Datum von deinen Quellen, als IT-ler müsstest du wissen dass alles was älter als ein Jahr ist, ist nicht mehr gültig ;)
Kann sein dass die GRPC die Zukunft sein wird, solange ich aber in Gegenwart lebe muss ich das verwenden was da ist und wenn sich GRPC durchgesetzt hat, mach ich ein Video darüber wie cool es ist ;)