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

[mark]

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?

[qyloxe]

@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.

[mark]

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

[qyloxe]

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.