© saicle/Shutterstock.com
PHP Magazin
Mit ein wenig Respekt klappt‘s auch mit dem Frontender

Mein Bier, dein Bier


In dieser Reihe soll es um die Zusammenarbeit von Backend- und Frontend-Entwicklung gehen. Beide Spezialisierungen haben sich in den letzten Jahren unter den Webworkern herauskristallisiert. Die eine Spezialisierung beschäftigt sich hauptsächlich mit Interfacedesign, Markup und dessen Struktur und Styling, also dem Frontend von Webapplikationen. Die andere setzt sich hingegen mit den Themen Datenbankdesign, API-Konzeptionierung und -Umsetzung sowie Geschäftslogik auseinander. Beide arbeiten in einem guten Projekt Hand in Hand und spielen sich die Bälle gegenseitig zu. Ich beginne in diesem Artikel mit dem Backend-Teil dieser Zusammenarbeit.

Grundlage jeder Webanwendung sollte ein Konzept sein, aus dem man User Stories erarbeiten kann. Anhand dieser User Stories kann die Backend-Entwicklung den technischen Rahmen des Projekts erkennen und abschätzen. Für diesen Artikel gehen wir davon aus, dass eine Adressverwaltung namens „Addressmanager“ entwickelt werden soll. Nachdem die User Stories stehen, kann sich unser Frontender mithilfe von Rapid Prototyping um die Entwicklung erster Screens kümmern. Wenn dann alle Stakeholder zufrieden sind, steht dem eigentlichen Entwicklungsprozess nichts mehr im Wege. Die Basis jedes Backends ist die Datenhaltung. Mit den entsprechenden Frameworks kann man das zwar weitestgehend vernachlässigen, allerdings muss man sich selbst bei der Verwendung von Frameworks grundlegend über die Art der Datenhaltung entscheiden. Die wichtigste Wahl ist dabei die Folgende: SQL, NoSQL oder eine Mischung aus beidem? Die Entscheidung hängt dabei stark von der Art der Daten ab. Benötige ich komplexe und sich regelmäßig verändernde Datenstrukturen, so bieten sich SQL-Datenbanken an. NoSQL bietet sich für in der Entwicklung nicht gut vorhersehbare Metadaten an (z. B. wenn Benutzer ihre eigenen Felder in ihrem Profil definieren können). Eine Mischform ist unter Umständen sinnig, um solche Metadaten nach gewissen Schlüsseln durchsuchen zu können. Hier kann man dann noch einmal abwägen, ob man diesen Anwendungsfall nicht durch einen geeigneten Suchindexer wie beispielsweise ElasticSearch abdecken kann.

Bevor wir uns mit der eigentlichen Struktur möglicher Backends beschäftigen, möchte ich noch kurz auf wichtige Designdogmen eingehen. Zuallererst sollte jeder Back­end-Programmierer zumindest schon mal etwas von MVC (Model View Controller) gehört haben, bzw. sich dieser Prinzipien bemächtigen. Eine Trennung von Geschäftslogik und Darstellungscode hat...

PHP Magazin
Mit ein wenig Respekt klappt‘s auch mit dem Frontender

Mein Bier, dein Bier

In dieser Reihe soll es um die Zusammenarbeit von Backend- und Frontend-Entwicklung gehen. Beide Spezialisierungen haben sich in den letzten Jahren unter den Webworkern herauskristallisiert. Die eine Spezialisierung beschäftigt sich hauptsächlich mit Interfacedesign, Markup und dessen Struktur und Styling, also dem Frontend von Webapplikationen. Die andere setzt sich hingegen mit den Themen Datenbankdesign, API-Konzeptionierung und -Umsetzung sowie Geschäftslogik auseinander. Beide arbeiten in einem guten Projekt Hand in Hand und spielen sich die Bälle gegenseitig zu. Ich beginne in diesem Artikel mit dem Backend-Teil dieser Zusammenarbeit.

Daniel Schweighöfer


In dieser Reihe soll es um die Zusammenarbeit von Backend- und Frontend-Entwicklung gehen. Beide Spezialisierungen haben sich in den letzten Jahren unter den Webworkern herauskristallisiert. Die eine Spezialisierung beschäftigt sich hauptsächlich mit Interfacedesign, Markup und dessen Struktur und Styling, also dem Frontend von Webapplikationen. Die andere setzt sich hingegen mit den Themen Datenbankdesign, API-Konzeptionierung und -Umsetzung sowie Geschäftslogik auseinander. Beide arbeiten in einem guten Projekt Hand in Hand und spielen sich die Bälle gegenseitig zu. Ich beginne in diesem Artikel mit dem Backend-Teil dieser Zusammenarbeit.

Grundlage jeder Webanwendung sollte ein Konzept sein, aus dem man User Stories erarbeiten kann. Anhand dieser User Stories kann die Backend-Entwicklung den technischen Rahmen des Projekts erkennen und abschätzen. Für diesen Artikel gehen wir davon aus, dass eine Adressverwaltung namens „Addressmanager“ entwickelt werden soll. Nachdem die User Stories stehen, kann sich unser Frontender mithilfe von Rapid Prototyping um die Entwicklung erster Screens kümmern. Wenn dann alle Stakeholder zufrieden sind, steht dem eigentlichen Entwicklungsprozess nichts mehr im Wege. Die Basis jedes Backends ist die Datenhaltung. Mit den entsprechenden Frameworks kann man das zwar weitestgehend vernachlässigen, allerdings muss man sich selbst bei der Verwendung von Frameworks grundlegend über die Art der Datenhaltung entscheiden. Die wichtigste Wahl ist dabei die Folgende: SQL, NoSQL oder eine Mischung aus beidem? Die Entscheidung hängt dabei stark von der Art der Daten ab. Benötige ich komplexe und sich regelmäßig verändernde Datenstrukturen, so bieten sich SQL-Datenbanken an. NoSQL bietet sich für in der Entwicklung nicht gut vorhersehbare Metadaten an (z. B. wenn Benutzer ihre eigenen Felder in ihrem Profil definieren können). Eine Mischform ist unter Umständen sinnig, um solche Metadaten nach gewissen Schlüsseln durchsuchen zu können. Hier kann man dann noch einmal abwägen, ob man diesen Anwendungsfall nicht durch einen geeigneten Suchindexer wie beispielsweise ElasticSearch abdecken kann.

Bevor wir uns mit der eigentlichen Struktur möglicher Backends beschäftigen, möchte ich noch kurz auf wichtige Designdogmen eingehen. Zuallererst sollte jeder Back­end-Programmierer zumindest schon mal etwas von MVC (Model View Controller) gehört haben, bzw. sich dieser Prinzipien bemächtigen. Eine Trennung von Geschäftslogik und Darstellungscode hat...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang