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.
First of all, here are the development fundamentals our devs follow in work prepared by our founder Bram:
Listvuejs component that can be used to create list like this one:
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.
make sortcommand in the Makefile, so to stop worry about import order and minimize merge conflicts.
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.comcompany could use Okta for example, while
contoso.comcould 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
flake8plugin 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.
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.
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.
If you know someone who may be a great fit for us, make a recommendation!
💬 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 more of 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 thread on the community forum.
Today we are releasing Baserow 1.15 with personal views, today() and now() formula functions, timezone support, and much more.
Want to write a post in collaboration with us?How to contribute?