Serverprogrammierung für iOS-App

[Farley]

Hallo zusammen,

ich bin schon seit langem auf der Suche nach Informationen und bisher nicht fündig geworden. Folgendes habe ich vor:
Ich möchte eine iOS-App erstellen, die ähnlich funktioniert wie mobile.de! Die User sollen also Inserate ihrer Autos erstellen und online schalten können. Gleichzeitig muss es natürlich eine Suchfunktion für die Inserate geben.

iOS-App-seitig wartet sicher einiges an Arbeit und Einarbeitung auf mich, aber zumindest weiß ich wo ich da ansetzen muss.

Mein Problem ist die Server-Seite. Mir fehlt komplett der Ansatz, wo ich da anfangen soll. Welches Betriebssystem sollte auf dem Server laufen? Welche Programmiersprache wäre für diese Anwendung sinnvoll? Welche Art Datenbank wäre sinnvoll? Sollte ein Webserver eingesetzt werden, der http-Anfragen irgendwie an eine Applikation weiter leitet? Oder direkt ein Socket-Server in C++ oder PHP programmiert, der auf einem bestimmten Port auf Anfragen lauscht? Ist die Frage, wie viele Anfragen so ein Socketserver überhaupt behandeln kann? Auf riesigen Plattformen kommen ja Millionen Verbindungen pro Tag rein.

Man hört ja immer davon, dass der Apache Webserver sehr weit verbreitet ist. Ich dachte aber der Apache ist ein reine Webserver, beantwortet also nur http- Anfragen und wird genutzt, um Web-Content bereit zu stellen? Wie lösen riesige Plattformen wie Facebook oder z.B. halt mobile.de diese Aufgabe? Wie funktioniert die Datenbankkommunikation?

Ihr seht also: Mir fehlt es komplett an Basiswissen bzgl. dem Thema (Web-)Server Programmierung. Ich wäre euch wirklich dankbar, wenn jemanden helfen und den richtigen Denkanstoß geben kann. Gerne auch Literatur-, Tutorial- oder Blog-Vorschläge.

Danke schon mal im Voraus!


Farley

 

[Sephe]

Server: Php+Mysql.

Client-App könntest du auch weglassen und alles im Browser machen mit jquery.

Welches OS du für den Server einsetzt ist eigtl egal. Ich persönlich arbeite gerne mit CentOS und Debian, Apache2 mit php und mysql.

Bei Facebook etc ist das natürlich etwas größer. Stichwort: BIG DATA.

Dort wurde z.T. eigene Software geschrieben um Datenbankanfragen weltweit zu verteilen, damit es keine Überlastungen gibt.

Sowas ist aber mit Apache + mysql auch möglich.

 

[Hito]

Abseits vom Thema:
was wird/sollte deine App denn besser machen als mobile.de?
Bei iPhones wirds schon schwer mehrs 4 Inserate gleichzeitig und ausführlich anzuzeigen(ohne Werbung).

 

[Mojo1987]

Mit den Vorkenntnissen ist das eigentlich zum scheitern verdammt... mit ein paar simplen Tips isses hier nicht getan.

 

[Hito]

Scheitert nur wenn man kein Kosten und Mühen scheut.
So eine App ist aber auf jeden Fall zu groß für nur eine Person. imho

 

[Tumbleweed]

Ihr seht also: Mir fehlt es komplett an Basiswissen bzgl. dem Thema (Web-)Server Programmierung.

Das ist gut, dass du das selbst erkennst. Du unterschätzt nur die Menge an Wissen, die dir da fehlt. Hier ist es nicht mit ein paar Tutorials oder Blogeinträgen lesen getan. Für so ein Projekt, so es denn auch nur annähernd seriös ablaufen soll, brauchst du mehrere Jahre Erfahrung in Webentwicklung. Und da ist die iOS-App (ganz schön eingeschränkter Nutzerkreis, wie erklärst du das in deinem Businessplan?) noch nicht mal mit eingerechnet.

An sowas arbeiten Heerscharen fähiger Architekten und Entwickler. Es nützt dir ja auch nichts, wenn du die Businesslogik zusammenstümperst und die ganze Plattform dann bei 5 Besuchern gleichzeitig in sich zusammenfällt unter der Last. Ganz zu schweigen vom Sicherheitsaspekt, denn du wirst hier ja sicherlich auch mit Nutzerdaten der Anbieter zu tun haben.

Fang kleiner an. Viel kleiner.

 

[Daaron]

Denk auch, für deine Anforderungen fehlen dir einfach noch 5 Jahre praktische Berufserfahrung sowie ne Hand voll Mitarbeiter. Das ist nichts, was du jemals schaffen könntest, ohne dabei spätestes hinsichtlich der Sicherheit derbst auf die Nase zu fallen.
Also: Entweder Gewerbe mit wenigstens nem halben Dutzend Mitarbeiter, oder gleich sein lassen.

Die User sollen also Inserate ihrer Autos erstellen und online schalten können. Gleichzeitig muss es natürlich eine Suchfunktion für die Inserate geben.

Was macht dich BESSER oder INTERESSANTER als Mobile.de? Mobile.de gibts seit Ewigkeiten, jeder kennt den Kram und die haben jährlich ein locker 7-stelliges Werbebudget (siehe Dichte der TV-Spots). Ich kann dir aus eigener Erfahrung sagen: Egal wie toll dein Angebot ist, wenn du gegen einen Konkurrenten antrittst, der TV-Spots finanzieren kann, dann kannst du es gleich lassen.

Welches Betriebssystem sollte auf dem Server laufen? Welche Programmiersprache wäre für diese Anwendung sinnvoll?

Für welches Betriebssystem hast du Administratoren? Man beachte: Plural, zwecks 24/7 Verfügbarkeit, auch zu Feiertagen.
Kannst du keine 24/7 Rufbereitschaft für deine Admins sicherstellen, dann kannst du deinen Dienst gleich lassen. Denn eines kann ich dir ebenfalls aus Erfahrung sagen: Server spinnen nicht gemütlich vormittags um 10, wenn 3 Admins grad Eier schaukeln. Server spinnen zum ersten Weihnachtsfeiertag, wenn alle im Familienkreis essen. Server spinnen zum WM-Endspiel-Sonnabend pünktlich zum Beginn der Verlängerung. Wenn du nur einen Admin hast, dann spinnen Server genau dann, wenn selbiger endlich mal Urlaub irgendwo in Funklochhausen macht.

Also: Keine Admins, keine Frage nach dem Betriebssystem. 2 Admins sind MINIMUM, eher 4-5.

Welche Art Datenbank wäre sinnvoll?

Hängt gleichermaßen von den Fähigkeiten deiner Entwickler wie vom OS ab. MSSQL, MySQL, MariaDB, PostgreSQL, Oracle,... Die Liste ist endlos und nur ein absoluter PROFI kann dir sagen, was jetzt richtig für deinen Fall ist.

Sollte ein Webserver eingesetzt werden, der http-Anfragen irgendwie an eine Applikation weiter leitet? Oder direkt ein Socket-Server in C++ oder PHP programmiert, der auf einem bestimmten Port auf Anfragen lauscht?

Wo ist der Unterschied? Ein Webserver ist, im weitesten Sinne, ein Socket-Server, der auf Port 80 auf Anfragen im HTTP-Standard lauscht... und mit einer REST-Schnittstelle ist es am Ende eh egal.

Ist die Frage, wie viele Anfragen so ein Socketserver überhaupt behandeln kann? Auf riesigen Plattformen kommen ja Millionen Verbindungen pro Tag rein.

Wie konzipierst du den Load Balancer? Das ist die korrekte Fragestellung...

Man hört ja immer davon, dass der Apache Webserver sehr weit verbreitet ist. Ich dachte aber der Apache ist ein reine Webserver, beantwortet also nur http- Anfragen und wird genutzt, um Web-Content bereit zu stellen?

Jap, Apache hat n Marktanteil von 60-70%, und zwar zurecht. Apache ist zwar nciht so agil wie nginx oder Cherokee, und erst recht nicht so performant wie ne maßgeschneiderte C/C++ - Lösung, aber für 99% der Fälle reicht ein gut konfigurierter Apache allemal.
Computerbase ist, wenn ich mich recht erinner, ein Apache mit Load-Balancer und nginx als Proxy-Cache.

Wie lösen riesige Plattformen wie Facebook oder z.B. halt mobile.de diese Aufgabe? Wie funktioniert die Datenbankkommunikation?

Um das zu beantworten muss man einige Semester in der Uni zugebracht UND ein paar Jahre praktische Erfahrung mitbringen.
Tatsächlich ist Facebook am Ende aber PHP. Genauer gesagt wird PHP dort via HipHop in Maschinencode umgewandelt.

 

[Funart]

Manchmal frag ich mich ob Personen absichtlich falsche Informationen geben oder ob sie es einfach nicht besser wisse. Ich bin jetzt einmal ein Optimist und glaub dass sie es nicht besser wissen. Du brauchst weder 5 Jahre erfahrung noch die Fähigkeit einen Loadbalancer zu konzeptionieren.
In der Regel starten solche Projekte richtig hacky aber es läuft. Wenn du wüsstest wie Google ursprünglich mal gehostet wurde würde dir schlecht werden. Da du wenig Erfahrung hast würde ich auf alle Fälle auf managed hosting setzen. Allerdings auf keinen Billig hoster setzen, selbst da bist mit unter 10 Euro im Monat schon dabei. Das reduziert vor allem das finanzielle Risiko und falls die app einschlägt kannst du dich noch immer ums skalieren kömmen. Aus den meisten apps wird nichts, dass liegt in der Natur der Sache.
Ich selbst hab in meiner Jugend ein Projekt mit 1k unique ips am Tag betrieben, wenn ich mir heute drüber nachdenke frag ich mich wie das hat laufen können
Zur App selbst -> Viele features bringen dir zu Beginn relative wenig. Schau dir andere ähnliche apps an und überleg dir, welche Dinge dir an diesen Apps überhaupt nicht gefallen und versuch das Problem zu lösen. Natürlich ohne einen haufen anderer Probleme zu verursachen. Wenn den Leuten deine App gefällt wirds vermutlich von selbst langsam größer werden. So etwas wie von heut auf morgen tausende User ist unwahrscheinlich.

Kurzfassung: Hack einfach mal rum und schau was passiert und mach dir jetzt keine Gedanken darüber was in einem Jahr ist. Viele solche Hobby Projekte laufen niemals, allerdings lernt man meist doch immer etwas dazu und das ist in meinen Augen wichtiger. Nur so kommt man zu einem Fähigkeitslevel wo man die meisten Probleme automatisch vermeidet -> Fehler machen ist einfach extrem Wichtig. Das bringt einem kein Buch bei.

 

[Daaron]

Du brauchst die praktische Berufserfahrung schon allein um zu wissen, wo überall Sicherheitsprobleme lauern.

Es ist scheißegal, dass Firma XY vor vielen Jahren mal mit ganz üblen Hacks angefangen hat. Vor Jahren ging sowas noch deutlich geschmeidiger, weil die Anzahl der potentiellen Nutzer noch lächerlich gering war. Damals war auch die Sicherheitsproblematik noch nicht so im Fokus. Da hatte man eben drölfzillionen Lücken für SQL Injection, Remote Code Execution oder PHP Object Injection. War doch keiner da, der es bemerken kann...

Heute würde Zuckerberg auch nicht mehr in PHP anfangen sondern direkt in C++. Das würde ihm (bzw. seinen Angestellten) den ganzen Aufwand mit HipHop sparen und evtl. sogar die Hosting-Kosten um 10-20% senken. Tatsächlich ist Facebook der Beweis, dass man ohne vorausschauende Planung irgendwann in eine Technologiefalle tappt, aus der man nur mit Mühe raus kommt. Für FB hießt das: finde einen Weg, um aus dem PHP-Code wirklich performanten vorkompilierten Maschinencode zu machen.

Das hier beschriebene Problem ist eben nichts, was man ohne jeglichen Dunst an den Start bringen kann. Das ist eine Mammutaufgabe für ein fähiges Team. Vergleichbare große Projekte haben im Hintergrund keine Garagentüftler ohne passenden Berufsabschluss, sondern ne kleine Armada an Dipl.Ing, BA, MA und Fachinformatikern.

 

[Farley]

Erst einmal vielen Dank für die vielen Antworten, aber bitte nicht so negativ! :-)

Abseits vom Thema:
was wird/sollte deine App denn besser machen als mobile.de?

Meine App soll nicht besser werden. Ich möchte kein Geld damit verdienen und den Automarkt beherrschen. ;-) Es geht mir ums Lernen.

Mit den Vorkenntnissen ist das eigentlich zum scheitern verdammt... mit ein paar simplen Tips isses hier nicht getan.

Ich denke nicht, dass es zum Scheitern verurteilt ist. Ich will ja ganz klein anfangen. Ein Server der mit "Hallo bin da" antwortet, eine App die es anzeigt. Dann Daten übertragen können, die stumpf in eine Datenbank gepackt werden. Und dann halt Schritt für Schritt weiter. Ich habe gar nicht geplant die App zu veröffentlichen. Ich würde nur gerne KnowHow aufbauen und das ist denke ich auch problemlos ohne Zeit und Kostendruck möglich.

Das ist gut, dass du das selbst erkennst. Du unterschätzt nur die Menge an Wissen, die dir da fehlt. Hier ist es nicht mit ein paar Tutorials oder Blogeinträgen lesen getan.

Ich bin durchaus bereit einiges an Arbeit zu investieren. Nur weiß ich nicht wie der richtige Ansatz ist. Deshalb wäre ich dankbar, wenn jemand nützliche Blogs, Tutorials oder Literatur zum Thema (Web-)Server-Programmierung kennt.

Für welches Betriebssystem hast du Administratoren?
Also: Keine Admins, keine Frage nach dem Betriebssystem. 2 Admins sind MINIMUM, eher 4-5.

Hängt gleichermaßen von den Fähigkeiten deiner Entwickler wie vom OS ab. MSSQL, MySQL, MariaDB, PostgreSQL, Oracle,... Die Liste ist endlos und nur ein absoluter PROFI kann dir sagen, was jetzt richtig für deinen Fall ist.

Wo ist der Unterschied? Ein Webserver ist, im weitesten Sinne, ein Socket-Server, der auf Port 80 auf Anfragen im HTTP-Standard lauscht... und mit einer REST-Schnittstelle ist es am Ende eh egal.

Wie konzipierst du den Load Balancer? Das ist die korrekte Fragestellung...

Jap, Apache hat n Marktanteil von 60-70%, und zwar zurecht. Apache ist zwar nciht so agil wie nginx oder Cherokee, und erst recht nicht so performant wie ne maßgeschneiderte C/C++ - Lösung, aber für 99% der Fälle reicht ein gut konfigurierter Apache allemal.
Computerbase ist, wenn ich mich recht erinner, ein Apache mit Load-Balancer und nginx als Proxy-Cache.

Das ist einfach zu beantworten: Keine. :-) Wie schon oben geschrieben: Natürlich ist mir bewusst, dass eine funktionierende Infrastruktur wie mobile.de in der Größe unmöglich alleine in den Griff zu kriegen ist. Möchte ich aber auch gar nicht
Bedeutet: Ich bin für jedes System offen. Einarbeiten muss ich mich sowieso. Gibt es denn keine Empfehlung? Ein Best-Practice?

Datenbanktechnisch sieht es genau so aus. MySQL scheint zumindest für den Anfang nicht zu schaden, richtig?

Zum Thema Webserver: Das ist genau meine Frage, was ist der Unterschied? In meinen Augen ist der Apache erst mal ein Webserver, der z.B. eine Website hostet und Anfragen per http beantworten kann. Gut. Wie bring ich dem Apache aber bei eine individuelle Anfrage zu beantworten? Kann ich dafür ein eigenes Serverprogramm schreiben (PHP oder wie auch immer) und der Apache kann dann die Anfragen weiterleiten? Wo kann man einen guten Einstieg in dieses Thema finden?

Manchmal frag ich mich ob Personen absichtlich falsche Informationen geben oder ob sie es einfach nicht besser wisse. Ich bin jetzt einmal ein Optimist und glaub dass sie es nicht besser wissen. Du brauchst weder 5 Jahre erfahrung noch die Fähigkeit einen Loadbalancer zu konzeptionieren.
In der Regel starten solche Projekte richtig hacky aber es läuft. Wenn du wüsstest wie Google ursprünglich mal gehostet wurde würde dir schlecht werden. Da du wenig Erfahrung hast würde ich auf alle Fälle auf managed hosting setzen. Allerdings auf keinen Billig hoster setzen, selbst da bist mit unter 10 Euro im Monat schon dabei. Das reduziert vor allem das finanzielle Risiko und falls die app einschlägt kannst du dich noch immer ums skalieren kömmen. Aus den meisten apps wird nichts, dass liegt in der Natur der Sache.
Ich selbst hab in meiner Jugend ein Projekt mit 1k unique ips am Tag betrieben, wenn ich mir heute drüber nachdenke frag ich mich wie das hat laufen können
Zur App selbst -> Viele features bringen dir zu Beginn relative wenig. Schau dir andere ähnliche apps an und überleg dir, welche Dinge dir an diesen Apps überhaupt nicht gefallen und versuch das Problem zu lösen. Natürlich ohne einen haufen anderer Probleme zu verursachen. Wenn den Leuten deine App gefällt wirds vermutlich von selbst langsam größer werden. So etwas wie von heut auf morgen tausende User ist unwahrscheinlich.

Kurzfassung: Hack einfach mal rum und schau was passiert und mach dir jetzt keine Gedanken darüber was in einem Jahr ist. Viele solche Hobby Projekte laufen niemals, allerdings lernt man meist doch immer etwas dazu und das ist in meinen Augen wichtiger. Nur so kommt man zu einem Fähigkeitslevel wo man die meisten Probleme automatisch vermeidet -> Fehler machen ist einfach extrem Wichtig. Das bringt einem kein Buch bei.

Vielen Dank! Die Antwort macht Mut und genauso hatte ich es geplant.

Also, ich hab mich wohl falsch ausgedrückt. Ich wollte hier nicht den Anschein erwecken, dass ich mit 0 Grundwissen morgen Millionen mit einer App verdienen will. Das geht nicht, ist mir klar.
Da es aber hier scheinbar sehr viel Erfahrung gibt vermute ich mal, dass ihr alle mal klein angefangen habt. :-) Und vllt könnt ihr mir ja helfen mit euren Erfahrungen, wie man sich am besten mit dem Thema Serverprogrammierung auseinander setzt.
Ich dachte nur es ist ein guter Weg, wenn ich mir ein Ziel setze. Und das ist eben meine (sehr kleine und deutlich abgespeckt) mobile.de-App. Nur für mich, nur zu Testzwecken. Wenn ich das schaffe (in 6 Monaten oder in 2 Jahren oder wann auch immer) habe ich denk ich viel gelernt und die ganze Strecke von nativer App über den Webserver zur Datenbank und zurück zumindest einmal geschafft

Wer Einstiegshilfen und/oder Ideen parat hat: Immer gerne her damit! Und natürlich ist auch konstruktive Kritik hilfreich, allerdings bin ich nicht komplett ohne Vorwissen und mir durchaus bewusst, dass ich einiges vor mir habe!

MfG
Farley

 

[T0a5tbr0t]

Wähle doch einfach nach deinen Vorkenntnissen aus. Für alle verbreiteten Programmiersprachen gibt es Frameworks für Webserver / Webdienste. Nehme einfach eine Sprache die du kannst bzw. lernen willst.
Einziger Tipp: Ich würde am Anfang nicht zu nah an die Hardware gehen, damit man schon früh Ergebnisse sieht. Also nicht gleich C / C++ oder so, sondern vllt. Python, PHP, JavaScript, C# oder auch Java. Dann muss man sich auch nicht mit Speicherverwaltung usw. abmühen. Bis auf C# laufen die genannten Sprachen auch ohne größeren Aufwand auf Windows und Linux.
Falls es dich interessiert: mobile.de scheint auf Java zu setzten (zumindest sehen deren Jobangebote so aus) und die Seite läuft auf Apache Servern

Und ja, SQL lernen schadet nicht. Für die ersten Datenbank-Versuche ist die Lernkurve da recht angenehm.

Und zu Apache generell: Das ist ein schneller (in C geschrieben) und ziemlich stark konfigurierbarer HTTP Server. Apache selber ist recht leichtgewichtig und kann mit Modulen (mod_...) erweitert werden. Meistens lässt man dahinter irgendeine andere Programmiersprache laufen (z.B. PHP) und der Apache ist dann zur Verarbeitung der HTTP-Header usw. da und leitet die Anfrage dann an das darunterliegende System weiter.
Wie genau das letztendlich läuft hängt eben vom verwendeten Framework / Sprache ab.
Theoretisch kann man jede Sprache hinter einem Apache laufen lassen. Wenn man ein Framework verendet, welche das Verarbeiten der HTTP Anfragen abnimmt, kann man den aber auch einfach weglassen. Manchmal nimmt man nen Apache auch einfach als Reverse Proxy bzw. um dahinter irgendwas größeres zu verwalten.

 

[Daaron]

Bedeutet: Ich bin für jedes System offen. Einarbeiten muss ich mich sowieso. Gibt es denn keine Empfehlung? Ein Best-Practice?

Nimm, was dir schmeckt. Wenn du irgendwo Vorkenntnisse hast, dann guck da. Wenn du keine hast, dann kann ich dir nur raten: Setz auf PHP. Sicher, einige besonders renitente Forenmitglieder werden dir von PHP abraten, weil die Sprache wirklich ein paar holprige Elemente hat, aber die Vorteile sind einfach unschlagbar:
- riesige Community. Schaut man z.B. auf Stackoverflow, so gibt es zu "nacktem" PHP doppelt so viele Threads wie zu Ruby + dessen Framework Rails (und man muss dazu sagen: Kein Aas verwendet "nacktes" Ruby).
- verdammt gute Dokumentation, sowohl in Englisch als auch in Deutsch
- durch massig quelloffene CMS, Shopsysteme, Foren,... gibts auch massenhaft Anschauungsmaterial

Also in meinen Augen ist der ideale Start ein klassischer LAMP-Stack. Linux Apache MySQL PHP... wobei man MySQL inzwischen getrost durch MariaDB ersetzen kann & sollte.

Zum Thema Webserver: Das ist genau meine Frage, was ist der Unterschied? In meinen Augen ist der Apache erst mal ein Webserver, der z.B. eine Website hostet und Anfragen per http beantworten kann.

Dasselbe gilt für Microsoft IIS, nginx, Cherokee, lighttpd,... Die alle machen nur eins: Sie lauschen auf Port 80 nach Requests und beantworten sie passend. Im einfachsten Fall antworten sie direkt mit ner Datei, z.B. ner .html, .js, .css, .jpg, .png, .mp3... Im komplexeren Fall sind sie so konfiguriert, dass gewisse Dateiendungen den Schwarzen Peter weiter schieben.
Das heißt, bei nem klassischen LAMP/WAMP - Stack: Eine Anfrage geht an die index.php -> Apache erkennt, dass die entsprechend konfigurierte PHP-Implementierung gefragt ist, index.php geht an die PHP Engine, PHP Engine macht ihren Job und gibt, im Zweifel, HTML-Code zurück, der dann vom Apache ausgespuckt wird.

Da es aber hier scheinbar sehr viel Erfahrung gibt vermute ich mal, dass ihr alle mal klein angefangen habt. :-)

"klein" in Form einer mehr oder minder umfassenden Ausbildung sowie n paar Monaten Selbststudium... ja.

Für den Anfang solltest du den Gedanken an ne App erst einmal gaaaanz weit in den Keller packen. Den kannst du nächstes Jahr wieder ausgraben. Sorg lieber erst einmal dafür, dass du eine sinnvolle Client-Server - Kommunikation hin bekommst, wobei der Client einfach nur n x-beliebiger Browser ist.
Schreib deine Geschäftslogik so, dass sie unabhängig vom "Empfänger" über ein- und dieselbe REST-Schnittstelle angesprochen werden kann und der Client dann eben entscheidet, wie er den Kram darstellt.

 

[Farley]

Wähle doch einfach nach deinen Vorkenntnissen aus. Für alle verbreiteten Programmiersprachen gibt es Frameworks für Webserver / Webdienste. Nehme einfach eine Sprache die du kannst bzw. lernen willst.
Einziger Tipp: Ich würde am Anfang nicht zu nah an die Hardware gehen, damit man schon früh Ergebnisse sieht. Also nicht gleich C / C++ oder so, sondern vllt. Python, PHP, JavaScript, C# oder auch Java. Dann muss man sich auch nicht mit Speicherverwaltung usw. abmühen. Bis auf C# laufen die genannten Sprachen auch ohne größeren Aufwand auf Windows und Linux.
Falls es dich interessiert: mobile.de scheint auf Java zu setzten (zumindest sehen deren Jobangebote so aus) und die Seite läuft auf Apache Servern

Nimm, was dir schmeckt. Wenn du irgendwo Vorkenntnisse hast, dann guck da. Wenn du keine hast, dann kann ich dir nur raten: Setz auf PHP. Sicher, einige besonders renitente Forenmitglieder werden dir von PHP abraten, weil die Sprache wirklich ein paar holprige Elemente hat, aber die Vorteile sind einfach unschlagbar:
- riesige Community. Schaut man z.B. auf Stackoverflow, so gibt es zu "nacktem" PHP doppelt so viele Threads wie zu Ruby + dessen Framework Rails (und man muss dazu sagen: Kein Aas verwendet "nacktes" Ruby).
- verdammt gute Dokumentation, sowohl in Englisch als auch in Deutsch
- durch massig quelloffene CMS, Shopsysteme, Foren,... gibts auch massenhaft Anschauungsmaterial

Also in meinen Augen ist der ideale Start ein klassischer LAMP-Stack. Linux Apache MySQL PHP... wobei man MySQL inzwischen getrost durch MariaDB ersetzen kann & sollte.

Guter Tipp. Da ich mit Java wohl am besten klar komme und PHP Kenntnisse sicher nicht schaden, würde ich es mit einem der beiden im ersten Schritt mal versuchen.

Und zu Apache generell: Das ist ein schneller (in C geschrieben) und ziemlich stark konfigurierbarer HTTP Server. Apache selber ist recht leichtgewichtig und kann mit Modulen (mod_...) erweitert werden. Meistens lässt man dahinter irgendeine andere Programmiersprache laufen (z.B. PHP) und der Apache ist dann zur Verarbeitung der HTTP-Header usw. da und leitet die Anfrage dann an das darunterliegende System weiter.
Wie genau das letztendlich läuft hängt eben vom verwendeten Framework / Sprache ab.
Theoretisch kann man jede Sprache hinter einem Apache laufen lassen. Wenn man ein Framework verendet, welche das Verarbeiten der HTTP Anfragen abnimmt, kann man den aber auch einfach weglassen. Manchmal nimmt man nen Apache auch einfach als Reverse Proxy bzw. um dahinter irgendwas größeres zu verwalten.

Dasselbe gilt für Microsoft IIS, nginx, Cherokee, lighttpd,... Die alle machen nur eins: Sie lauschen auf Port 80 nach Requests und beantworten sie passend. Im einfachsten Fall antworten sie direkt mit ner Datei, z.B. ner .html, .js, .css, .jpg, .png, .mp3... Im komplexeren Fall sind sie so konfiguriert, dass gewisse Dateiendungen den Schwarzen Peter weiter schieben.
Das heißt, bei nem klassischen LAMP/WAMP - Stack: Eine Anfrage geht an die index.php -> Apache erkennt, dass die entsprechend konfigurierte PHP-Implementierung gefragt ist, index.php geht an die PHP Engine, PHP Engine macht ihren Job und gibt, im Zweifel, HTML-Code zurück, der dann vom Apache ausgespuckt wird.

Bringt einiges an Licht ins Dunkle! Gibt es gute Dokus oder Beispiele wie man einen Apache Server konfigurieren muss, damit dieser Anfragen an PHP oder Java-Code weiterleitet?

Für den Anfang solltest du den Gedanken an ne App erst einmal gaaaanz weit in den Keller packen. Den kannst du nächstes Jahr wieder ausgraben. Sorg lieber erst einmal dafür, dass du eine sinnvolle Client-Server - Kommunikation hin bekommst, wobei der Client einfach nur n x-beliebiger Browser ist.
Schreib deine Geschäftslogik so, dass sie unabhängig vom "Empfänger" über ein- und dieselbe REST-Schnittstelle angesprochen werden kann und der Client dann eben entscheidet, wie er den Kram darstellt.

Ja da hast du vllt recht.

Um noch mal zusammenzufassen, was ich hoffentlich(!) kapiert habe:
Erfolgt der Serverzugriff von einem Browser über eine Webseite ist es immer sinnvoll, einen Webserver wie z.B. Apache laufen zu haben, der zum Einen die Website auf Anfrage bereit stellt und zum Anderen anderweitige Anfragen (die in http verpackt sind) an einen Server in PHP oder Java geschrieben weiterleitet. Dieser würde dann auch über den Webserver in http verpackt antworten.
Möchte man von einer App aus auf den Server zugreifen, macht es immer Sinn einen Webserver laufen zu haben, falls man parallel auch Zugriff über eine Webseite haben will. Weil man ja sonst verschiedene Zugangspunkte schaffen müsste. So läuft alles über den Webserver und gut.
Wenn ich jetzt zum Beispiel ein Programm programmieren möchte, dass mir den Datenaustausch von Rechner A nach B ermöglicht, dann macht ein Webserver keinen Sinn, weil ich nicht den Weg über den Browser nehme. Ich hab mein eigenes in Java geschriebenes Frontend und baue eine Socketverbindung zu meinem Java-Server-Programm auf.
Wenn ich jetzt eine App hätte, die zum Beispiel nur eine Serververbindung braucht um Highscores zu übertragen und es gäbe keinerlei Browservariante dafür: Macht es dann dennoch Sinn einen Webserver zu nutzen (vllt aus Sicherheitsgründen) und http zu sprechen?`Oder reicht dann auch ein einfaches Javaprogramm, das einen Websocketzugang anbietet, eine Verbindung aufbaut und mit der Datenbank kommuniziert?

Gruß
Farley

 

[T0a5tbr0t]

Nehme auf jeden Fall eine fertige Testumgebungen zum üben. Der ganze Technik-Stack wird sonst schnell zu einem Konfigurations-Monster, welches gerne Anfänger zum Frühstück frisst
Für PHP google mal nach LAMP bzw. XAMPP. Da gibt es fertige Pakete die man einfach startet und dann läuft ein Server über localhost mit PHP, MySQL usw.
Wenn du da mehr wissen willst, einfach mal die Dinge in diesem Paketen googlen. Bei PHP z.B. mod_php, fastCGI und wozu die alle gut sind.
Aber mit kleinen Schritten vorarbeiten, denn sonst ist die Lernkurve sehr steil. Die sind gebaut, um vom kleinen Blog bis großem Webshop mit Load Balancer zum funktionieren und dementsprechend flexibel und konfigurierbar.
Für Java gibt es auch fertige Pakete mit z.B. nem Apache Tomcat. Aber da ist die Lernkurve (wie bei eigentlich allem in Java ) recht steil.

Ob HTTP, ne Websocket Verbindung oder "einfach" eine TCP Verbindung gut ist, hängt von deinem Client ab bzw. was da einfacher zu Entwickeln ist. HTTP (mal abgesehen von HTTP 2.0) ist eben nur Pull (also Anfrage vom Client -> Server schickt Antwort). Wenn man mehr braucht muss eben ein Socket her.

 

[Daaron]

Guter Tipp. Da ich mit Java wohl am besten klar komme und PHP Kenntnisse sicher nicht schaden, würde ich es mit einem der beiden im ersten Schritt mal versuchen.

Mit Java wird es wohl um einiges schwerer, auf die Schnelle eine lauffähige Umgebung hin zu bekommen. PHP ist da eben unschlagbar. XAMPP runterladen, entpacken und die Dienste starten. Schon läuft n wunderschöner WAMP-Stack als Testumgebung. Für Live-Systeme ist XAMPP nicht zu verwenden, is zu unsicher konfiguriert.

Bringt einiges an Licht ins Dunkle! Gibt es gute Dokus oder Beispiele wie man einen Apache Server konfigurieren muss, damit dieser Anfragen an PHP oder Java-Code weiterleitet?

Guck mal bei Howtoforge nach den Perfect Server - Tutorials... ABER: Du brauchst den Kram nicht. Vollkommen überdimensioniert.
Halt dich an PHP, halt dich für den Anfang an XAMPP in deiner gewohnten Windows-Umgebung. Damit kannst du die nächsten 1-2 Jahre fleißig jeden Tag was Neues lernen, ohne jemals in Berühung mit "realen" Hosting-Umgebungen zu kommen.

Erfolgt der Serverzugriff von einem Browser über eine Webseite ist es immer sinnvoll, einen Webserver wie z.B. Apache laufen zu haben, der zum Einen die Website auf Anfrage bereit stellt und zum Anderen anderweitige Anfragen (die in http verpackt sind) an einen Server in PHP oder Java geschrieben weiterleitet. Dieser würde dann auch über den Webserver in http verpackt antworten.

So ungefähr... Eine Anfrage an example.org ist z.B. indirekt eine Anfrage an example.org/index.php. Das wird im Server so als Standard definiert. Für alle Anfragen, die direkt auf Dateien oder Verzeichnisse zeigen , z.B. auf das Logo (https://www.computerbase.de/img/logo.png), werden mit der jeweiligen Datei beantwortet bzw. der Index-Datei des Verzeichnisses. Alles, was von der Anfrage her KEINE physisch vorhandene Datei/Verzeichnis ist, geht direkt an die Index-Datei, eben bei PHP-Umgebungen die index.php. Selbige geht als nächstes in den PHP-Interpreter, der all die schönen Dinge tut, die in der index.php stehen. Was am Ende dabei heraus kommt entscheidet der Interpreter. Irgend eine HTTP-Antwort erhält man, aber nicht zwingend ein verwertbares Dokument.

Wenn ich jetzt eine App hätte, die zum Beispiel nur eine Serververbindung braucht um Highscores zu übertragen und es gäbe keinerlei Browservariante dafür: Macht es dann dennoch Sinn einen Webserver zu nutzen (vllt aus Sicherheitsgründen) und http zu sprechen?

Sicherheitstechnisch? HTTPS statt HTTP... Einen eigenen verschlüsselten Socket zu schreiben ist viel komplizierter, als einfach bestehende Systeme zu nutzen.
Der wirklich interessante Punkt ist die Homogenität. Dein System macht ja nicht nur eines. Es empfängt ja nicht nur Highscores und sendet sie vielleicht an Apps zurück. Dein System wird ja sicher auch ne Webseite anbieten, auf der man ohne App die Highscores sehen kann. Dein System hat vielleicht ne Admin-Webseite. Wenn du also eh von zig verschiedenen Schnittstellen auf dieselben Daten zugreifen musst, dann geht man den Weg des geringsten Widerstands und lässt alles als RESTful Service über HTTP laufen.

Wenn du da mehr wissen willst, einfach mal die Dinge in diesem Paketen googlen. Bei PHP z.B. mod_php, fastCGI und wozu die alle gut sind.

Nix schlägt PHP-FPM...

Für Java gibt es auch fertige Pakete mit z.B. nem Apache Tomcat. Aber da ist die Lernkurve (wie bei eigentlich allem in Java ) recht steil.

Steil? Schon die pure Installation von Tomcat über die Debian Paketverwaltung erschlägt einen danach mit nem Fragenkatalog zur Grundkonfiguration, dass man doch eher die Eiger-Nordwand ohne Hilfsmittel besteigen möchte...
Nene, Finger weg von Java. Das is für die großen Jungs mit den großen Gehaltschecks.

HTTP (mal abgesehen von HTTP 2.0) ist eben nur Pull (also Anfrage vom Client -> Server schickt Antwort). Wenn man mehr braucht muss eben ein Socket her.

Nope, auch HTTP beherrscht Push. Der ganze Kram ist sogar für HTML5-fähige Browser standardisiert, siehe: http://www.w3.org/TR/eventsource/
Und im schlimmsten Fall gibts ja noch die Websockets API...

 

[Sithys]

Ich würde einfach mal cordova in den Raum schmeißen. Schau es dir mal an, hybride apps werden die nativen irgendwann ablösen, bin ich mir ziemlich sicher.

http://www.cordova.apache.org

 

[Farley]

Danke euch allen! Damit hab ich erst mal ne Menge Anregungen und genug zu lernen!

MfG
Farley

 

[Daaron]

Cordova klingt nützlich, aber bringt dem TE erst einmal gar nichts. Erst einmal muss ein Modus Operandi gefunden werden, wie die gewünschten Daten auf dem Server bereitgestellt und zum Client übertragen werden. Das heißt: Backend-Logik. Kistenweise Backend-Logik. Das nächste Jahr über nur Backend-Logik.