Konzept für eine Art Web-Shop mit App-Unterstützung

[Phoenix]

Zitat von IBExpert:

Wenn dem so ist und das jeder alles so parat haben sollte, dann frag ich mal ganz offen, ob es nur mir so geht, das ich ohne den ganzen Kram bisher sehr gut klarkomme, einiges davon zwar kenne, aber gar nichts davon für existenziell wichtig und unersetzbar halte.

Die Fragen sind eigentlich folgende:
- Sind die altbekannten Technologien wirklich gut genug für so ein Vorhaben?
- Bringen mir auf verteilte (Web- und App-) Applikationen spezialisierte Werkzeuge einen Vorteil?
- Wie lange soll das neue Produkt am Markt bleiben? (Hoffentlich mehr als nur 3-4 Jahre?)
- Finden sich dann in 5-7 Jahren noch Entwickler, die sich mit der altbekannten Technologie auskennen?
- Kann ich junge Entwickler dann noch mit meinem Technologiestack überzeugen?
- Wie wichtig ist das Produkt für mein Business?
- Kann ich es mir leisten, das Ding mittelfristig wieder weg zu werfen und neu zu machen wenn die altbekannte Technologie doch nicht fliegt?

Man sollte dabei auch noch folgendes bedenken:

Wir haben hier kein einfaches Client-Server Setup. Sobald Du Dich im Web- und App-Umfeld bewegst arbeitest Du zwangsläufig an einer verteilten Architektur. Du hast Persistenz (DB, kann aber auch mal ne Messagequeue oder ein Eventstore sein), Du hast Services/APIs die zustandslos sein müssen (zumindest ab dem Zeitpunkt an dem Du eine einfache Basis-Ausfallsicherheit sicherstellen möchtest), Du hast Clients auf verschiedenen Plattformen und der Zustand des Gesamtsystems verteilt sich auf Persistenz, Netzwerk und Client-Anwendungen. Und nein, so ne App kann mal offline sein, Du kannst also nicht einfach alles in Transaktionen auf der DB packen um das konsistent zu halten. Du brauchst entweder verteilte Transaktionen (guter Rat: tu's nicht), oder, besser und korrekter, Du setzt auf eventual consistency (irgendwann wird's wieder konsistent werden, nur jetzt grad in dieser Sekunde noch nicht). Und Du musst das alles im Betrieb überwachen.

Gibt es für alle diese Herausforderungen in Deinem Dir jetzt bekannten Werkzeugset Dinge, von denen Du mit Gewissheit sagen kannst dass sie auch bei zehntausenden Anfragen pro Sekunde auf Deinem System grundsolide ihre Arbeit verrichten? Bist Du Dir sicher dass die Sicherheitsschicht Deiner API nicht durch einen Angreifer in ein paar Sekunden ausgehebelt wird (und damit meine ich: Bist Du Dir wirklich sicher? Wie viele unterschiedliche Security-Firmen hast Du mit Penetration-Tests beauftragt um die Aussage zu belegen?).

Und wenn Du Dich jetzt fragst: Ist das wirklich notwendig? Das ganze brauch ich doch nicht! Dann überlege: Du hast einen Shop mit Anbindung an ein Zahlungssystem. Welcher Schaden kann potentiell entstehen wenn jemand im Namen eines anderen bestellt, oder jemand mittels DNS-Spoofing Paypal mimt und Deinem System vorgaukelt etwas sei bezahlt dabei hat Paypal die Zahlungsinfos nie erhalten, oder jemand durch eine Lücke in der API die Versandadresse eines Kunden ändert und alle teuren Waren an eine Paketstation gehen und der Empfänger unbekannt ist? Und das sind nur die einfachen Angriffe. Für sowas haben professionelle Täter heute Scripte die sowas ausprobieren, da sitzt keiner manuell dran und versucht Dein System zu hacken - das System übernehmen die vollautomatisiert.

Und dann sind die Antworten auf die folgende Fragen eigentlich sehr einfach:
Will ich nicht lieber mein Produkt auf eine technologische Basis setzen, die genau für diese Herausforderungen spezialisiert ist?
Sollte ich nicht für meine Webanwendung etwas benutzen, das heute State of the Art ist, und für das ich auch genau jetzt erfahrene Entwickler finden kann?
Sollte ich nicht Technologien für meine API einsetzen, die genau dafür spezialisiert ist und mir dort massig Arbeit abnimmt?
Sollte ich mich was Security angeht nicht besser auf Armeen von Security-Engineers verlassen als zu meinen, alles selber besser zu können?

[DeddyH]

[Phoenix]

Vielleicht noch ein kleiner Nachtrag:

Wenn Du einen "Ich bestelle mein Mittagessen innerhalb der Firma" mit Paypalanbindung bauen willst und es nicht schlimm ist, das wenn auf der Kiste auf der das läuft mal ne Platte ausfällt das Ding mal bis zum Tausch nicht funktioniert, dann sind das selbstverständlich ganz andere Anforderungen und dann kann man sowas sicher auch nochmal in Perl bauen, wenn Du das beherrschst.

Man darf nie vergessen das der pragmatischste Weg auch funktionieren kann. Aber Public internet und Apps sind dann eben doch was anderes.

Da fällt mir übrigens noch was ganz anderes ein @Matze: Apple und Google verlangen auf in-App Verkäufe 30% vom Umsatz. Das gilt grundsätzlich auch für die Verkäufe von physischen Dingen. Wenn Du nicht groß genug bist um Sonderkonditionen auszuhandeln (Amazon, Zalando, eBay etc.) ist das echt ein Problem. Wir haben einen Kunden der das machen wollte (und der ist nicht klein, die Geräte die der verkauft fangen im unteren 5-stelligen Drittel an) und der ist aufgrund dieser Regelung von der Idee seinen Shop als App zu verpacken wieder ganz schnell abgekommen.

[DeddyH]

Das wäre IMHO ein weiteres Argument für eine PWA.