Oplossing hosten meerdere PHP Web apps

Door Stan Avoird op 02-07-2019 11:25 gewijzigd op 02-07-2019 11:37

5.557 views

Beste allemaal,

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.

Ozzie PHP

03-07-2019 11:51

Externe partijen (programmeurs, webdesigners) die weten als het goed is waar ze mee bezig zijn, maar je moet maar beter niet tegen de eigenaar/manager van een restaurant zeggen: hier is je FTP-toegang en via "main.css" kun je de lay-out aanpassen, maar vergeet ook niet de cache te flushen.

Is maar even een voorbeeld, maar je snapt ongetwijfeld wat ik bedoel ;)

S Stan Avoird

03-07-2019 11:51

Ozzie PHP op 03/07/2019 11:38:05

Ik denk dat wat Thomas probeert te zeggen, is dat je de eigenaren/personeel van een restaurant niet zou moeten willen lastigvallen met techniek. En daar heeft hij een punt. Ieder z'n vak.

Inderdaad, uit ervaring heb ik geleerd dat het in de praktijk zo makkelijk mogelijk moet zijn. het liefst moeten ze alles kunnen doen met 1 klik op de knop. Alles moet automatisch gaan, het systeem moet denken voor de klant. Het moet gewoon kloppen en werken

Daar heeft hij gelijk in, maar ik heb het idee dat de topicstarter ook sites wil aan kunnen bieden voor restaurants. En die wil je liever geen uniforme stijl meegeven. In dat geval zouden (externe) webdesigners prima via FTP templates (Twig, Smarty, whatever) de site kunnen samenstellen. Deze techniek heb ik al eerder gezien bij een aantal aanbieders met betaal- en reserveringssystemen voor winkels.

Alle restaurants vragen uiteindelijk precies dezelfde FTP bestanden aan om zo de web app te viewen.
Wat inderdaad opties zouden kunnen zijn om het systeem eigen te maken qua style later zijn:
1. Restaurants toegang geven tot hun eigen specifieke FTP map waarin ze CSS sheets kunnen uploaden en dan via de web app kunnen instellen dat ze deze willen gebruiken. Waarschijnlijk kan dit makkelijk met Twig, Smarty o.i.d. Maar daar ben ik op dit moment niet bekend mee
2. Via de web app zelf als administrator opties maken waarin je het kleurenschema kan aanpassen, logo's, positioneringen van grids etc.

Maar dit zijn opties voor later. Eerst moet de web app af zijn, kunnen draaien op een server, en dan komen de extraatjes pas.

Ramon van Dongen

03-07-2019 15:07

Restaurants toegang geven tot hun eigen specifieke FTP map waarin ze CSS sheets kunnen uploaden

Ik zou voor een optie gaan waar ze in de web app de kleuren aan kunnen passen. Mocht je echt css sheets willen laten uploaden; gewoon middels een upload formulier in je webapp.

Als de FTP alleen maar is om stylesheets aan te passen, ga je iets simpels voor veel (niet programmeurs) mensen in een keer heel moeilijk maken.

- Ariën -

03-07-2019 15:21 gewijzigd op 03-07-2019 15:23

Een backend om eenvoudig wat site dingen aan te passen, zou handig zijn. Als een restaurant een eigen gestylde site wilt zonder beperkingen, dan is FTP wel handig voor de webdesigner.

Het ligt er net aan hoever je wilt gaan.

S Stan Avoird

03-07-2019 22:07

Even weer on topic:

Stel ik werk met 1 grote database voor alle restaurants die elk hun eigen data kunnen opvragen dmv een index restaurantId.
En stel er zijn 100 restaurants die allemaal tegelijkertijd dingen aan het doen zijn: inroosteren, producten opvragen etc.
Dan zijn er misschien wel 500+ database connecties en acties tegelijkertijd.
Stel de MySQL server loopt eventjes vast, dan hebben al die 100 restaurants daar gelijk last van.

Nu zit ik dan toch te denken of dit wel de beste oplossing is?
Is dit nog wel praktisch dan eigenlijk?

Aan de andere kant, hoe doet een heel erg drukbezochte website dat dan met 10.000 bezoekers per dag die ook werkt met gegevens uit database halen?
Mij lijkt dat deze website dan ook maar 1 database heeft waar die 10.000 bezoekers gebruik van maken.

- Ariën -

03-07-2019 22:21 gewijzigd op 04-07-2019 10:18

Een website die graag zo min mogelijk downtime wilt hebben, gebruikt op zulke momenten een extra database server, welke door middel van replicatie gelijk loopt. Ik weet dat ze bij Tweakers dit doen verdeeld over twee datacenters.

Regelmatig schrijven ze wel eens artikelen over hun serverpark. Misschien kan je op hun website wat interessants vinden over zo een opzet.

Leuke tutorial:
https://www.digitalocean.com/community/tutorials/how-to-set-up-master-slave-replication-in-mysql

R Rob Doemaarwat

03-07-2019 23:07

Stan Avoird op 03/07/2019 22:07:11

Stel de MySQL server loopt eventjes vast

Of je dan 100 restaurants in 1 database hebt, of elk restaurant z'n eigen database, op dat moment hebben ze toch allemaal een probleem.

Voor schaalbaarheid is het toch echt het handigst als je alles in 1 database hebt. 100 kopieën van exacte hetzelfde is altijd vragen om problemen (of het nou code is, of databases - op een dag kom je er achter dat ze toch niet allemaal exact gelijk zijn, en dan begint het gedonder ...)

S Stan Avoird

04-07-2019 10:20

Een website die is zo min mogelijk downtime wilt hebben, gebruikt op zulke momenten een extra database server, welke door middel van replicatie gelijk loopt. Ik weet dat ze bij Tweakers dit doen verdeeld over twee datacenters.

Regelmatig schrijven ze wel eens artikelen over hun serverpark. Misschien kan je op hun website wat interessants vinden over zo een opzet.

Leuke tutorial:
https://www.digitalocean.com/community/tutorials/how-to-set-up-master-slave-replication-in-mysql

Klinkt zeker als een oplossing, thanks!

Ik moet natuurlijk op dit moment wel rekening houden met de scalability van de web app, maar wat valt er te scalen als ik nog geen users heb. Dus eerst daar maar op focussen.

Of je dan 100 restaurants in 1 database hebt, of elk restaurant z'n eigen database, op dat moment hebben ze toch allemaal een probleem.

Voor schaalbaarheid is het toch echt het handigst als je alles in 1 database hebt. 100 kopieën van exacte hetzelfde is altijd vragen om problemen (of het nou code is, of databases - op een dag kom je er achter dat ze toch niet allemaal exact gelijk zijn, en dan begint het gedonder ...)

Dat is waar. Eerst maar eens klantjes zien te scoren, en dan kan ik later altijd nog kijken naar meerdere servers/databases die gelijk lopen etc.

Ben nu de web app aan het ombouwen dat het kan werken als 1 codebase met 1 grote database.

Ivo P

04-07-2019 12:08

Er zijn zat van dit soort concepten te vinden. Niet per se in de horeca branch, maar wel technisch vergelijkbaar.

Bijvoorbeeld teamwork.com
Je krijgt daar een url als https://phphulp.teamwork.com/
een beheerder van het account uploadt een logo en kiest wat kleuren, en voila: het lijkt net of het bij je bedrijf hoort.

Ander voorbeeld waar je zeker gratis een account kunt aanmaken: moneybird.
Hier is de interface niet specifiek in jouw huisstijl, maar de facturen en offertes die je hier kunt aanmaken, worden voorzien van jouw logo, jouw kleuren en jouw huisstijl-lettertype.

De lettertypes en kleuren sla je in de database op.
of the fly laat je de css aanmaken via style.php <<< .php he, dus niet .css

-- ja, het gaat ook wel via .css dynamisch, maar dat is stap 2

En de logo's gaan in een map buiten de documentroot.

laten we simpel zeggen dat voor account met id = 123 een logo wordt opgeslagen als ./logos/123

En het logo wordt getoond in de pagina via

<img src="/getlogo.php">

in getlogo.php kijk je (via session, via url subdomein) welk account het om gaat.

Daar zie je dat het om account 123 gaat.
PHP kijkt of 123 bestaat in /logos/
zo ja: dan readfile gebruiken in combinatie met header('Content-Type: image/jpeg')

Geen FTP toegang geven aan je gebruikers.

dan heb je geen enkele controle meer of style.css niet hernoemd wordt naar stylesheet.css of dat er een slim neefje een get_externe_content.php tussen de stylesheets plaatst.

--------

Ik proef een beetje uit je reacties, dat de aandacht vooral uitgaat tot nu toe naar de looks, en dat de techniek gaat met "dat kunnen we later nog wel aanpassen".

Maar de database is naar mijn idee de fundering van je applicatie.
Daarna de backend code en de set up qua locatie van eventuele files
Uiteindelijk moet het er ook nog uitzien.

Hoe verder je bent met bouwen zonder fundament, hoe groter de kans dat je straks een leuk uitziende torenflat hebt, met een fundament voor een garage box.

Ik denk dat je best een leuk concept in handen kunt hebben, maar zorg voor een goede technische basis,

S Stan Avoird

04-07-2019 12:22

Ik proef een beetje uit je reacties, dat de aandacht vooral uitgaat tot nu toe naar de looks, en dat de techniek gaat met "dat kunnen we later nog wel aanpassen".

Maar de database is naar mijn idee de fundering van je applicatie.
Daarna de backend code en de set up qua locatie van eventuele files
Uiteindelijk moet het er ook nog uitzien.

Hoe verder je bent met bouwen zonder fundament, hoe groter de kans dat je straks een leuk uitziende torenflat hebt, met een fundament voor een garage box.

Ik denk dat je best een leuk concept in handen kunt hebben, maar zorg voor een goede technische basis,

Het topic was origineel gestart met de vraag hoe ik het beste de web app kon hosten op een zo efficient mogelijke en scalable manier.
Dat antwoord heb ik inmiddels gevonden in dit topic.

Daarna waren we aan het discussieren over de verdere technische details.

En ik weet niet hoe we er kwamen, maar uiteindelijk ging het over het customizen van de web app voor een specifiek restaurant.
Waarschijnlijk omdat we discussieerde over dat alles 1 codebase en 1 database wordt dus dat er nog meer op dynamisch gebied moet gebeuren om zo elke web app anders te laten werken en lijken terwijl alles op dezelfde codebase en database runt.

Ik ben op dit moment helemaal niet bezig met de customization optie voor de web app.
Op dit moment heeft het een generieke layout die elk restaurant kan gebruiken.
Ik probeerde eigenlijk te zeggen, eerst de techniek en de web app die moet werken en draaien, en daarna kan ik verder gaan kijken naar extra opties zoals het customizen van de web app per restaurant.
Maar dit is een "extra" en voegt qua functionaliteit niks toe.

We zijn een beetje off-topic gegaan. Maar vond het wel leuk om te praten over de vooral dynamische mogelijkheden.

Toch bedankt voor je inzicht en antwoord!
het dynamisch opbouwen van een stylesheet op basis van een php bestand klinkt als een simpele maar effectieve manier om de web app te personaliseren.
De kleuren, logo url, font-size, font-family etc. kunnen gewoon worden opgeslagen in de database . En de style.php kan dan worden opgebouwd op basis van de waardes in de database.

Enige is dan wel weer, dat je elk pageload/pageswitch de waardes uit de database moet ophalen terwijl dit eigenlijk onveranderd blijft. Dus dan zouden we weer moeten gaan denken aan een cache (Redis bijv) of misschien wel alles opslaan in de localstorage, zolang het in de localstorage staat, gebruik de waardes om de stylesheet op te bouwen daar, anders waarde uit de database.
Al brengt dit denk ik wel weer security issues met zich mee, localstorage is volgensmij makkelijk aan te passen als gebruiker en dan kan je weer nare dingen doen met de style.php.

Reageren

Inloggen om te reageren