#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2016
    Posts
    22
    Rep Power
    0

    modular system (packages) with dependencies?


    so i am building few site for my company's client. the sites are mostly the same but could have customisations.
    so we decided to create duplicate sites instead of multi-tennant. and we decided to use packaging system so we can install them as required by a site.

    Now my question is if i have a package 1 (events) who also need to display list from package 2 (articles) how should i go about it?
    i can create some sort of a route for news/all.json but then package 1 will KNOW it exists.. Another issue is both events and news have categories which could be same, so with packages i would need a separate table news_categories and event_categories?

    so my idea is a package - will consist of DB Migrations, Tests, Routes (User and Admin)
  2. #2
  3. Headless Moderator
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    16,977
    Rep Power
    9647
    That's quite a vague description, you know. It'll be hard to give useful advice without knowing specifics.

    If you're talking about deployment, go for composer. You can do private codebases with it.

    If you're talking about application architecture, maybe it'll make more sense to think of it as "plugins" instead of "modules". It will be a lot of backend coding to support that. An easier option would be to bundle everything together into the one application, then disable the features you don't want - meaning don't register URL routes, don't register event handlers, don't do whatever.
  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2016
    Posts
    22
    Rep Power
    0
    Originally Posted by requinix
    That's quite a vague description, you know. It'll be hard to give useful advice without knowing specifics.
    ...
    that actually makes sense. we can copy it all and then modify it as we see fit. One problem I see is updating will be a pain.

    imagine you have 4-5 sites. Each site is exact replica with all features in but some disabled. Now i find a bug, i cant just do composer update to get a package update. i have to manually go to each site and then apply fix

    Having said that the packages i was thinking of making were quite small i.e. events (so thats just event table and possibly event_categories)
  6. #4
  7. Headless Moderator
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    16,977
    Rep Power
    9647
    Originally Posted by shez1983
    Now i find a bug, i cant just do composer update to get a package update. i have to manually go to each site and then apply fix
    That problem is addressed by the concept of "continuous integration/deployment".

    Originally Posted by shez1983
    Having said that the packages i was thinking of making were quite small i.e. events (so thats just event table and possibly event_categories)
    The smaller the easier. Especially if you can reduce each package's requirements to one concept, such as tapping into events. A plugin system can be as simple as the base application automatically including every "plugins/*/plugin.php" file it can find.

    Enabling/disabling features can be controlled by the database or a configuration file not bundled with the application itself. That way it won't be affected by new deployments.
  8. #5
  9. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2016
    Posts
    22
    Rep Power
    0
    thanks again @requinix -

    final question i think - what about things like if event has categories which can be same as article categories - i would have tio make 2 tables event_cat and arti_cat
    perhaps i can make a temp table which reads off these two tables and then use that? but then again if one site doesnt have events i would need to tinker this?

    Sorry to go back but since i posted this i have been wondering if it would be better to just go multi-tennent instead. the membership part is the only chunky part apart from that the rest is pretty easy.
    There is just one form on each site which is slightly different but i can use strategy pattern if need be (so create diff models depending on which site & then call them into repository based on which site is being used by the user)

    The only reason I went the multi-instance way was because my CEO kept on saying multi-tennant might get hard if there are customisation between sites but right now the sites are all built and we are just re-writing them and there are no specific customisation and if theres one thing i have learnt in programming its never code for what ifs of the future...
  10. #6
  11. Headless Moderator
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    16,977
    Rep Power
    9647
    If there's any way you can get everyone on the same application, that's best. I've worked with both situations and having one codebase is much better to deal with than coordinating many.

    For the database thing, I don't know. I can't tell what you're talking about in terms of needing multiple tables...

IMN logo majestic logo threadwatch logo seochat tools logo