Oplossing hosten meerdere PHP Web apps
Pagina: « vorige 1 2 3 volgende »
We dwalen een beetje af van de originele topic.
Maar ik weet nu wel waar ik allemaal naar moet kijken.
Heel erg bedankt allen!
Mochten jullie nog extra tips of info hebben, ik houd dit topic nog een tijdje in de gaten.
Stan Avoird op 02/07/2019 14:55:32:
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.
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.
Gewoon een kwestie van de juiste accounts en rechten op de FTP.
Mensen met restaurants willen restaurants runnen lijkt mij, niet lopen klooien met FTP :p.
Ik bedoel, je kan via de web app ook emails sturen naar medewerkers en attachments toevoegen.
Deze attachments worden automatisch geupload naar de FTP server naar een specifieke folder, zoals uploads/attachments
Echter als alle restaurants gebruik maken van dezelfde codebase en dezelfde FTP mappen dan moet er wel ergens een scheiding zitten dat het ene restaurant niet bij de uploads/attachments folder kan van andere restaurants.
Hetzelfde geldt voor een logo uploaden en instellen als logo van de web app.
De images moeten dan wel gescheiden ergens geupload worden.
Maar dit is denk gewoon een kwestie van het geuploade bestand een random naam geven die niet te raden is en deze dan in de uploads map op te slaan. Vervolgens de site-index voor die map uitschakelen zodat je alleen via direct access erbij kunt.
Het gaat tenslotte alleenmaar om plaatjes.
Thomas van den Heuvel op 02/07/2019 20:11:35:
Mensen met restaurants willen restaurants runnen lijkt mij, niet lopen klooien met FTP :p.
Maar mensen die de layout willen (laten) beheren, al zijn het externen, misschien wel.
Dus zo een gek idee is het niet eens. Er is immers meer dan een kok en ober ;-)
Je moet dan gewoon de juiste rechten op de FTP hebben, zodat ze niet bij elkaar bestanden komen. En voor persoonlijke zaken zoals facturen, die voorzie je van een random code, of nog beter: Zet ze buiten de webroot, en laat ze eerst de toegang controleren, en dan het bestand ophalen.
Gewijzigd op 02/07/2019 20:45:00 door - Ariën -
Uiteindelijk is de bedoeling dat niemand FTP access krijgt. Hooguit misschien dan voor een upload/ folder of images/ folder.
Thomas van den Heuvel op 02/07/2019 22:58:02:
Mja, of je geeft gebruikers een gebruiksvriendelijke interface in de form van een media(beheer)systeem zodat je alles via het beheerpaneel van een website kan regelen in plaats van dat ze daarvoor een apart programma moeten installeren en leren gebruiken.
Programmeurs doen niet anders, als ze templates zouden maken voor een klant die een bepaald gehost CMS-systeem gebruikt. Enige wat ze nodig hebben is een documentatie met mogelijkheden. Op deze manier werkt/werkte BiedMeer ook. Een simpele interface voor de wat minder geleerden is wel handig voor logo's bijv.
Maar goed, ik weet niet of er sprake is van templates en de mogelijkheid van een hele site erbij.
Gewijzigd op 02/07/2019 23:26:02 door - Ariën -
Is maar even een voorbeeld, maar je snapt ongetwijfeld wat ik bedoel ;)
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
Quote:
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.
Quote:
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.Restaurants toegang geven tot hun eigen specifieke FTP map waarin ze CSS sheets kunnen uploaden
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.
Het ligt er net aan hoever je wilt gaan.
Gewijzigd op 03/07/2019 15:23:29 door - Ariën -
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.
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
Gewijzigd op 04/07/2019 10:18:04 door - Ariën -
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 ...)
Quote:
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
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.
Quote:
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 ...)
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.
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,
Quote:
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,
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.
Pagina: « vorige 1 2 3 volgende »