PHP REST/JSON Service vs. TCP-Server Daemon

[RWarnecke]

Hallo zusammen,

ich benötige eure Erfahrungswerte. Ich möchte ein Backend für eine App bauen und überlege, ob ich die komplette Kommunikation zwischen App und Server über einen Webserver mit PHP und REST/JSON aufbaue oder ob ich einen entsprechenden TCP-Server als Daemon nutze und darüber die Kommunikation erfolgt. Dabei ist es aus meiner Sicht erstmal nicht wichtig, welches DBMS dahinter hängt.

Welches der beiden Varianten würdet Ihr nehmen, wenn man es nachhaltig aufbauen will und warum ? Die folgenden Kriterien sollten erfüllt werden :

• Es soll skalier bar sein
• Es soll performant sein (natürlich den Verbindungsgegebenheiten angepasst)
• Leicht zu warten

Wichtig wäre auch zu wissen, aus eurer Erfahrung heraus, wo stoße ich mit PHP oder mit dem Daemon an eventuelle Grenzen. Die Systemvoraussetzungen für PHP mit REST/JSON oder einem TCP-Server als Daemon sind vorhanden durch einen entsprechenden Dedicated Server bei einem Hoster. Dieser Server kann frei installiert und konfiguriert werden.

Mir ist schon klar, dass das ganze immer situationsbedingt ist. Eure Erfahrungswerte sollen mir helfen ein entsprechendes Gefühl für mein neues Projekt zu bekommen.

[mensch72]

wir machen es aus Prinzip der eventuellen MultiPlattform Kompatibilität immer mit REST/JSON, aber nicht per PHP sondern per nativer ServerAnwendung quasi "per TCP" und ganz wichtig: HTTPS/SSL fähig über/mit "http://www.tmssoftware.com/site/xdata.asp"

Wir haben eh TMS, und für eine für simple eigene TCP Lösung hatten wir nix eigenes für HTTPS/SSL in userem SourcePool.
Bei TMS ist man sowohl Server als auch Client seitig flexibel und kann von "nur JSON" bis direkt ORM gekoppelte DB alles machen.
Es ist&bleibt aber eben der DelphiWay, dein Ansatz/Bedarf klingt nicht so, als ob du unbedingt ein natives DelphiServerProgramm möchtest... Wir kennen uns eben (nur) mit Delphi/C++, Windows und WindowsServern sehr gut aus, so kommt uns gar nicht der Gedanke REST/JSON per PHP anzugehen unabhängig von gut oder schlecht

[Valle]

Ich würde ganz klar zu REST/JSON tendieren.

HTTP und JSON sind modern und verbreitet genug, sodass ich da keine Skalierungs- oder Performanceprobleme sehe. Im Gegenteil: Einen TCP-Server aufzusetzen würde bedeuten, dass man viel der Skalierung- und Optimierungssarbeit von Hand machen muss. Skalierende Webtechnologien gibt es wie Sand am Meer und bieten Lösungen für die ja immergleichen Probleme. Einige davon (PHP gehört eher nicht dazu) sind auch wirklich gut.

Der Vorteil von PHP+JSON läge dafür aber in der Wartbarkeit. Es sollte zu keiner Zeit ein Problem sein, einen Entwickler für PHP / REST / JSON zu finden, der euch dabei unterstützen kann. Plain TCP oder exotischere Programmiersprachen, zu denen ich auch Delphi zähle, sind da komplizierter.

Gerade was HTTP und JSON angeht ist zum Beispiel NodeJS mittlerweile wohl auch aus den Kinderschuhen raus. Performance, Skalierbarkeit und Wartbarkeit (auch im Sinne von Personalproblemen) sind hier wirklich hervorragend. Aber auch klassischere Ansätze mit Python oder Ruby wären denkbar. PHP kann ich für ernsthafte Projekte nicht mehr so richtig für voll nehmen... Aber es gäbe sicherlich schlimmeres.

Natürlich muss ich als Disclaimer dazu sagen, dass ich Webentwickler bin und daher wohl etwas voreingenommen.

[Mavarik]

REST & JSON aber kein PHP sondern Webbroker!

So mich ich das schon sein vielen Jahren - nix ist schneller!

Mavarik

[RWarnecke]

Hallo zusammen,

danke erstmal für eure Antworten.

Zitat von Mavarik:

REST & JSON aber kein PHP sondern Webbroker!

Läuft das auch unter Linux ?

Zitat von Valle:

Aber auch klassischere Ansätze mit Python oder Ruby wären denkbar. PHP kann ich für ernsthafte Projekte nicht mehr so richtig für voll nehmen... Aber es gäbe sicherlich schlimmeres.

Ruby und Python werde ich mir mal anschauen.

[Mavarik]

Zitat von RWarnecke:

Zitat von Mavarik:

REST & JSON aber kein PHP sondern Webbroker!

Läuft das auch unter Linux ?

Aber klar doch...

[Rollo62]

Ich hatte mal ein bischen mit PHP SLim rumprobiert.
Das ist ganz gut strukturiert und hat wenig Ballast.
Allerdings hatte ich mit der Authentifizierung https keine wirklich tolle Lösung gefunden.
Das sollte aber mittlerweile machbar sein.

Rollo

[BrightAngel]

Noch ein paar Argumente für HTTP/JSON

• Port 443/80/TLS/HTTP sind Firewalls und Middleboxen bekannt
• verbreiteter Technologiestack
• vieles ist schon definiert und es gibt spannende Erweiterungen (websockets, ...)
• von Haus aus schon lesbar (gut, niemand hält dich davon ab z.B. ein ASCII Protokoll auf TCP direkt zu definieren, aber es wäre halt wieder selbstgebastelt...)
• TLS direkt schon im Stack mit drin (sowas wie SNI z.B.)
• Multiplexbar mit normalem Webcontent
• Client kann auch zur Not im Browser laufen (debugging Interface/Werkzeuge im Browser)

... und gegen PHP

• Skript läuft pro Anfrage durch -> Kommunikation nur gut über Model möglich... (okay, da gibt es hacks...)
• Bei Longpolling oder ereignisgestützten Reaktionen eher unintuitiv
• Wenn die Server ohnehin frei konfigurierbar sind, gibt es Leichtgewichtigeres

und es kommt natürlich auch darauf an, wie RESTig das ganze wirklich wird...

Brighty

[RWarnecke]

Zitat von Mavarik:

Zitat von RWarnecke:

Zitat von Mavarik:

REST & JSON aber kein PHP sondern Webbroker!

Läuft das auch unter Linux ?

Aber klar doch...

Aber nur mit Delphi 10.2, mit XE8 nicht.

Zitat von Rollo62:

Ich hatte mal ein bischen mit PHP SLim rumprobiert.
Das ist ganz gut strukturiert und hat wenig Ballast.
Allerdings hatte ich mit der Authentifizierung https keine wirklich tolle Lösung gefunden.
Das sollte aber mittlerweile machbar sein.

Danke für den Tipp, werde ich mir genauer anschauen.

[Rollo62]

@BrightAngel

Da hasr du sicher Recht.
Was für PHP spricht ist das es notfalls auf jedem 5eur server läuft.
Node.js ist leider noch nicht so verbreitet sonst wäre das mein Favorit. Nicht jede Anwendung braucht 100% performance z.b. Wenn es nur begrenzte userzahl gibt.


Rollo