Multiple front ends

[mjashanks]

Use Cases

A common use case that we see in beta is

• Create an business application that is used internally (budibase bread and butter)
• Expose the same data, via a different (more restricted) interface - to users with logins. e.g. a "Customer Portal"
• Expose some data publically (not authenticated).... e.g. an embedded chart on their website
• Allow some public data input .. e.g. A Form on their website

4 out of the last 10 beta calls have needed one of the last 3 of these options

Current Behaviour

Currently, we have 2 "Pages" (this is just how im naming it for this discussion)

• Public - The page when the user is not logged in... this has no data access
• Private - The page displayed when the user is logged in

Currently, we have a diffulty exposing data publically - due to our multi-tenant app feature (*see below) which is currently unused and, I believe, unecessary.

* Multi tenant apps - Budibase is currently designed so that apps may have multiple, segregated databses attached. Users belong to instances - only when the user logs in do their requests get directed to an instance.

Proposed Change

1. Remove the concept on an "Instance".... every app is linked directly to a single database. Benefits of doing so...

• We can expose data publically
• Simplifies our authentication - users only log into an app, not an app + instance

2. Ability to set a "Public" / "Annonymous" level of access against API (data) endpoints
   E.g. we can say that "Reading from the Metrics View" is available to the public

3. Enable the creation of "Pages"

• a page is given a URL... e.g. /customer-portal or /suvey-form
• a page is given some level of access... e.g. Admin or Customer or Annonymous (public)
• each page is a single page application (as is currently)
• a pages is embedable on another site, via an iframe ... e.g. /survey-form

[joebudi]

Is multi-tenancy possible if we go down this new route? I feel multi-tenancy is a nice USP and one larger orgs will need. But, I do agree, it is not as valuable as your suggestions about.

With your suggestions above, do we remove the concept of a master screen?

[mjashanks]

This almost breaks multi-tenancy - people could still "Duplicate" an app to provide this feature. However - multi-tenancy is only a requirement if you are selling your app as a SaaS product.... i.e. you sell an instance to each of your customers - they have their own data.

This does not remove the concept of a master screen. Each page is still a Single Page Applpication. Each page will still need child urls (screend) - ways to navigate through the app.

However, if you are simply creating a new Page for a "Survey Form", your master screen can be your only screen - with no header etc - i.e. with the simplicity of the current default "Public" (login) screen