Ein Gastbeitrag von Klaus Breyer, einer der Autoren des „Praxishandbuch Facebook-Programmierung„.

Die Anfänge

Ich erinnere mich noch daran, als hätte ich es erst gestern gelesen: Mein erstes Buch über Facebookprogrammierung im Jahr 2009 thematisierte FBML und Ruby on Rails. Welch exotische Kombination. Denn selbst der geneigte Leser mag mit viel Glück vielleicht lediglich eines davon kennen. Damals war die Nutzung der Facebook API generell ungewöhnlich – doch und unter all diesen Exoten war Ruby on Rails (ein Web Framework für die Sprache Ruby) am weitesten verbreitet.

Und was war nun noch gleich FBML? Ganz genau! Die „Facebook Markup Language“. Ein HTML-Derivat mit speziellen Facebook-Tags, das von Facebook zuerst serverseitig in ordentliches HTML übersetzt wurde, bevor es dann im Browser des Nutzers ankam. Der komplette Traffic von ausnahmslos allen Apps lief zu dieser Zeit über Facebooks amerikanischen Server – und das nur sehr langsam und schwer zu debuggen.

Nahezu kein einziger Monat verging ohne „Breaking Changes“. Später dann initiierte Facebook „Operation Developer Love“ und gelobte hiermit Besserung. Doch von garantierten Migrationszeiten war man auch damit noch weiter entfernt als gewünscht. Dafür gab es jedoch sehr praktische Features: Eine Anwendung konnte noch ganz andere Arten von Notifications an Nutzer senden – und das ohne Limitierung oder Qualitätskontrolle seitens Facebook! Das waren damals tatsächlich die wirklich „viralen Features“. Wurde eine App einmal zugelassen, ließ sie einem fortan keine Ruhe mehr. Die Funktionen der frühen Apps waren in den meisten Fällen Dinge wie virtuelle Geschenke oder die Möglichkeit, sich gegenseitig mit Kissen zu bewerfen. Hochgradig virale Anwendungen – doch allesamt eher sinnfrei. Was für eine tolle Zeit!

Goldgräberstimmung

Im Jahr 2011 hielt ich einen Talk mit dem bezeichnenden Titel „Fixing Facebook API – die schönsten Workarounds“. Hier war das Motto Programm. Zu dieser Zeit konstruierten wir unsere Anwendungen bereits in iFrames und nicht mehr in FBML – doch auch diese wollten nicht immer so, wie wir gerne wollten. Noch dazu stand damals natürlich nahezu jeder digitale Konzepter vor der Aufgabe, seine erste Facebook Anwendung zu entwerfen. Die Aufklärungsarbeit der frühen Entwickler-Szene an ihren Kunden bzw. den zwischengeschalteten Agenturen war umfangreich. Größer war nur noch der Aufwand, bis dato bereits versprochene Features künstlich in die Facebook-Mechanik zu implementieren.

Und so entwarfen wir fast zwei Jahre lang in erster Linie was? Natürlich Gewinnspiele. Damals bedeutete „Nachhaltiger Wert“, die Nutzer vor der Teilnahme die entsprechende Seite liken zu lassen. An eine ernsthafte Diskussion über den Return on Investment, wie wir sie heute führen, war nicht zu denken.

Nun: Ich will nicht sagen, dass jedes Gewinnspiel schlecht war. Im Gegenteil! Im Vergleich zu der damaligen, durchschnittlichen Digitalkampagne programmierten wir hier bereits interaktive Meilensteine, die ihren Zweck mehr als nur erfüllten. Vor allem in der Akquise von Teilnehmern. Denn davon wimmelt es in dem sozialen Netzwerk nur so. Kein Nutzer war mehr allein und Freunde einzuladen wurde zum Standard.

Der „Login with Facebook“ hieß damals noch „Facebook Connect“ und war im Nachhinein betrachtet der Wegbereiter für ein modernes Single Sign On-Verfahren. Als Facebook damit bereits auf fast jedem Login-Screen vertreten war, zogen auch Google und Twitter nach – besser spät als nie!

Überhaupt, und das muss man Facebook zugute halten, waren sie hochgradig kompetitiv und bewegten sich unheimlich schnell vorwärts. Zwar blieben dabei auch einmal Dinge auf der Strecke, dafür wurden jedoch auch neue Features eingeführt. Zum Beispiel die Graph API: Mit einem besonders schlanken Interface, welches JSON-Antworten auf HTTP-Requests lieferte, war sie der Prototyp der modernen Web-API. Inzwischen gibt tatsächlich kaum mehr Startups, die eine solche Schnittstelle nicht anbieten.

Heute

 

Ich könnte an dieser Stelle noch sehr viel mehr Anekdoten auspacken: Open Graph Stories kamen, Offline Access verschwand, Review-Prozesse erhöhten die Qualität und das Vertrauen der Plattform – und Test-Nutzer verhindern nun, dass ich meine eigenen Freunde beim Testen von sozialen Features belästige.

Inzwischen kann jeder die Facebook Programmierschnittstelle benutzen – und sie erleichtert in der Tat mehr, als sie verkompliziert: Wer einen Login mit Facebook verwendet, spart sich das Nutzerhandling und erhöht die Conversation-Rates des eigenen Logins. Ja, nicht nur den Login sondern sogar die gesamte Datenhaltung kann man nun an den Facebook-eigenen Service „Parse“ abgeben.

Inzwischen ist die Facebook API mustergültig. Bei Twitter können API-Aufrufe nicht einfach so im Browser geprototyped werden, sondern benötigen in den meisten Fällen einen POST-Request.

Außerdem muss man hier auch zugeben, dass die wenigsten APIs versioniert sind. Facebook nutzte die Not von damals, um daraus heute eine Tugend zu machen. Dem Entwickler wird heutzutage ganz transparent kommuniziert, auf welche API-Version er setzt und wie lange diese noch unterstützt wird.

Kurz gesagt: Bisher war es Facebook-Büchern nie lange gegönnt, wirklich aktuell zu sein, da sich die Plattform unglaublich schnell entwickelte. Jetzt allerdings ist der Zeitpunkt für ein Buch so gut wie bisher nie, denn: Facebook veranstaltet die jährliche Entwicklerkonferenz F8 und mit API-Versionierung existiert nun ein System mit einem stabilen Referenzpunkt, auf den wir Autoren uns beziehen können. Durch die dokumentierten Änderungen an der API und auch den bestehenden Migrationspfaden kann der Leser diese sehr viel besser nachvollziehen.

Wer nun also damit anfangen möchte, sollte nicht mehr zögern und sich schleunigst das „Praxishandbuch Facebook-Programmierung„zulegen.

Und wer schon genauso lange dabei ist wie ich, der darf natürlich auch gerne persönlich mit mir melancholisch über die alten Tage lamentieren. (… und kauft sich das Buch am besten auch!)

Klaus Breyer ist Gründer und Geschäftsführer der buddybrand GmbH, dort verantwortlich für Technologien und Innovationen. Als Social-Media-Agentur begleitet buddybrand internationale Markenunternehmen wie ŠKODA International, airberlin, Heineken oder Storck (merci, Toffifee) durch die digitale Transformation, entwickelt Kampagnen und ist für Content- und Commmunity-Management zuständig. Immer an spannenden digitalen Geschäftsmodellen interessiert ist er in der deutschen Start-Up- und Technologie- Szene gut vernetzt. Seine Stärke ist es, technische Inhalte einfach und anschaulich zu erklären. Er ist deshalb gern gesehener Speaker auf Konferenzen und aktiver Blogger auf klaus-breyer.de