Baserow for Developers: January Developer Digest

Baserow for developers is a digest that equips you with the most important product updates and developer news. In the first edition, learn about Baserow’s engineering culture, new technical features, and our latest developer job opportunities.

New technical features and updates

Frontend/Backend

Added a new the List vuejs component that can be used to create list like this one:
Added a new DataType instance, MemberDataType, which allows plugins to inject data into member responses. You can customize the member response content and show more information in the member tables this way.
Added a simple way to check permissions for plugins. You can use the Baserow permission system to check permissions in your plugins too. Here’s an example for the backend check.

CoreHandler().check_permissions(
        user, # The user who is doing the action.
        "operation_name", # Must be the name of a registered operation.
        group=group, # The group in which the operation takes place.
        context=context_object, # An optional object to give the context of the operation.
)

This instruction will return True if the operation is allowed by all registered permission managers and raise a PermissionDenied exception if not. More comprehensive doc is coming.

Added a new permission manager registry to allow devs to register their own way to hook on the permission checking feature. You can define your own rules when validating the user action. For instance you can define a permission manager that allow a user to have all the permissions on a table if he has created it.

Dev experience

Added isort and the make sort command in the Makefile, so to stop worry about import order and minimize merge conflicts.
Added the vscode configuration, so new devs using vscode as editor can start from setup their env pretty quickly.

Get inspired by these discoveries

How Single Sign On works and how we developed it.

Single Sign On is a critical feature for medium/big enterprises in order to have a central identity authority where admins can decide who may use which software.

To allow different users, we had to develop our integration with some well known Single Sign On services.

We started with Okta and OneLogin as supported providers, since they have a very dev-friendly environment with great documentation and the possibility to quickly create custom connectors to test out our code with some real use-case scenario.

We also had to develop our custom code since most of the Django libraries out there start with the assumption that an application just have the need for one external IdP (Identity Provider), while we want admins to create different integrations based on the domain instead, so that the acme.com company could use Okta for example, while contoso.com could use a different IdP hosted on OneLogin.
It has been very interesting to try and study most of the open source libraries out there, dive deep on what we really need and architect one of the simplest implementations we could actually build to fit our needs.

How to implement a flake8 plugin to check for custom rules.

In Baserow, we have a convention to leave an empty line after the python docstring and before the code.
Unfortunately enough, there was no way to enforce our style-guide-enforcement tool (flake8) to check for this custom rule out of the box, so it was quite easy to forget both for the developer and the reviewer, adding a low-value checkpoint to remember and check every time.

Creating a new flake8 plugin was fun and it turns out to be a good time-saver too, since now we can completely forget about that convention because both our preferred IDE and the pre-commit check will immediately show the error about our conventions.

📌 Interesting to know! Use registries to extend and introduce new functionality, either directly in the codebase or via plugins. Baserow has many registries, you can for example add a new field type via baserow.contrib.database.fields.registries.field_type_registry. More information can be found in the developer documentation here: https://baserow.io/docs/plugins%2Ffield-type. You’ll also find more examples on how to add custom view types, filters and more. Baserow has 19 registries in total.

How to handle Context Switching? Interview with the Baserow dev, Alex.

What was the biggest challenge while working on RBAC?

RBAC in general is a super complicated topic where we often ended up with long formed discussion about difficult topics. There was also a lot of co-dependency since we were 4 devs working on the same feature. Because of that, it was hard at times to understand where everyone is at and what everyone's understanding is going forward (it could have been much worse though).

How you managed to deal with context changing?

Keeping notes on the MRs or in a local file to remind yourself where you were at with a certain topic.

What tips would you give on how to avoid the negative effects of context switching?

Ideally, you should avoid context switching all together since it does overwhelm you and make you less productive. But if it is unavoidable then it’s best to accept that you will lose some time because of it, and that is okay. Notes and schedules can also help.

Useful links to check

Developer job opportunities

DevOps Engineer: https://baserow.io/jobs/devops-engineer.
Senior Full Stack Developer: https://baserow.io/jobs/experienced-full-stack-developer.
Front-end Developer: https://baserow.io/jobs/front-end-developer.

Stay connected

💬 Follow us at @baserow on Twitter for staying in the known of all company updates and news.
⌨️ Join the Baserow community forum to chat with other developers and the Baserow team.
⭐️ Star Baserow on GitLab to show your appreciation of our work.

What would you like to see in the next digest edition? Do you have any insights, struggles, and/or useful links you want to share with the rest of the community? Let us know by responding to this post.

Blog