[PHP] Opzet multisite project

[Proxikill]

Hallo,

Ik ben aan het starten met een nieuw webproject, en had graag jullie advies hiervoor.
Omdat het de bedoeling is dat er meerdere installaties komen van de webapplicatie, allemaal onder eigen beheer. Omdat elke organisatie die een installatie heeft zijn eigen specifieke vereisten heeft, zowel qua layout als voor een deel qua functionaliteit, zoek ik een manier om dit zo efficient mogelijk te realiseren. Daarbij denk ik zowel aan performance als aan onderhoud.

Een eerste idee is natuurlijk elke installatie apart te doen, en eventuele updates elke keer voor alle installaties uit te voeren. Dat heeft als grote voordeel dat elke installatie apart te beheren valt en het op het eerste zicht eenvoudig is voor organisatie X specifieke zaken aan te passen. In het verleden werd zo gewerkt, maar de ervaring leert dat de verschillende installaties op den duur zo versplintert geraken dat je meer aparte applicaties aan het beheren bent en daar veel tijd mee verloren gaat.

Momenteel speel ik met het idee om de applicatie in twee delen te verdelen, een backend die voorziet in alle opslag en verwerking, en per organisatie een installatie die gebruik maakt van deze backend.
Doordat de backend een enkele applicatie is waarvan alle installaties gebruik maken, is het natuurlijk makkelijk om deze te onderhouden. De aparte installaties per organisatie geven dan weer de mogelijkheid om toch nog relatief op maat te blijven werken.
In eerste instantie dacht ik aan een REST backend, maar het probleem dat ik daarbij zie is de efficientie, een hoop curl calls lijkt mij niet de beste manier op dit op te lossen. Het voordeel daarvan is wel dat het niet zo moeilijk zou zijn om op termijn ook een mobiele app te ontwikkelen. Daarnaast blijf ik met het probleem zitten dat in dat geval nog veel van de acties op de backend zouden plaatsvinden. Om een concreet voorbeeld te geven zouden bepaalde organisaties bij een bepaald event een SMS notificatie wensen, terwijl andere bij datzelfde event een notificatie via mail of zelfs geen notificatie willen.
In het ideale geval zou de backend dus bij elke actie een event doorgeven aan de corresponderende installatie, die daar de gewenste acties mee gaat uitvoeren. Om het allemaal wat beheerbaar te houden zou elke installatie dus zo veel mogelijk bestaan uit afgescheiden modules, die ik eenvoudig zou kunnen aan en uitzetten.

Als ik er goed over nadenk, ben ik ook niet helemaal overtuigd van de tweede manier. Uiteindelijk zal veel functionaliteit in de specifieke installaties terecht komen, waardoor er terug richting de huidige situatie gegaan wordt. Ik weet niet of het moeilijk is om functionaliteit in modules onder te brengen, die dan eenvoudig aan en uitgezet kunnen worden? Zaken die door meerdere installaties gedeeld worden zijn zo makkelijk te onderhouden als er geen specifieke aanpassingen aan de modules gedaan worden, en voor specifieke situaties lijkt het me dat deze ook in een module gegoten kunnen worden die dan maar op 1 plaats gebruikt wordt?

Om af te ronden geef ik nog graag mee dat mijn bedoeling is om gebruik te maken van het Laravel framework, maar dat ik wel open sta voor suggesties mocht dit niet de beste keuze lijken. Ik heb niet zo gigantisch veel ervaring met Laravel, maar het lijkt me wel dat dit een heel krachtig framework is. Misschien dat het mogelijk is om de modules waarover ik hierboven sprak in packages te gieten en de applicaties zo op te bouwen?

[dev10]

Ik weet niet of het moeilijk is om functionaliteit in modules onder te brengen, die dan eenvoudig aan en uitgezet kunnen worden?

In het geval van Symfony, ik heb geen enkele ervaring met Laravel, kun je functionaliteit onder brengen in Bundles. Je kunt vervolgens (bijna) ieder gedeelte uit een Bundle overriden.

Als je geneigd bent om richting je eerste idee te gaan, zou ik in Symfony er voor kiezen om echt per functionaliteit alles te gaan opdelen. Je krijgt dan een UserBundle, VerplichteFunctionaliteitEenBundle, VerplichteFunctionaliteitTweeBundle, etc... Ik zou vervolgens een basissysteem gaan opzetten met de functionaliteit die altijd voor komt. De bundles die niet overal standaard voorkomen kun je dan toevoegen als dependency van de applicatie en op het moment dat je iets moet overriden, kun je dat doen zoals in de tweede link die ik hierboven plaatste.

Als je vervolgens voor iedere Bundle een aparte repository aanmaakt, kun je door middel van

code:

composer update

relatief gemakkelijk de bundles updaten. Als je dan in iedere installatie van de app ook de juiste unit-tests inbouwt, is het een kwestie van PHPUnit uitvoeren in de directory van je project en als je groen licht krijgt, deployen.

Nogmaals, ik heb geen enkele ervaring met Laravel, maar ik ga ervanuit dat een dergelijk opzet in Laravel ook mogelijk moet zijn.

[Antrax]

Ik sluit mij volledig aan bij dev10. Geen tot weinig ervaring met Laravel zelf. Ik zelf heb meerdere projecten lopen die samen een basis systeem delen en aan de hand van een domeinnaam en nameserver de juiste maatwerk voor de klant pakt.

Dit is een leuk artikel om te lezen (als je hiermee SaaS bedoeld): Moving to a SaaS model with Symfony2

[Cartman!]

Ik heb vorig jaar een platform opgezet wat in meerdere markten draait en daar hebben we een single code base en dan de configuratie per markt adhv environment-variabelen (MARKET=nl_NL bijv). In t geval voor notificaties dus bijv:

code:

config/nl_NL.yml
notifications:
    - email

##
config/en_US.yml
notifications:
    - email
    - sms

Alle functionaliteit is dus gedeeld maar niet elke markt gebruikt alles. Elke markt draait op zichzelf maar je kan met een deploy-functie elke markt heel snel op dezelfde versie krijgen. Dit platform is gemaakt met Silex overigens maar kun je natuurlijk net zo goed opzetten met Laravel of Symfony. Deze setup is heel fijn in onderhoud en je krijgt geen wildgroei aan varianten en je hoeft niks te doen qua patches als je iets vindt wat in alle platformen zit. Een nadeel is dat je moeilijker "market exceptions" kunt inbouwen, je kunt wel if/else constructies erin zetten maar dat zou ik zoveel mogelijk vermijden.

[Gomez12]

Proxikill schreef op dinsdag 28 juli 2015 @ 14:48:
Een eerste idee is natuurlijk elke installatie apart te doen, en eventuele updates elke keer voor alle installaties uit te voeren. Dat heeft als grote voordeel dat elke installatie apart te beheren valt en het op het eerste zicht eenvoudig is voor organisatie X specifieke zaken aan te passen. In het verleden werd zo gewerkt, maar de ervaring leert dat de verschillende installaties op den duur zo versplintert geraken dat je meer aparte applicaties aan het beheren bent en daar veel tijd mee verloren gaat.

De grootste vraag is : Waarom is het in het verleden zo versplinterd geraakt en hoe ga je dat voorkomen in de toekomst?

Want nu zie ik enkel maar technische oplossingen terwijl het basisprobleem niet technisch is.
Ongeacht welke technische richting je kiest, er is altijd de vrijheid in om te versplinteren (of er is geen mogelijkheid tot maatwerk).

Dus ik zou eerst de vraag beantwoorden hoe je het versplinteren tegengaat aan de mensenkant voordat je naar de technische kant gaat kijken... Anders zit je over 2 jaar weer met dezelfde situatie

[SPee]

Sommige dingen zijn universeel
How to develop highly customizable off-the-shell software

Je kan een meta model maken (niet aan te raden)
Je kan per klant een branch maken (Veel werk herhalen wat mogelijk toch uit elkaar gaat lopen)
Je maakt plugins/modules (mogelijk de beste optie)

Niet alles hoeft via modules; sommige dingen kun je ook enkel met configuratie aanpassen.
(Niet geconfigureerd is niets doen)

Ik zou wel proberen om de sites voor de verschillende klanten zoveel mogelijk gelijk houden. Dus het customizen tot een minimum te beperken. Een voorgaande project had ook verschillende klanten, maar enkel de kleur en tekst was aan te passen. En ander project was er een basis waarop verder gebouwd werd. Ik kan niet zeggen dat dat goede keuzes waren.

[BarôZZa]

De tweede oplossing heeft absoluut de voorkeur.

De eerste oplossing heb ik ook meegemaakt en dat was voor mij reden om een andere baan te zoeken. Het is de makkelijkste/snelste oplossing in het begin, maar op een gegeven moment ben je zoals je zegt meer tijd kwijt aan het onderhoud, het doorvoeren van wijzigingen en het testen ervan op de verschillende installaties. Grote kans dat het na verloop van tijd ook een enorme rommel wordt en nieuwe code voor conflicten gaat zorgen op bepaalde installaties waardoor er weer specifieke fixes voor gemaakt moeten worden. Ik wil overigens niet zeggen dat dit niet goede gestructureerde manier gedaan kan worden, maar bij mijn vorige werkgever was het enorm uit de hand gelopen. Werkt ook demotiverend voor de programmeurs. Je bent simpelweg met nutteloos werk bezig in plaats van jezelf te ontwikkelen.

Bij een REST backend heb je een aantal voordelen:
- Het kan juist efficiënter zijn doordat de backend zich niet bezig hoeft te houden met bijvoorbeeld het parsen van templates. Je kan de backend daardoor op een aparte server draaien of kiezen om meer logica in de frontend te bouwen (ik vermoed dat je daarmee die curls voorkomt waar je het over had)
- Je kan er van alles op aansluiten. Dit kan inderdaad een mobiele app zijn, maar je kan ook denken aan integratie met andere software/web apps die de klanten al gebruiken. De voorkant kan een PHP applicatie zijn, maar ook bijvoorbeeld een aparte Node.JS app, of geheel javascript als het op dezelfde server staat.
- De werking van de backend blijft heel gemakkelijk te testen.
- Het is makkelijk als je met meerdere mensen tegelijk eraan werkt.

Nieuwe functionaliteit inderdaad in nieuwe modules zetten en deze aanzetten bij een klant Je houdt op die manier goed overzicht van wat er nu allemaal in totaal is gebouwd en het is ook handig als je specifieke functionaliteit wil hergebruiken en/of wil ombouwen tot generieke module. Ook altijd goed bedenken of iets klantspecifieke functionaliteit is of generieke functionaliteit met een configuratie. SMS/email en dergelijke lijkt me gewoon generieke functionaliteit die je per klant kan configureren. Bij de betreffende werkgever zag ik nogal eens dat functionaliteit werd gecopypasted bij verschillende installaties en later op verschillende plekken werd aangepast.

Wat betreft Laravel: zelf geen ervaring mee, maar ik las dat het een clean en gemakkelijk te leren framework is, maar dat dat wel ten koste gaat van de snelheid en dat het vooral geschikt is van kleine tot medium grote project. Bij grote/zware applicaties heb je dus kans dat je op een gegeven moment weinig ruimte hebt om te optimaliseren. Geen idee of dit project daaronder valt In ieder geval zou ik als ik jou was gewoon zelf een paar frameworks testen en vergelijken. Dat is de enige manier om erachter te komen welke goed bij jou (hoe snel bouw je er iets in, hoe is de documentatie) en het project (snelheid, functionaliteit) past.

[arnovr]

Het is lastig in te schatten om hoeveel installaties je het hebt, als je er 4000 moet opzetten, vind ik architectuur technisch wat anders dan 50.

Maar rond de 50, kan je zoiets overwegen:

Applicatie en service per klant, waarbij ik er naar zou streven ALLES te proberen via configuratie te kunnen doen. Alle code via bundles / libraries oplossen. Dit zorgt ervoor dat updaten gemakkelijker kan gaan. Probleem kan wel backwards compatibilty op termijn zijn, belangrijk om rekening mee te houden.

In bijvoorbeeld je notificationbundle gooi je bv een event naar een event bus: notification_send, met organisatie data en notification data.

Dan zou ik een notification microservice opzetten voor organisatie X die een sms/email/whatever bundle heeft, die luistert naar de event bus, checkt of hij die organisatie is, en verstuurd notifications.

Op deze manier splits je feature en organisatie, en blijft het potentieel handelbaar.
Mocht de klant graag sms erbij willen, pas je zijn notification microservice aan met sms bundle, wat configuratie en klaar.

En zorg ervoor dat alles via puppet/chef/ansible deploybaar is, scheelt veel tijd!

Voordelen: Potentieel schaalbaar, meeste via configuratie,
Nadelen: Kosten, veel services? latency, veel via backend?

Om echt inschatting te kunnen maken wat een goede optie is voor jou, is het belangrijk om de business doelen te weten, budgetten, en scope van features.