Let's start familiarizing with the basic concepts in Bobuild.
The builder and the app(s)
The builder is the area, located at https://builder.bobuild.com, where you actually build and modify your app. In the builder you're able to edit the various interfaces using a drag and drop approach, customizing their appearance and creating the various workflows. Additionally, in the builder you can access the raw data of your tables.
The app is the actual application you build with the builder, which is reachable using its own address (for instance, https://mycompany.bobuild.com).
So you'll start from the builder where you'll create your tables, load your initial data and design the various pages of your app. After that is done, you won't usually need to go to the builder much often as your daily work will happen within the app you created. For security reasons, we recommend keeping the credentials of the builder just for you: any other person needing to work with your data will be able to do it through the app pages you create, accessing with the authentication rules you'll decide.
Anatomy of an app
An app is made of two parts: data and pages. Names are pretty self-explanatory and reflect the usual distinction between "database" and "interface". In the data section you define objects and their relationships, while in the pages section you design the various interfaces that users will interact with.
The terms table and object are interchangeable and equivalent in Bobuild: they represent the entities of your data model. Think of them exacly like database tables or sheets of a worksheet. Examples of objects are customer, order, product etc. If you want to handle user authentication in your app, you'll probably need a user or operator object as well.
Of course, an object has multiple fields: for instance, customer will have name, last name, company name and so on.
In order to let users work with your data, you'll need to design one or more pages which will provide the actual interface.
As you can see from the screenshot, pages are nested: suppose in the main page you have a table listing all customers, a button from there will bring you to a child page showing the details of each customer. Also note that you can have multiple top-level pages: this is handy in those cases where you want to expose multiple portals (in the screenshot, one public portal for customers and one private portal for backoffice handling of requests).
Inside a page, you can place one or multiple widgets: think of them like building blocks that provide a specific functionality. For instance, a table, a form or a chart.
All clear? It's time to start with your first app.