Baserow Cloudron app - Airtable alternative

[bram]

Hello everyone,

My name is Bram Wiepjes and I am the founder of Baserow (https://baserow.io) which is an open source no-code database tool and Airtable alternative.

First of all I wanted to tell that Cloudron is an amazing platform! This is the first time that I worked with it, but it is just great! The ease of use, stability, addons and low learning curve make it a fantastic product and I have become a fan.

As a fun weekend side-project I decided to make a Baserow Cloudron app. My initial version can be found here https://gitlab.com/bramw/baserow/-/merge_requests/154 and I would love for people to test it out and review the code. All feedback is welcome and would be much appreciated.

Even though this version works, tested it on Cloudron 6.1.2, there are a couple of issues that I ran into. Baserow depends on Redis version 5 because it uses Django Channels 3. The Cloudron documentation mentioned that the Redis addon installs version 5, but it was always version 4 for me. I solved this by installing Redis 5 locally in the Docker image which is fine for now because the state doesn't necessarily needs to be persistent.

Baserow exists of a backend and web-frontend which communicates only via a REST API and Web Socket with each other. Is there a possibility to to split the backend and web-frontend into two different images? Right now I've combined them into one image. If that is not possible, is it possible to do two health checks? One for the backend and one for the web-frontend?

Lastly, it would be great to get listed in the App Store once this version is stable.

Best,
Bram

[mehdi]

@bram nice to see some app developers porting their own apps to cloudron

@bram said in Baserow Cloudron app - Airtable alternative:

The Cloudron documentation mentioned that the Redis addon installs version 5, but it was always version 4 for me. I solved this by installing Redis 5 locally in the Docker image which is fine for now because the state doesn't necessarily needs to be persistent.

I'm not sure, I have never written a Cloudron app that needed to use Redis. I'll let the Cloudron devs answer you on this one.
Installing redis locally in the meantime is a good work-around for the moment.

@bram said in Baserow Cloudron app - Airtable alternative:

Is there a possibility to to split the backend and web-frontend into two different images? Right now I've combined them into one image

Nope, no way to do that on Cloudron. Sorry, you indeed have to package them together, and start both with something like supervisor, which should already be available in the base image.

@bram said in Baserow Cloudron app - Airtable alternative:

If that is not possible, is it possible to do two health checks? One for the backend and one for the web-frontend?

Not at the moment, but I think the devs were talking about ditching the current http request way of doing health-checks, in favor of using the native HEALTHCHECK dockerfile instruction (https://docs.docker.com/engine/reference/builder/#healthcheck). Not sure if work has started on this yet.

[plusone-nick]

@bram welcome and glad to have you! @girish & @nebulon are amazing! Looking forward to this collab, also you should check out https://www.budibase.com/ no-code app builder. They recently implemented Airtable support - Baserow would be good there too +1

[doodlemania2]

this is huge! welcome @bram - big fan of your app!!!!

[nebulon]

Hi @bram and welcome to our forum!

This is indeed great news and awesome how much progress you already made for the packaging.

I will give it a try later today and hopefully we can get this into the app library soon

Regarding redis version, I can confirm that the addon has version 4.9.0 installed, however we are currently preparing a new base image for apps and addons, which is based on Ubuntu 20.04 and then redis is updated. I see that @girish just already updated the docs

For healthcheck one option is to add a small daemon which provides for example a /healthcheck route and internally then pings the corresponding services for health. That way the app package only has one route but that one will indicate if all components are healthy.

I hope I can give more feedback once I've tested it. Just a heads up, we also require selenium tests for all app packages, but we are happy to provide them for Baserow then.

[marcusquinn]

@bram Great stuff - looking forward to giving it a good test and helping with feedback.

Personal opinion but maybe shared. Something I've found, and I think others do too, is making open-source a sustainable business, and for users, avoiding gotchyas, lock-ins or usage taxes.

The business models I've found the happiest are with EspoCRM and Freescout.

Essentially, the FOSS is unlimited in usage, and the Premium is too.

Premium revenue coming from selling extra setup "Packs" that are typically only needed by businesses, and also effectively fast-track best-practice template setups.

So FOSS users get the full benefit of the framework to use, test,, feedback on and help evolve.

And those using the app to save or make time or money will happily pay for the premium packs as they get them setup with templates that would otherwise take a longer time to recreate.

I understand per-user licensing for vendor-managed SaaS because users numbers tend to correlate to support requests or expectations.

However, for self-hosted, I hope to encourage you to consider unlimited users and, instead look to premium packs, templates, setups, perhaps with an annual license.

So you have good and repeat income but businesses that have low margins and high user count needs aren't looking at prohibitive scaling costs because if they are self-hosting, they also tend to be self-supporting for 1st-line requests. Consider it support work-sharing

Keep up the great work, I love anything that encourages understanding database design and record-keeping and communications best-practice. I'm sure the world will thank and reward you for your innovation!

[bram]

Thanks everyone for the warm welcome and for the info.

For now it is okay if Redis doesn't keep the persistent state, so we can use the one that is installed within the Basero app image. Would be nice to use the Cloudron addon in the future once Redis 5 is fully supported. Once the Docker healthcheck is supported we can use that.

Looking forward to your feedback!

[bram]

I have a quick follow up question. Is it possible for Cloudron to generate a unique secret key and provide that as environment variable? Baserow depends on a secret key to create password reset and invite tokens, but this needs to be unique value for each installation. Otherwise if everyone uses the same key, it will become possible to create password reset tokens which is a security issue.

[nebulon]

@bram similar to cookie secrets, this usually is done in the startup script (start.sh).

Something on the lines of (just some pseudo bash here):

if [[ ! -f /app/data/.secret ]]; then
    echo "SECRET_ENV=$(some way to generate a secret)" > /app/data/.secret
fi

source /app/data/.secret

Very much depends on how the app consumes this. Sometime like gitlab they have a secrets file like: https://git.cloudron.io/cloudron/gitlab-app/-/blob/master/start.sh#L92

[mehdi]

@bram an example here : https://git.cloudron.io/mehdi/river/-/blob/master/start.sh#L64

if [ ! -f /app/data/session.secret ]; then
  dd if=/dev/urandom bs=256 count=1 | base64 > /app/data/session.secret
fi

[bram]

This will work for my use case. Thanks!

[ianhyzy]

This looks like a fantastic tool, can't wait to try it out on Cloudron!