Skip to main content

Configurating your project

Commonly frameworks start with models, controllers, guards, and leave other challenges to the developer to make a choice. Fireback comes with many default things in mind, to let the project go live, with least possible configuration or technical decisions.

These configuration are necessary either using Fireback as user management or developing your backend with it in go. Simply Fireback could be installed as a product and you could develop your own backend on other languages, and you need to do some configuration for it to work properly.

Yet, for all these features which are available in workspaces module, you need to make some decisions how you want to run your project.

These topics are:

  • Run the migrations, and inserting capabilities
  • Configurate the admin users
  • Write email templates, setup the email providers, email senders and more.
  • Configurate the passport methods (allowing email, phone numbers or other).
  • Setting Workspace Types (For example in a shop, customers, sellers, or other type of users)
  • Adding capabilities (permissions) for custom built services.

Running migration​

Capabilities are a common method of controlling access level across the applications, and User, Role, Workspace and Permissions model of Fireback allows to create such scenarios for simple and complicated products.

Migrations need to be run as well to keep the database elements in sync. Fireback automatically adds every entitiy into fireback migration apply command, and also you could write custom migrations and add them to module via ProvideEntityHandlers function:

module.ProvideEntityHandlers(func(dbref *gorm.DB) error {
   // implement as many as migrations you want, and access dbref
   // as gorm database connection
})

Syncing capabilities​

You can synchronize the the capabilities via fireback migration capabilities alone. running migration apply command will refresh the capabilities after running database migrations.

Workspace Types​

Workspace types are very interesting solution based on the capabilities. They limit a certain type of users to only have specific features of the application available to them.

This could be selected before user joins the product. Imagine a learning platform, which "Students" and "Teachers" need a complete different panel and features. Using workspace types, you can still develop the same application but provide the features selectively to students and teachers.

Workspace types also could be used to develop different packages for product, like paid and unpaid, and by assiging a specific role to that type, you enable or disable a set of features.

Define teacher and student workspace types​

Before you can any workspace type, you need to create their roles. A role, is a title, and array of capabilities.

Because we did not develop the student and teacher entities or actions, we go and add manullay two capabilities for testing purposes:

./app cap c --uid "root.teacher.*" --name "Teacher capabilities"

And student as well:

./app cap c --uid "root.student.*" --name "Student capabilities"

Then we go create such roles for both of them. Each role can have 1 or more capabilities together.

ali@alis-MacBook-Pro fireback % ./app role c --name "Student Role"                              
Select Capabilities:
Use arrows to navigate, CTRL+Space toggle selection, and Enter to close, or type in for search
Keyword: stud

> [ ] root.student.*

You can select them with CTRL+Space, and then select enter. The same for teacher:

ali@alis-MacBook-Pro fireback % ./app role c --name "Teacher Role"
Select Capabilities:
Use arrows to navigate, CTRL+Space toggle selection, and Enter to close, or type in for search
Keyword: teacher

> [x] root.teacher.*

Now we have the necessary roles. We can create workspace types for them. Please remeber when we created the roles, we are passing the uniqueId as role-id in following commands, and teacher and student are having different uniqueId generated for them:

ali@alis-MacBook-Pro fireback % ./app ws type c --title "Student Workspace" --role-id OhdetYve1BQnlCHucA3Dn --slug student 
workspaceId: root
isDeletable: true
isUpdatable: true
userId: 2jOzry2q61HC0L3qrjZrd
rank: 0
id: 4
uniqueId: KW5Jnvh2ggt_cVFjPybGV

Similarly, for teacher:

ali@alis-MacBook-Pro fireback % ./app ws type c --title "Teacher Workspace" --role-id OCwiGiRe4tzOGjOjfeo6G --slug teacher

After this, you'll see that these workspaces are available upoin signin method:

ali@alis-MacBook-Pro fireback % ./app ws workspace-types
- workspaceId: system
  isDeletable: true

Obviosly it would be accessible on http server as well.