ROLL THE CLOUD INC. dedicated github repo possible child org - explore
Custom
github
Your own github account
gitlab
aws code commit
hosted git server
Deployment:
Hosted
Shared hosting on roll the cloud infrastructure in aws
Custom ( host static site on own infrastructure )
s3 + cloudfront
cloudfront required for https
github
routes that don't exist as physical pages for prerender 404 - no fallback route like with cloudfront
google
netify
azure
gitlab
Download
Download files as zip either send by email or place in a drop box if to large. Something.
Architecture
Roles:
Overlord
Administrator
Developer
Site Builder
Designer
Customer
Hierarchy:
Organization 1
site 1
Resources
repo
code commit
github
gitlab
s3
build files
cloudfront
distribution
Entities
Panel Page (internal or hosted entity)
panel page A
panel page B
panel page C
Ad (custom entity)
site 2
Entities
Panel Page
panel page A
panel page B
site 3
Entities
Panel Page
panel page A
Organization 2
site 1
site 2
Organization 3
site 1
Scratchpad
I think cassandra could work fairly well for managing organization and site info. Including resource permissions since these will be tied to sites and organizations. The check can be done in lambdas prior to accessing s3 assets. I have never liked the idea of storing permission info to s3 resources like panel pages on the s3 object itself. I think it makes much more sense to store permissions separately.
Panel pages currently belong to sites through the site property. Users will belong to sites. At the base level any user that belongs to a site can modify the resource to start. Customers that sign up for a site don't belong to any particular site since they can transition between all sites in the ecosystem.
Users can only create panel pages for sites which they are allowed. Users can only modify panel pages for which they are granted write access. This model is already somewhat setup using entityPermissions.
So the question becomes how do users get assigned to sites. The other part is the more granular permissions and organization hierarchy.
A site is defined as a independent build hosted in a dedicated s3 app bucket with cloudfront distribution. The original name of organization was profile back when the only part of this was creating separate ad websites for different real estate agents or dealers. Now this becomes more generic at the company level thus organization instead of just profile.
User can belong to multiple organizations and have different permissions per organization.
You sign up. Once you sign up create an org. Creators of orgs are root users. They can do anything. All other users must have explicit permissions to org resources.
To make life easier there will also be roles which are basically templates for assigning permissions to users.
Creativity could be exercised here using druid terminology such as ; "circle".
Leaning more toward github actions for both druid core and druids instead of using aws code build.
Configuration
Repo
Deployment:
Architecture
Roles:
Hierarchy:
Scratchpad
I think cassandra could work fairly well for managing organization and site info. Including resource permissions since these will be tied to sites and organizations. The check can be done in lambdas prior to accessing s3 assets. I have never liked the idea of storing permission info to s3 resources like panel pages on the s3 object itself. I think it makes much more sense to store permissions separately.
Panel pages currently belong to sites through the site property. Users will belong to sites. At the base level any user that belongs to a site can modify the resource to start. Customers that sign up for a site don't belong to any particular site since they can transition between all sites in the ecosystem.
Users can only create panel pages for sites which they are allowed. Users can only modify panel pages for which they are granted write access. This model is already somewhat setup using entityPermissions.
So the question becomes how do users get assigned to sites. The other part is the more granular permissions and organization hierarchy.
A site is defined as a independent build hosted in a dedicated s3 app bucket with cloudfront distribution. The original name of organization was profile back when the only part of this was creating separate ad websites for different real estate agents or dealers. Now this becomes more generic at the company level thus organization instead of just profile.
User can belong to multiple organizations and have different permissions per organization.
You sign up. Once you sign up create an org. Creators of orgs are root users. They can do anything. All other users must have explicit permissions to org resources.
To make life easier there will also be roles which are basically templates for assigning permissions to users.
Creativity could be exercised here using druid terminology such as ; "circle".
Leaning more toward github actions for both druid core and druids instead of using aws code build.