Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt? Bekijk dan ons cookiebeleid.

Meer informatie
Toon posts:

SaaS oplossing | subdomein per account - Hoe?

Pagina: 1
Acties:

Vraag


  • pgerrits
  • Registratie: april 2008
  • Laatst online: 15-06 14:10
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.

Alle reacties


  • Alm4riC
  • Registratie: februari 2005
  • Laatst online: 13:56
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]


Acties:
  • +2Henk 'm!

  • Woy
  • Registratie: april 2000
  • Niet online

Woy

Moderator Devschuur®
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]

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • dev10
  • Registratie: april 2005
  • Laatst online: 14:45
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
  • Registratie: januari 2000
  • Niet online

downtime

Everybody lies

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.

Acties:
  • +1Henk 'm!

  • Freeaqingme
  • Registratie: april 2006
  • Laatst online: 16:14
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.

No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.


  • pgerrits
  • Registratie: april 2008
  • Laatst online: 15-06 14:10
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.

Acties:
  • +1Henk 'm!

  • Woy
  • Registratie: april 2000
  • Niet online

Woy

Moderator Devschuur®
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.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • Woy
  • Registratie: april 2000
  • Niet online

Woy

Moderator Devschuur®
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 :)

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • Freeaqingme
  • Registratie: april 2006
  • Laatst online: 16:14
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.

No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.


  • Freeaqingme
  • Registratie: april 2006
  • Laatst online: 16:14
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.

No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.


Acties:
  • +1Henk 'm!

  • Woy
  • Registratie: april 2000
  • Niet online

Woy

Moderator Devschuur®
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.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • downtime
  • Registratie: januari 2000
  • Niet online

downtime

Everybody lies

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
  • Registratie: juni 2006
  • Nu online
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.
Pagina: 1


Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Microsoft Xbox Series X LG CX Google Pixel 5a 5G Sony XH90 / XH92 Samsung Galaxy S21 5G Sony PlayStation 5 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True