So wählen Sie eine zukunftssichere Subdomain-Struktur für Ihre SaaS-Web-App aus

Sie haben sich also endlich für den Namen Ihrer neuen SaaS-App entschieden und einen Domainnamen gekauft. Aufregende Zeiten!

Eine Ihrer ersten technischen Entscheidungen wird die Auswahl von Subdomains sein, für die die Webeigenschaften gehostet werden. Sie möchten nicht voreilig optimieren, aber indem Sie zu diesem Zeitpunkt eine sinnvolle Gruppe von Subdomains für Ihre verschiedenen Web-Eigenschaften auswählen, werden Sie dazu beitragen, diese Kopfschmerzen später zu vermeiden:

  • Marketingleute, die das Routing in Ihrer App brechen
  • Entwickler, die den Stil der Marketing-Site brechen
  • Verwaltung komplexer Umleitungskonfigurationen
  • Eine Notwendigkeit für Reverse-Proxys in Ihrer App-Architektur
  • SEO-Strafen

Trennen Sie Ihre Web-App von der Marketing-Website

Wenn Sie ein Ein-Personen-Team sind, das sowohl die Web-App erstellt als auch die Marketinginhalte schreibt, könnten Sie versucht sein, beide unter derselben Subdomain zu belassen. Schließlich könnten Sie Ressourcen wie CSS und Logos zwischen Websites gemeinsam nutzen und sparen sich die Kosten für separates Hosting.

Sie können jedoch in Zukunft nicht-technisches Marketingpersonal einstellen, das neue Inhalte hinzufügen oder vorhandene Inhalte ändern muss. Um ihnen das selbstständige Arbeiten zu erleichtern, möchten Sie vielleicht ein CMS (z. B. WordPress) verwenden. Dies müsste normalerweise auf einem eigenen Server ausgeführt werden und wäre wahrscheinlich nicht die gleichen serverseitigen Technologien, die Sie zum Erstellen Ihrer Webanwendung verwenden (z. B. Ruby/Rails, Nodejs/Express, Python/Django). Sie möchten sich auch keine Gedanken über Ausfallzeiten der Marketing-Website machen, wenn Sie Wartungsarbeiten an der App durchführen, oder über das Brechen von CSS-Stilen auf der Marketing-Website, wenn Sie eine Regel in der App ändern.

Die Verwendung derselben Subdomain schließt auch die Möglichkeit aus, eine statische CDN-gehostete Marketing-Website zu verwenden, um die Ladezeitleistung zu verbessern und die Hosting-Kosten zu senken.

Auswählen eines Subdomänennamens für Ihre App

Die einfachste Option ist einfach zu verwenden app da es nicht zu spezifisch in Bezug auf den Zweck ist, sodass Sie Ihre Optionen offen halten, sollte der Umfang der Web-App im Laufe der Zeit zunehmen. Dies ist B2B- und B2C-Benutzern vertraut und wird von beliebten Diensten wie verwendet YNAB, Sendgrid und Optimiert. Es hat auch den Vorteil, dass es kurz ist, wodurch URLs im Browser Ihres Benutzers leichter lesbar sind.

Andere gängige Optionen sind:

Bevorzugen Sie für Ihre Marketing-Site die nackte Domain gegenüber „www“.

Dies ist subjektiver als meine anderen Empfehlungen und es gibt Argumente dafür und dagegen beide Optionen aus UX- und technischer Konfigurationsperspektive. Meine Begründung für die Wahl der Naked-Domain (manchmal auch als Apex- oder Bare-Domain bezeichnet) gegenüber „www“ ist, dass letztere für die meisten Webbenutzer heute überflüssig ist und es die Naked-Domain ist ziemlich einfach in AWS Route 53 und CloudFront zu konfigurieren (Meine bevorzugten DNS- und statischen Website-Hosts).

Unabhängig davon, für welche Option Sie sich entscheiden, stellen Sie sicher, dass Ihre Website so konfiguriert ist, dass sie von einer zur anderen umgeleitet wird.

Halten Sie Ihre Marketing-Website und Ihren Blog auf derselben Subdomain

Ich würde empfehlen, Ihr Blog als Teil derselben Website wie Ihre Marketing-Website in einem Unterordner wie z mydomain.com/blog/. Marketing-Leute sind in der Regel die Leute, die die Marketing-Site und den Blog aktualisieren. Durch die Verwendung desselben CMS, das auf derselben Website gehostet wird, können sie ihre Änderungen einfacher vornehmen. Eine einzelne Website ermöglicht auch die Anwendung von Branding und Website-Layout (gemeinsame Kopf-, Navigations- und Fußzeile) an einem Ort. Darüber hinaus werden Analysen vereinfacht, da nur eine Web-Property in Google Analytics und der Google Search Console konfiguriert werden muss. Schließlich scheint es sich mittlerweile um SEO Best Practice zu handeln „Unterordner/Unterverzeichnisse gegenüber Subdomains bevorzugen“.

Belassen Sie Ihre API (vorerst) auf derselben Subdomain wie Ihre App

Diese Entscheidung spielt nur dann wirklich eine Rolle, wenn Sie Ihre API öffentlich zugänglich machen. Ich würde behaupten, dass Sie keine API als Teil von v1 Ihrer App öffentlich verfügbar machen sollten, da externe Inbound-Integrationen selten ein zentrales Must-Have-Feature für Ihre Benutzer sind. Zu diesem Zeitpunkt sollte Ihre API privat sein und nur von AJAX-Aufrufen aus Ihrer Web-App genutzt werden. Aus diesem Grund würde ich empfehlen, es für Ihre erste Version unter derselben Subdomain wie Ihre Hauptportal-App zu belassen, es sei denn, die API ist der absolute Kern Ihrer App (im Gegensatz zu nur einem Mittel zur Integration).

Wenn Sie sich entscheiden, Ihre API öffentlich verfügbar zu machen, sollten Sie in Erwägung ziehen, sie selbst zu hosten api Unterdomäne. Wie Sie den Code Ihrer App gestalten (dh in Modulen innerhalb einer einzelnen monolithischen App oder in einem separaten Repository unter einer Microservice-Architektur) geht weit über den Rahmen dieses Artikels hinaus. Wenn Sie jedoch separate Microservices für Ihre Web-App und Ihre API haben, müssten Sie einen Reverse-Proxy (z. B. Nginx) in Ihre Architektur einführen, um ein pfadbasiertes Routing einer Anfrage an den richtigen Service-Handler durchzuführen. Wenn Sie dagegen separate Subdomains haben, wird dieses Routing auf DNS-Ebene gehandhabt, was viel einfacher ist.

Verwenden Sie ein SSL-Zertifikat für alle Ihre Eigenschaften

Wenn Sie einige oder alle Ihre Webeigenschaften über HTTPS zugänglich machen möchten, können Sie dies mit einem einzigen SSL-Zertifikat tun, für das die folgenden 2 alternativen Subjektnamen konfiguriert sind:

mydomain.com
*.mydomain.com

Sie müssen einzelne Subdomains nicht explizit angeben, da sie alle durch den Platzhalter abgedeckt sind *. Die nackte Domäne wird jedoch nicht durch den Platzhalter abgedeckt, sodass sie als separates Element aufgeführt werden muss.

TL;DR

Halten Sie sich an die folgenden Empfehlungen und Sie werden nicht viel falsch machen:

  • Verwenden Sie Ihre nackte Domain (mydomain.com) für die Marketing-Site
  • Hosten Sie Ihr Blog als Teil der Marketing-Site unter der mydomain.com/blog/ oder mydomain.com/articles/ Ordnerpfad
  • Verwenden app.mydomain.com als Subdomain für die Web-App
  • Hosten Sie Ihre private API unter app.mydomain.com/api/v1/
  • Hosten Sie Ihre öffentliche API unter api.mydomain.com/v1/ (aber tun Sie dies nicht, bis es benötigt wird)
  • Verwenden Sie HTTPS für alle Eigenschaften

Ursprünglich erschienen bei winterwindsoftware.com

Similar Posts

Leave a Reply

Your email address will not be published.