How can I conditionally include/exclude pieces of my app?



  • Hi,
    I am working on a quasar app where clients will have varying levels of access depending on their plan. We are deploying an individual instance of the app per client, and I am aiming to only bundle exactly what that client has access to and nothing more.

    Our current solution is to use protected routes so that the client can only view what they have permission to view, however the shortcoming here is that the inaccessible sections of the app (be it files/components/folders) are still in the bundle itself. We would like to have the option to ignore these files/components/folders on build. Is this possible?



  • @mark said in How can I conditionally include/exclude pieces of my app?:

    Our current solution is to use protected routes so that the client can only view what they have permission to view, however the shortcoming here is that the inaccessible sections of the app (be it files/components/folders) are still in the bundle itself. We would like to have the option to ignore these files/components/folders on build. Is this possible?

    I would consider the option of git branches for those clients (hoping there are not too many of them). If this is not feasible with scale, then there are git submodules and clever build options for those files/components/folders. Anyway, git is the first what comes to mind.



  • @qyloxe there will be many clients. Can you speak more on these clever build options?



  • I assume you will have to deal with such categories of files:

    CS- shared code
    CC- common code
    FS- shared configuration
    FC- common configuration
    DS- shared data
    DC- common data

    my hypothetic folder structure (lets assume windows) would look like this:

    /bin
      client01_dev.cmd
      client01_build.cmd
      client01_cicd.cmd
      client02_dev.cmd
      client02_build.cmd
      client02_cicd.cmd
    /conf
      /common
        app.json
        servers.json
      /client01
        secrets.json
        params.json
      /client02
        secrets.json
        params.json
    /data
      /common
      /client01
      /client02
    /dev
      /client01
      /client02
    /dist
      /client01
        /spa
      /client01
        /spa
    /src
      /project01
      /sharedlib01
      /sharedlib02
    

    in /src I would have git clones for main branch of project and every shared submodule. Eventual changes in client forks/clones would be merged/rebased here. This main git repo would keep releases of your app.

    in /dev I would have git branches for every client with shared code as git submodules.

    in /data/common I would keep all common data (files, images, sqlite databases etc.)
    in /data/client[xx] I would keep only specific client data.

    In /conf/common I would keep shared configuration ie app parameters, server data etc.
    In /conf/client[xx] I would keep specific client parameters - smtp passwords, ssh, this client app conf etc.

    In /dist/client[xx] I would keep the result of quasar build and other files copied after distribution command (environment, statics). The files from this folder should go to server or be a source for continuous integration/delivery.

    in /bin I would have build/dev/dist tools for every client:
    client[xx]_dev.cmd
    this tool is for developer. depending on dev model it could take code and data from git, it could properly build configuration/environment data, npm/yarn and of course run “quasar dev -m spa” command in proper client directory.
    client[xx]_build.cmd
    this tool should run a command “quasar build” and the client project will be compiled into proper /dist/client[xx]. then there will be copied there specific client configuration files and data files - and of course - common data and common configuration
    client[xx]_cicd.cmd
    this tool should distribute your app to production in whatever means necessary

    Whats in /dev/client[xx]?
    This is a quasar project, with .gitignored specific .env file, with highly modified quasar.conf.js. In /dev/client[xx]/src there are git submodules with shared code. The modifications to quasar.conf should take parameters from client[xx]_dev.cmd and client[xx]_build.cmd and act accordingly. For example it could take a path to configuration files and prepare this clients .env file or put some data into build.env quasar.conf.js section. It is also possible to use custom webpack configuration here and just copy some common or shared client files during the dist phase.

    Well, thats the gist. The main pain point with this workflow is of course git management, but I doubt that with such specific assumptions of client separation/multi tenancy, any other solution would be less painful.


Log in to reply