Possibility of development/staging/production environments.

[fabiankaestner]

Hi folks,

we are currently evaluating different low-code platforms for developing an internal moderation/administration backend for our end-user facing application.
I'm incredibly impressed by your product, and feel like it allows us to build the applications we need. However, we are developing our application using a continuous deployment workflow to development/staging/production kubernetes clusters.
I've noticed you plan on releasing a helm chart, which is exciting.
We have however identified potential issues for our usecase:

• Does the current product support easily switching the database targeted by an application?
  We would love to be able to easily access the same internal tool, only targeting staging/production/... data
  The easiest way I came up with is duplicating the application, and then updating the data source properties. Which, I would think, gets annoying quite easily when developing the internal tool alongside frequent deployments of our end-user facing application.
  Is there a better way to do this I am missing? If not, is this process currently automatable (e.g. by calling an API to export/create a new app when our CI/CD scripts run)?
• Do you have plans to support versioning Budibase apps?
  As our production database schema is still in flux, we would love to be able to keep multiple versions of Budibase apps.

Thank you so much for your work on this product, and for releasing it open-source.

[shogunpurple]

Hello @fabiankaestner - first of all thank you for your positive feedback on budibase. We are really glad that you are enjoying using the product.

To answer your questions:

Our helm chart will be shipped in the coming week or two. Right now we are just making it more generic and providing docs around it so users can get it set up. We are currently using it to stand up our own production environment, and we look forward to community members using it in production settings so that we can improve and tweak it based on their feedback. The type of workflow that you are using in your company, with staged deploys and full automation of several clusters is as good a test as any!

Right now, we do not support switching the data sources based on environments. I do feel this is something that we will support, but it's not on our immediate roadmap due to a lot of other high priority items. Right now the only choice is to duplicate and update the properties, or import/export applications.

There is a similar story with versioning also. The only way to really achieve this right now is to take "checkpoints" by exporting your app and using it as a baseline, importing it into a new app when you want to make changes and test. We do plan to do a lot of work in future around versioning, backup and collaboration so that the team based process is much smoother when using budibase. Again this is not directly on our immediate roadmap, but we are talking a matter of several months, before we get round to building this out.

It would be excellent to chat further about your use case and how you are using budibase, and we can help you be successful in whatever way we can. Hope this answers your questions :)

[fabiankaestner]

Hi, thank you so much for your quick answer! Love to see the culture you seem to have here :)

Great to see you do plan on developing features to support versioning & multiple different data sources.

Since you haven't said, I assume there is currently no exposed API to export/create applications?
As somebody who knows your codebase: How difficult do you think it might be to monkey-patch something with your internal API to support importing/exporting the application in our deployment scripts? Seeing as you are exporting JSON, I think it might not be too hard to build something that covers our usecase.

We are currently mainly comparing your product to appsmith, and they do not seem to have this feature either. So if we were able to get something running, that would be a huge plus for our workflow.

[shogunpurple]

There is no exposed API to import/export, however we do of course have an internal API that drives the frontend.
Export controller: packages/server/src/api/controllers/backup.js
Import controller: packages/server/src/api/controllers/application.js

Since these endpoints are protected for the builder only, it would not be trivial to completely automate this through HTTP calls. We do plan on building a budibase API that allows budibase to be used as only a backend.

You can follow along with this here: #1768

[fabiankaestner]

If anyone else runs into a similar issue before Budibase exposes a public API, I built a small CLI and API abstraction here:

@budibase-version-manager/cli
@budibase-version-manager/api

You can install the CLI using npm i -g @budibase-version-manager/cli.

The tool allows you to authenticate, export and import applications, as well as modify datasource connection parameters before re-importing an application. Feel free to contribute if you have another usecase.

Please note, I built this tool for our internal use, interacts with Budibase using an unsupported API and modifies the JSON export output provided by Budibase.
In summary, use at your own risk, it may break anytime.

On another note, @shogunpurple:
While developing I noticed your session cookies use the name budibase:auth. I initially started writing the CLI in go, and this threw me for a loop, as using colons in cookie names is not technically standards-compliant. As the go http package adheres to the standards strictly, I was unable to interact with the API. I don't know if this is an issue for you, but you may want to consider using standards-compliant names, even though basically all browsers support the current names.
Relevant documents: RFC 6265, RFC 2616, MDN Docs

[Pachat]

@fabiankaestner: installed with npm i -g @budibase-version-manager/cli and trying to run
bbvm login --host=localhost:10000 --user=bb@mydomain.com --pass=xxxxxx (where userr and pass are what work in GUI)
but get HTTPError: Response code 404 (Not Found)
Does bbvm still work with September version?

[fabiankaestner]

@Pachat I'll get back to you when I get around to testing with the most recent version later this week.

[fabiankaestner]

So, apparently the API structure has changed to incorporate multitenancy. I'll get to work on an update as soon as I find some time @Pachat .

[NLKNguyen]

@fabiankaestner is there any update on this? I was thinking about writing a custom tool to modify the data source config in the couchdb for different staging environment, but it seems like your tool covers that. Hopefully it still works.

[fabiankaestner]

Hi, unfortunately I'm pretty busy with my main job currently. I don't know for sure at the moment, but I think the main change was the addition of an instance name or something in the path of the API calls. I'd be happy to accept a PR if you'd like to look into it?

[saaraazGit]

@shogunpurple, Hi there, is there any updates on the versioning?

[indrasantosa]

I'm also here for the multi-environment. Or has anyone found a solution to this? I would like to hear how do you guys solve it

[fgrande]

Get into this thread to see its evolution.

[almereyda]

You can always also click the Subscribe button to the right, if you do not want to raise a notification for your subscription.