SaaS oplossing | subdomein per account - Hoe?

[pgerrits]

Misschien een hele suffe vraag en zit ik veeeeeel te moeilijk te denken. Er zijn diensten zoals Shopify, Wordpress.com, maar ook teachable.com en vast nog vele andere die werken met een subdomein per account.

Dus als je een account maakt op 1 van die sites krijg jij een url zoiets als: xxxxx.shopify.com of xxxxx.teachable.com.

Zijn dat nu echte losse sites (folder in de webserver) of is dit alleen een DNS dingetje die vervolgens in de frontend/backend wordt gebruikt voor routering, identificatie, etc etc.

Ik ben al dagen aan het googlen en zoeken maar ik kom niet heel veel verder dan wat "ideeën" hoe je dit zou kunnen doen met Nginx.

Maar hoe werkt dit? Wat uiteindelijk kan je je eigen domein zoals mijneigenwebwinkel.nl linken aan je shopify subdomein. Dus mijneigenwebwinkel.nl -> xxxxxx.shopify.com

Als dat code matig gedaan zou zijn, dan ben je toch je ID kwijt in de url als je via de domein mask gaat?

Ik hoef niet perse een klip en klaar voorbeeld te weten, maar een boek, talk, artikel o.i.d.. is ook al prima. Ik zoek me rot maar kan het niet vinden.

[Alm4riC]

Ik denk dat je opzoek bent naar Multitenancy. Hoe dit exact in elkaar zit weet ik niet, maar ik denk het een combinatie is van hun eigen geschreven software een wildcard subdomain *.shopify.com.

Zodra je een account aanmaakt wordt er een block gereserveerd, bijvoorbeeld pgerrits.shopify.com en het verkeer voor dat domein gerouteerd naar een eigen map. Reden om aan te nemen dat elke gebruiker een eigen map krijgt is omdat je ook thema en plugin bestanden kan aanpassen.

Ik weet er het fijne niet van, maar ik denk dat je met deze keywords al een stapje in de goede richting komt

Edit:
Reddit link met wat info : https://www.reddit.com/r/..._shopify_and_squarespace/

[Voor 8% gewijzigd door Alm4riC op 12-03-2021 08:39]

[Woy]

In de basis zal dit gewoon gedaan worden door op de server de host header te interpreteren. In je webserver kun je gewoon een wildcard binding instellen ( Voor Azure hier bijvoorbeeld documentatie: https://azure.microsoft.c...tes-and-wildcard-domains/, maar voor andere oplossingen verschilt het niet veel ).

In de software wordt die header dan gewoon geinterpreteerd, en aan de hand van die informatie wordt andere content geserveerd.

Bij dergelijke SaaS providers zal er echt niet per tenant een nieuwe versie van de software gedeployed worden. Er zullen natuurlijk wel meerdere servers zijn, en het is ook prima mogelijk dat een reverse proxy het request aanpast en de tenant in de querystring opneemt, of een header, maar dat veranderd de implementatie aan de serverkant niet echt veel.

Verder zal er vast op een slimme manier aan load-balancing gedaan worden, waarbij bijvoorbeeld rekening gehouden wordt vanuit welke regio een request komt, maar ook dat veranderd de implementatie van de daadwerkelijke software niet echt, dat is puur een stukje infrastructuur.

[Voor 42% gewijzigd door Woy op 12-03-2021 09:55]

[dev10]

Zijn dat nu echte losse sites (folder in de webserver) of is dit alleen een DNS dingetje die vervolgens in de frontend/backend wordt gebruikt voor routering, identificatie, etc etc.

Dit zijn geen losse folders in de webserver. Je zorgt er voor dat de webserver elke subdomein accepteert en dan kun je in de applicatie zelf de routering regelen. In Laravel kan dat bijvoorbeeld zo: https://laravel.com/docs/...e-group-subdomain-routing

[downtime]

Alm4riC schreef op vrijdag 12 maart 2021 @ 08:38:
Ik denk dat je opzoek bent naar Multitenancy. Hoe dit exact in elkaar zit weet ik niet, maar ik denk het een combinatie is van hun eigen geschreven software een wildcard subdomain *.shopify.com.

Een wildcard subdomain bestaat niet in DNS. DNS kent (zover ik weet maar ben geen netwerkspecialist) name-records (bv www onder tweakers.net) en één default record die ervoor kan zorgen dat tweakers.net ook gewoon naar dezelfde server als www.tweakers.net kan gaan.
Maar als je duizenden of zelfs miljoenen tenants met een eigen subdomain wilt hosten dan moet je die volgens mij allemaal in DNS opvoeren. Wat natuurlijk gewoon geautomatiseerd kan worden.

Wat de vraag van TS lastig te beantwoorden maakt is dat er meerdere wegen naar Rome leiden.

[Freeaqingme]

downtime schreef op vrijdag 12 maart 2021 @ 14:38:
[...]

Een wildcard subdomain bestaat niet in DNS.

DNS support weldegelijk een record aanmaken met een wildcard. Je kan bijvoorbeeld *.example.com met een A record laten verwijzen naar 127.0.0.1. Als je dan ook nog een 'www' record aanmaakt dan prevaleert die.

Dit heeft wel twee nadelen:
- Een wildcard record werkt maar voor 1 niveau diep. Dwz dat '*.example.com' wel werkt voor 'foobar.example.com', maar niet voor 'www.foobar.example.com'.
- Het gaat op deze manier altijd naar dezelfde (groep) servers/loadbalancers. Daar creeer je dan wel makkelijk een bottleneck.

Daarom zie je vaak dat men een dns-server configureert waarbij er een dynamische backend is welke on-the-fly opzoekt in de database welk ip er bij hoort. Of je doet dan bijvoorbeeld dat alle subdomeinen die met een A beginnen naar 127.0.0.1 gaan, alles met een B naar 127.0.0.2, etc.

[pgerrits]

downtime schreef op vrijdag 12 maart 2021 @ 14:38:

Maar als je duizenden of zelfs miljoenen tenants met een eigen subdomain wilt hosten dan moet je die volgens mij allemaal in DNS opvoeren. Wat natuurlijk gewoon geautomatiseerd kan worden.

Wat de vraag van TS lastig te beantwoorden maakt is dat er meerdere wegen naar Rome leiden.

Meerderen wegen = prima. Maar ik ben er dus nog niet helemaal uit. Kijk ik ben gewoon even aan het freeweelen en aan het brainstormen over een project. Ik ben ook geen netwerkspecialist en ben eigenlijk een beetje op zoek naar richting voor een oplossing.

Het gaat geen duizenden domeinen worden, maar wel een paar honderd.

Als ik het nu even samenvat kom ik erop dat je het kan oplossen met DNS door middel van een 'wildcard/catch-all'.

De vraag is dan natuurlijk alleen hoe je dan inderdaad om gaat met separate instellingen zoals een plugin/design. De architectuur die ik nu voor ogen heb zou inderdaad het shopify model zou zijn met mogelijk een eigen design/css/template.

Let wel: Het is niet mijn bedoeling om hier een oplossing te krijgen. Uiteindelijk gaat iemand dit maken en bouwen, maar ik wil vanuit ontwerp/architectuur hier over nadenken en ook een beter gevoel krijgen bij de uiteindelijke realisatie hiervan.

[Woy]

pgerrits schreef op vrijdag 12 maart 2021 @ 15:18:
[...]
De vraag is dan natuurlijk alleen hoe je dan inderdaad om gaat met separate instellingen zoals een plugin/design. De architectuur die ik nu voor ogen heb zou inderdaad het shopify model zou zijn met mogelijk een eigen design/css/template.

Gewoon in je applicatie afvangen, dus gewoon de host-header lezen, aan de hand daarvan je tenant bepalen, en daar je applicatielogica/resources op aanpassen.

[Woy]

Freeaqingme schreef op vrijdag 12 maart 2021 @ 14:44:
[...]
Daarom zie je vaak dat men een dns-server configureert waarbij er een dynamische backend is welke on-the-fly opzoekt in de database welk ip er bij hoort. Of je doet dan bijvoorbeeld dat alle subdomeinen die met een A beginnen naar 127.0.0.1 gaan, alles met een B naar 127.0.0.2, etc.

Er zijn inderdaad uitgebreide DNS loadbalancing opties, in de cloud bijvoorbeeld Amazon Route 53 of Azure Traffic Manager. Die kunnen ook aan de hand van regios en availability de juiste DNS resolven.

Maar dat lijkt mij voor nu nog een beetje buiten de scope van de TS

[Freeaqingme]

pgerrits schreef op vrijdag 12 maart 2021 @ 15:18:
[...]

De vraag is dan natuurlijk alleen hoe je dan inderdaad om gaat met separate instellingen zoals een plugin/design. De architectuur die ik nu voor ogen heb zou inderdaad het shopify model zou zijn met mogelijk een eigen design/css/template.

Let wel: Het is niet mijn bedoeling om hier een oplossing te krijgen. Uiteindelijk gaat iemand dit maken en bouwen, maar ik wil vanuit ontwerp/architectuur hier over nadenken en ook een beter gevoel krijgen bij de uiteindelijke realisatie hiervan.

Als je zoekt op multi tenancy kan je daar van alles over vinden. Vooral over de vraag of je wel/niet alles in 1 database wil doen, of 1 db per klant wil aanmaken. Mijn suggestie zou zijn om alles in 1 database te stoppen zodat het makkelijk beheersbaar blijft. Dan sla je in elke tabel gewoon op voor welke klant het is.

Dat stelt je in staat te focussen op je featureset en minder op je infra. Tegen de tijd dat je product dusdanig groot is dat je echt tegen problemen aanloopt (en die kans is heel klein, want database systemen kunnen echt _heel veel_ hebben) dan heb je ook tzt wel voldoende man in dienst om dat voor je op te lossen.

Als je niet eerst focust op functionaliteit, dan zal je - vermoedelijk - nooit groot genoeg worden om dit probleem uberhaupt te tackelen.

[Freeaqingme]

Woy schreef op vrijdag 12 maart 2021 @ 15:37:
[...]

Er zijn inderdaad uitgebreide DNS loadbalancing opties, in de cloud bijvoorbeeld Amazon Route 53 of Azure Traffic Manager. Die kunnen ook aan de hand van regios en availability de juiste DNS resolven.

Het kan natuurlijk ook prima met een simpele PowerDNS setup. Net wat je ding is

Woy schreef op vrijdag 12 maart 2021 @ 15:37:
[...]

Maar dat lijkt mij voor nu nog een beetje buiten de scope van de TS

Zeker waar. Het topic begon (m.i.) een beetje als 'hoe doen bedrijven dit', daarom dacht ik even te schetsen wat voor oplossingsrichtingen er zoal zijn. Naar mate het meer concreet en minder abstract wordt denk ik dat je inderdaad kan stellen dat die scope voorlopig niet aan de orde is.

[Woy]

Freeaqingme schreef op vrijdag 12 maart 2021 @ 15:42:
[...]
Het kan natuurlijk ook prima met een simpele PowerDNS setup. Net wat je ding is

Sure, ik zit meer in de cloud-hosted software, dan is een dergelijke oplossing een stuk makkelijker, en meestal dus ook goedkoper dan zelf wat met PowerDNS gaan doen

Als je meer zelfhosted doet dan is het waarschijnlijk inderdaad een ander verhaal.

[downtime]

Freeaqingme schreef op vrijdag 12 maart 2021 @ 14:44:
[...]


DNS support weldegelijk een record aanmaken met een wildcard. Je kan bijvoorbeeld *.example.com met een A record laten verwijzen naar 127.0.0.1. Als je dan ook nog een 'www' record aanmaakt dan prevaleert die.

Dit heeft wel twee nadelen:
- Een wildcard record werkt maar voor 1 niveau diep. Dwz dat '*.example.com' wel werkt voor 'foobar.example.com', maar niet voor 'www.foobar.example.com'.
- Het gaat op deze manier altijd naar dezelfde (groep) servers/loadbalancers. Daar creeer je dan wel makkelijk een bottleneck.

Daarom zie je vaak dat men een dns-server configureert waarbij er een dynamische backend is welke on-the-fly opzoekt in de database welk ip er bij hoort. Of je doet dan bijvoorbeeld dat alle subdomeinen die met een A beginnen naar 127.0.0.1 gaan, alles met een B naar 127.0.0.2, etc.

Je hebt gelijk. Ik heb dus altijd verkeerd begrepen wat het wildcard record in DNS doet. Blijkbaar werkt het niet alleen als je geen servernaam opgeeft (bv. example.com) maar ook met niet-bestaande namen (bv. zxcvbnm.example.com).
Dus zelfs een "domme" DNS-server kun je configureren om alle (niet bestaande) subdomeinen naar hetzelfde IP adres te verwijzen.

Ik zie zelfs dit in het Wikipedia artikel over wildcard DNS records:

Registrants
Wildcard domains are widely used by blogging websites that allow users to create sub-domains upon demand; e.g., sites such as WordPress or Blogspot. Another popular use is by Free Dynamic DNS websites that allow users to create a DNS name that changes to match their host IP as the IP address is changed periodically by their ISP's DHCP server.

Gelukkig heb ik nooit een situatie gehad waar het verschil relevant was. De enige vraag die ik in de praktijk ooit heb gekregen was hoe je example.com laat redirecten naar www.example.com. En daarop heb ik dus wel het juiste antwoord gegeven.

[ThomasG]

Je kunt dit op verschillende manieren doen, welke allemaal andere voor- en nadelen hebben. Microsoft heeft hier een goed artikel over geschreven, gericht op Azure maar in de basis overal op toepasbaar. Microsoft.com: Multi-tenant SaaS database tenancy patterns.