Oplossing hosten meerdere PHP Web apps
Ik ben op zoek naar een oplossing om mijn PHP Web Applicatie (gebouwd met PHP, MySQL, jQuery, HTML, CSS) te hosten.
Het gaat om een Web Applicatie voor in de Horeca. Denk aan online inroosteren, inklokken, user management, bestellen etc.
Het uiteindelijke doel is om de web applicatie online te hosten zodat de restaurant vestigingen via het internet erbij kunnen.
Elk restaurant krijgt een eigen Web Applicatie en kan inmiddels door in te loggen gebruik maken van de web app.
Over de web app:
- Support laatste versie PHP
- Gebouwd op performance en veel javascript/jQuery om zoveel mogelijk dynamic content te genereren en dus zo weinig mogelijk scripts opnieuw te laden
- Maakt gebruik van lichte query's uit de MySQL database, sommige zijn zwaarder dan andere, denk aan DataTables vullen met data van de database. De zwaarste query is misschien wel alle producten uit de database halen wat per restaurant kan verschillen maar neem even voor het gemak 300 producten.
- Zowel medewerkers als hogere machten kunnen inloggen met verschillende rechten om verschillende taken te voltooien/in te zien
Uiteindelijke doel:
- Bijvoorbeeld 15 restaurants maken gebruik van de web app.
- Ieder restaurant eigen web app
- Moet gedurende de hele dag beschikbaar zijn op mobiel/tablet/laptop etc.
Mijn inzicht/oplossing:
_____________________________________________________________
1) Managed VPS waarbij je +- 10 klanten op 1 VPS laat draaien en elke restaurant een unieke subdomein geeft. Bijvoorbeeld: je hebt restaurant1 t/m restaurant10. Dan kan restaurant1 bij de web app dmv de volgende URL:
https://restaurant1.server01.nl/ en restaurant5 kan dan bij https://restaurant5.server01.nl/ (Met server01 uiteraard een andere domeinnaam)
- Link Managed VPS die ik gezien heb: https://www.sohosted.com/managed-vps/ (SMALL)
- TransIP VPS zien er ook goed uit, alleen weet ik niet of daar een managed VPS bij zit
Voordeel van Managed VPS:
- Hogere uptime (restaurant moet dag en nacht kunnen werken met het systeem zonder storingen)
- 24/7 storingdienst
- Sneller dan normale webhosting (weet ik niet zeker, zou een hele zware normale webhosting niet gewoon sneller zijn dan de goedkoopste managed VPS?)
- Goedkoper om te scalen
Nadelen:
- Op dit moment duur, omdat er nog geen betaalde klanten zijn
_____________________________________________________________
2) (Rond de 20 euro p/maand) Een normale zware webhosting. Waarbij je misschien maximaal 3 klanten per hosting laat draaien. En voor iedere 3 klanten een nieuwe hosting aanschaft.
- Link zware hosting die ik gezien heb: https://www.antagonist.nl/webhosting/ (Pro pakket)
Voordelen hosting:
- Op begin goedkoop, maar later duurder door scaling
- Qua snelheid misschien niet zo gek veel verschillend als goedkope managed VPS?
- Minder klanten per hosting pakket
Nadelen
- Later duurder door scaling
- Onoverzichtelijk, uiteindelijk heel veel hostingpakketten voor klanten
- Grotere kans op storingen
_____________________________________________________________
Op dit moment zijn dit de enige oplossingen die ik kan bedenken. Zelf geen technische kennis om bijvoorbeeld een unmanaged VPS op te zetten.
Als er iemand anders nog ideeën heeft om deze web app zo goed mogelijk te kunnen hosten voor de restaurants, graag! Ik sta open voor suggesties.
Gewijzigd op 02/07/2019 11:37:57 door Stan Avoird
In dat laatste geval zou ik gewoon gaan voor 1 domeinnaam;
Na het inloggen weet je voor welk bedrijf iemand inlogt en pas je daarop de web-app content aan.
Het enige grote verschil per restaurant is dus de config.php file even makkelijk gezegd waarin de database connectie wordt vastgesteld.
Het enige probleem is ,dat je na het inloggen niet weet voor welk bedrijf iemand inlogt.
Het gaat puur per gebruikersnaam & wachtwoord en de web app zoekt deze gegevens op in de MySQL database waarmee hij op dat moment verbonden is.
Daarom dacht ik er aan om voor elk restaurant een eigen FTP map te creeeren met de gehele web app daarin met de goede database config file.
Als men dan op https://restaurant1.server01.nl/ komt, correspondeert deze URL met de FTP map van het restaurant, en dus gelijk ook met de goede database.
Om nog verder te gaan, stel je hebt een IOS of Android APP. Dan kan ik dus eenmalig vragen aan de gebruiker van de APP: Welk restaurant server wil je connecten? De gebruiker kiest dan de juiste server. Deze instellingen worden opgeslagen bij in je mobiel bijvoorbeeld, en de volgende keer als je de APP opent start je gelijk op de goede server en kan je meteen inloggen.
Ook snap ik jouw antwoord, de gehele PHP Web app is generiek en dus voor elk restaurant hetzelfde. Dus waarom de PHP Web 700x in verschillende FTP mappen stoppen als het toch dezelfde app is.
Al weet ik niet goed hoe ik dit moet implementeren in mijn geval.
Mijn advies is: maak één codebase op één locatie waar op alle restaurants draaien. Aan de hand van de subdomein identificeer je het restaurant, waarmee je de juiste instellingen voor het restaurant kan ophalen, zoals de roosters, diensten, logo etc...
Technisch gezien komen alle subdomeinen dus op dezelfde locatie uit.
Ook moet je je afvragen of je voor elk restaurant een eigen database wilt aanmaken. Deze gelijk houden vraagt namelijk een goede gestroomlijnde workflow.
Verder raad ik aan om je hele applicatie op een managed VPS te plaatsen. Een shared webhosting pakket raad ik altijd af voor zakelijke toepassingen, vooral omdat je geen SLA hebt en geen eisen kan stellen over de server.
Gewijzigd op 02/07/2019 12:09:37 door - Ariën -
Zou een oplossing kunnen zijn?:
1. Restaurant connect via subdomein: https://restaurant01.server01.nl/
2. Komt op de inlogpagina, check met PHP de URL --> Subdomein = restaurant01
3. Get database connectie details via hardcoded PHP file? Of via een aparte mysql database waarin alle connectie details staan opgeslagen?
4. Dan de database connectie details ergens opslaan? In een SESSION? Is dit wel veilig?
5. Aan de hand van de opgeslagen database connectie telkens uit de SESSION o.i.d de inloggegevens halen en vanuit daar kan je querys gebruiken
Of stap 4. misschien gebruik maken van het opslaan van de database inlog details in een Redis object cache? Is het dan veilig om dat daaruit te halen?
>Ook moet je je afvragen of je voor elk restaurant een eigen database wilt aanmaken. Deze gelijk houden vraagt namelijk een goede gestroomlijnde workflow.
Dezelfde database gebruiken voor alle restaurants zou misschien niet zo veilig zijn. Ik moet dan ook alle query's gaan omschrijven en de database structuur aanpassen lijkt mij.
Bijvoorbeeld : SELECT * FROM .... WHERE .... AND restaurant_ID=1
Ik denk dat je zoiets bedoelt?
Gewijzigd op 02/07/2019 12:18:05 door Stan Avoird
In dat geval raad ik aan een configuratiebestand te maken, die voor het veiligheid gemak niet in jouw webroot staat maar daar boven.
Ik zou niet weten waarom je tijdelijk de database gegevens in een sessie of Redis-objecten wilt opslaan. Aan de hand van de subdomein weet je toch wel kan je moet gebruiken.
Gewijzigd op 02/07/2019 12:24:36 door - Ariën -
- Ariën - op 02/07/2019 12:22:41:
Wou je met meerdere databases werken dan?
In dat geval raad ik aan een configuratiebestand te maken, die voor het veiligheid gemak niet in jouw webroot staat maar daar boven.
In dat geval raad ik aan een configuratiebestand te maken, die voor het veiligheid gemak niet in jouw webroot staat maar daar boven.
Mij lijkt dat 1 database per restaurant meer performance geeft.
Stel je hebt 1 database voor 100 restaurants. En alle restaurants bij elkaar hebben 30.000 producten. Dan lijkt het mij langer te duren om SELECT * FROM producten WHERE restaurant=1 uit te voeren op die database met 30.000 rijen dan voor elk restaurant een aparte database te hebben.
Correct me if I'm wrong. Ik probeer de web app zo goed mogelijk op te zetten dat het zo makkelijk mogelijk te scalen is en dat het zeer gemakkelijk is om een nieuwe klant op te zetten.
Toch lijkt het mij niet onverstandig om te gaan denken over één grote database structuur, want in principe is de structuur van de database ook precies hetzelfde over alle restaurants, net als de codebase. Dus stel je moet ooit eens een database tabel aanpassen of toevoegen, moet je dat ook per restaurant weer gaan updaten.
Dit lijkt mij wel weer minder moeite, want je zou dat kunnen doen met behulp van een query die de PHP codebase uitvoert als een simpele update.
Bedankt dat je zo erg meedenkt! Waardeer ik zeer.
>Ik zou niet weten waarom je tijdelijk de database gegevens in een sessie of Redis-objecten wilt opslaan. Aan de hand van de subdomein weet je toch wel kan je moet gebruiken.
Inderdaad, dom. Eenmaal op de subdomein, kan je dus op elke pagina weer terugzien welk restaurant je bent en dus de correcte database gegevens ophalen uit de rootfolder waar bijvoorbeeld een config.php bestand staat met ALLE database connecties in van alle restaurants.
Gewijzigd op 02/07/2019 12:29:15 door Stan Avoird
Ik ken websites met databases van 50 GB.
En die hebben er geen enkel probleem mee
- 1 PHP codebase in de public_html folder
- 1 PHP config file voor database in een root folder, niet direct accessable
- 1 Subdomein per restaurant
- Bij elk PHP request/pageload check subdomein en aan de hand daarvan set een database OF set een restaurantId waarmee je uit de database kan lezen
- 1 Database voor alle restaurants. Gegevens gescheiden dmv unieke index restaurantId bijv.
- Alles draaiend op een managed VPS
Stel je hebt dan 500 restaurants. Dan heb je dus nogsteeds maar 1 PHP codebase, 1 Grote database met gegevens van alle medewerkers, producten, roosters etc. maar wel per database RIJ aangegeven bij welk restaurantId de gegevens horen
Dit ziet er al heel erg scalable uit!
Alleen gebruik ik honderden MySQL query's waarbij ik allemaal een conditie moet toevoegen om op restaurantId te checken als ik alles in 1 database wil gaan gebruiken. Klopt dit?
Is hier geen handig trucje voor?
Stel ik vergeet eens een keer de restaurantId conditie te checken bij een query, dan heeft dat meteen invloed op ALLE rijen van andere restaurants. Dit is best gevaarlijk.
Bestaat er iets als in PHP om een query vóórdat het wordt uitgevoerd een check te doen?
Bijvoorbeeld
$stmt = $conn->query("SELECT * FROM table");
//Hier een check: if query does not contain "WHERE restaurantId=?" statement, then do not execute
Lijkt me een simpele maar efficiente oplossing om snelle fouten tegen te gaan.
Hoe weet een transactie dat het moet rollbacken/niet committen als er een bepaalde conditie niet in de query staat.
SELECT * FROM table
of
SELECT * FROM table WHERE restaurantId=?
Zijn allebei goede query's en worden allebei uitgevoerd. Alleen willen we de eerste vermijden, omdat we daar de conditie zijn vergeten te checken.
Zie ook: http://www.mysqltutorial.org/mysql-transaction.aspx
Gewijzigd op 02/07/2019 13:25:14 door - Ariën -
Hier kan ik zeker wat mee.
Op dit moment zijn we nog druk met het ontwikkelen van de web app zelf.
Zodra dit helemaal klaar moeten we het een en ander ombouwen om zo als 1 database en 1 codebase te functioneren. Maar scheelt het wel erg veel tijd in de toekomst.
Ward van der Put op 02/07/2019 14:01:38:
Dit los je niet op met trucs en tests, maar met een goede softwarearchitectuur. Als je het geheel objectgeoriënteerd bouwt, kan één specifiek restaurant nooit worden verward met een lijst met meerdere restaurants: dat zijn twee compleet verschillende objecten.
Op dit moment is de web app vooral opgebouwd uit losstaande PHP codes en query's en zijn maar enkele dingen in objecten/classes opgeslagen.
Het klopt op dit moment vooral allemaal op de front-end. De back-end werkt, maar kan zeker beter.
Hoe zou een specifiek restaurant nooit verward kunnen worden met een lijst met meerdere restaurants door gebruik te maken van objectorientated programming volgens jou?
Ik zou wat praktische voorbeelden erg waarderen.
Quote:
Stel je hebt 1 database voor 100 restaurants. En alle restaurants bij elkaar hebben 30.000 producten. Dan lijkt het mij langer te duren om SELECT * FROM producten WHERE restaurant=1 uit te voeren op die database met 30.000 rijen dan voor elk restaurant een aparte database te hebben.
Heb je dit al eens getoetst? Oftewel getest op de hardware waar deze database(s) actief zou(den) moeten zijn? Als je indexen aanmaakt dan zou dit niet zoveel uit moeten maken. Zoals iemand ooit eens zei: meten = weten.
En dan is het bovenstaande slechts één argument: performance. Maar is er uit optiek van de data zelf een reden om alles in één database te stoppen? En misschien zou je het app-beheer (site voor beheren restaurants) en het app-gebruik (site/subdomein voor restaurant zelf) uit elkaar kunnen trekken?
Mogelijk moet je ook gaan nadenken hoe je het toevoegen van een restaurant automatisch kunt uitrollen (toevoegen nieuw restaurant in beheer database, creëren nieuwe bijbehorende restaurant-database, als je deze aanpak kiest). Hier valt een heleboel te automatiseren lijkt mij.
Quote:
Dus stel je moet ooit eens een database tabel aanpassen of toevoegen, moet je dat ook per restaurant weer gaan updaten.
En dat is een indicatie dat je ook moet nadenken over upgrades en eventueel maatwerk die je bijvoorbeeld in modules en restaurant-specifieke tabellen stopt, zodat je je core-functionaliteit (van zowel code als database) gelijk houdt zodat je met je updates geen maatwerk overschrijft :).
Hoe meer aandacht je besteedt aan het ontwerp, hoe minder ellende down the line, lijkt mij. En ja, dit zouden alle echte relationele databases moeten zijn, zodat onderlinge data consistent blijft.
@Ariën, transacties zijn onderling niet (per definitie) atomair. Gaat dat voorbeeld wel goed in die tutorial? Wat nu als twee van dat soort transacties tegelijkertijd uitgevoerd worden? Ik vermoed dat dat alsnog vreselijk mis kan gaan met het orderNumber? Of de laatst gecommitte faalt gewoon omdat het orderNumber dan al is ingenomen? En waarom gebruikt die gast niet gewoon een auto-increment veld? :p
Gewijzigd op 02/07/2019 14:17:37 door Thomas van den Heuvel
Stan Avoird op 02/07/2019 13:16:11:
SELECT * FROM table
of
SELECT * FROM table WHERE restaurantId=?
of
SELECT * FROM table WHERE restaurantId=?
Die tweede query programmeer je maar één keer: in een object (een mapper bijvoorbeeld) dat een ander object (een restaurant) uit de database haalt. De rest van de code laat je uitsluitend met dat tweede object als model werken.
Je programmeert sowieso alles maar één keer. DRY: Don’t Repeat Yourself. Er is veel voor te zeggen om ook de eerste query maar op één plek in je gehele architectuur te laten voorkomen.
Dit maakt je oplossing robuust en schaalbaar: de component die verantwoordelijk is voor "haal alle restaurants op" kun je verbouwen of vervangen zonder dat het gevolgen voor de rest heeft.
Quote:
Heb je dit al eens getoetst? Oftewel getest op de hardware waar deze database(s) actief zou(den) moeten zijn? Als je indexen aanmaakt dan zou dit niet zoveel uit moeten maken. Zoals iemand ooit eens zei: meten = weten.
En dan is het bovenstaande slechts één argument: performance. Maar is er uit optiek van de data zelf een reden om alles in één database te stoppen? En misschien zou je het app-beheer (site voor beheren restaurants) en het app-gebruik (site/subdomein voor restaurant zelf) uit elkaar kunnen trekken?
Mogelijk moet je ook gaan nadenken hoe je het toevoegen van een restaurant automatisch kunt uitrollen (toevoegen nieuw restaurant in beheer database, creëren nieuwe bijbehorende restaurant-database, als je deze aanpak kiest). Hier valt een heleboel te automatiseren lijkt mij.
En dan is het bovenstaande slechts één argument: performance. Maar is er uit optiek van de data zelf een reden om alles in één database te stoppen? En misschien zou je het app-beheer (site voor beheren restaurants) en het app-gebruik (site/subdomein voor restaurant zelf) uit elkaar kunnen trekken?
Mogelijk moet je ook gaan nadenken hoe je het toevoegen van een restaurant automatisch kunt uitrollen (toevoegen nieuw restaurant in beheer database, creëren nieuwe bijbehorende restaurant-database, als je deze aanpak kiest). Hier valt een heleboel te automatiseren lijkt mij.
Nog niet getoetst. Maar inderdaad, als je gewoon een index aanmaakt die dat sorteert. Heeft het niks te maken met de andere rijen die in de database tabel staan.
Het zou voor de scalability beter zijn als je alle data van alle restaurants in 1 database propt.
Hiermee wordt 1 database dan wel erg groot en moet je specifieke query's schrijven die sorteren op index restaurantId, maar de backups gaan simpeler, want je hoeft maar 1 database te backupen. Ook het updaten van de database structuur hoeft maar 1x uitgevoerd te worden wanneer nodig is, omdat er maar 1 database is.
Mij lijkt dit dus wel een goede oplossing. Echter heb ik nogsteeds niet echt een overzicht gekregen voor mezelf hoe ik al de huidige query's wil gaan omschrijven dat ze die specifieke "WHERE restaurantId=?" conditie gaan gebruiken.
In 80% van mijn web app gebruik ik wel een functie die gemakkelijk een query prepared en dan executed.
Als ik deze 80% , 100% kan maken. Dan kan ik vóórdat deze functie de query executed, checken of de query de specifieke conditie "WHERE restaurantId=?" bevat.
Zo niet, dan wordt de query gewoon niet uitgevoerd.
Zo vermijd ik dat er per ongeluk query's worden uitgevoerd voor alle restaurants in plaats van een specifieke restaurant.
Het toevoegen van een restaurant zou in principe vrij simpel moeten zijn als ik de volgende structuur aanhoudt:
Quote:
Dus het eindscenario zou kunnen zijn:
- 1 PHP codebase in de public_html folder
- 1 PHP config file voor database in een root folder, niet direct accessable
- 1 Subdomein per restaurant
- Bij elk PHP request/pageload check subdomein en aan de hand daarvan set een database OF set een restaurantId waarmee je uit de database kan lezen
- 1 Database voor alle restaurants. Gegevens gescheiden dmv unieke index restaurantId bijv.
- Alles draaiend op een managed VPS
- 1 PHP codebase in de public_html folder
- 1 PHP config file voor database in een root folder, niet direct accessable
- 1 Subdomein per restaurant
- Bij elk PHP request/pageload check subdomein en aan de hand daarvan set een database OF set een restaurantId waarmee je uit de database kan lezen
- 1 Database voor alle restaurants. Gegevens gescheiden dmv unieke index restaurantId bijv.
- Alles draaiend op een managed VPS
Nieuw restaurant/klant:
1. Maak nieuwe subdomein aan
2. Update een bestandje of database dat een uniek restaurantId aan het nieuwe subdomein koppelt
3. Klaar?
Wanneer het nieuwe restaurant naar haar subdomein gaat, wordt bij aanvang op de web app gevraagd welk restaurantId er bij het subdomein wordt en wordt deze gebruikt voor alle verdere acties op de web app.
Waar ik trouwens nog niet over heb nagedacht is bijvoorbeeld het uploaden van een logo of bestand. Nu wordt dit geupload naar een specifieke FTP map bijvoorbeeld: server01.nl/uploads/logo.png
Hier moet ik ook iets op gaan verzinnen dat de bestanden gescheiden blijven per restaurant. En dat een restaurant niet zomaar bij de files kan van een ander restaurant.
Quote:
Die tweede query programmeer je maar één keer: in een object (een mapper bijvoorbeeld) dat een ander object (een restaurant) uit de database haalt. De rest van de code laat je uitsluitend met dat tweede object als model werken.
Je programmeert sowieso alles maar één keer. DRY: Don’t Repeat Yourself. Er is veel voor te zeggen om ook de eerste query maar op één plek in je gehele architectuur te laten voorkomen.
Dit maakt je oplossing robuust en schaalbaar: de component die verantwoordelijk is voor "haal alle restaurants op" kun je verbouwen of vervangen zonder dat het gevolgen voor de rest heeft.
Je programmeert sowieso alles maar één keer. DRY: Don’t Repeat Yourself. Er is veel voor te zeggen om ook de eerste query maar op één plek in je gehele architectuur te laten voorkomen.
Dit maakt je oplossing robuust en schaalbaar: de component die verantwoordelijk is voor "haal alle restaurants op" kun je verbouwen of vervangen zonder dat het gevolgen voor de rest heeft.
Ik begin meer in te zien hoe dit werkt in de praktijk.
Moet ik dan functies gaan maken die een query generaliseren?
Bijvoorbeeld ik wil een rij updaten in table "producten" waar de naam van het product "Appel" is.
Nu is er gewoon een losse query:
$conn->query("UPDATE producten SET amount=1 WHERE name='Appel'");
Maar we willen, als we alles in 1 database stoppen, naar de volgende query:
$conn->query("UPDATE producten SET amount=1 WHERE name='Appel' AND restaurantId=1");
Hoe kan ik dit het beste aanpakken dan?
Door een functie en class bijvoorbeeld aan te maken die iets generieks uitvoert?
Restaurant->updateQuery($table, $SET, $WHERE);
waarbij updateQuery er ongeveer zo uitziet:
function updateQuery($table, $SET, $WHERE) {
//functie staat in class Restaurant, en class Restaurant bevat al restaurantId=1
$conn->query("UPDATE $table SET $SET WHERE $WHERE AND restaurantId=".restaurantId);
}
Dit is een zeer simpel voorbeeld, maar denk ik in de goede richting?
Bedankt iedereen nogmaals voor het meedenken!
Gewijzigd op 02/07/2019 14:56:40 door Stan Avoird