Baserow Cloudron app - Airtable alternative
-
@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.
-
@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
-
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.
-
@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!
-
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!
-
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.
-
@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
-
@timconsidine It's available now, just not in the store. Just follow instructions above and you'll be up and running in no time.
-
@doodlemania2 Cheers !
-
This post is deleted!
-
@doodlemania2 Having trouble with this :
Repeat errors likeApp installation error: Installation failed: Unable to pull image tcmbp132021/baserow:1:3:0. Please check the network or if the image needs authentication. statusCode: 400
I can build locally and I can push docker image.
But interestingly docker for desktop reports 3.25Gb locally and repository only 1.1GbDoes the image need authentication ??
Or maybe there is indeed a network error
Grrrr -
And when I run the container locally, it starts and immediately fails
http://ocalhost:3000 doesn't respond and docker for desktop reports not started
I think there is a build problem -
Bizarre
Now working
Maybe there was some network glitch going on
I did dodocker trust
just in case
But had to delete images multiple times and try again
Anyway now deployed to and working on cloudron - yay !
Thank you @bram !!