Budibase cofounder here - we are super excited to finally ship the dev experience of 2.0 and can't wait to see what the community build with the new dev experience. Happy to answer any questions or hear any feedback that anyone may have!
As I mentioned in the post, this was a truly special moment for the team here at budibase. Open source can have its challenges, but moments like this make it so worthwhile. I'm more than happy to answer any questions anyone has.
Automations are simple by design - the general automation steps are kept simple so they are easy to configure and create. We do however have a JS and a bash automation block. These blocks let you perform looping, iteration and logic using either JavaScript or bash.
The reason we use JavaScript is simple. Most software engineers can write or at least express simple constructs in JavaScript. Being a C family language, this makes it easy to pick up for engineers who have been exposed to other languages like Java, for example.
The problems you are describing are actually something that we have felt before, when budibase did not have JS support, we had users reporting that the templating/handlebars syntax was not good for logic, and was new to them. It was esoteric and required in depth knowledge for advanced use cases.
Using an off-the-shelf high level or more specific expressive language has some serious drawbacks, especially if you create it yourself. The first is education - writing extensive docs around how to write and use that language. The next is maintenance - maintaining your own custom PEG grammar or programming language is a huge project in itself, not even including the research required to execute it well.
By using JavaScript, we can leverage the already existing plumbing for executing JavaScript, and provide something that has much for familiarity to the general user.
Our app metadata is stored as JSON documents in CouchDB, but entire apps can be exported to .txt files that can be imported into budibase also. Our templates work through this method.
We do not currently support git based versioning, although it's certainly something we could support in future, given the fact an entire app can be represented in a .txt file.
Thanks for the comment. We have just undergone a full security audit as of 2 weeks ago - any infrastructure or code vulnerabilities are currently being worked on.
Many JavaScript projects contain huge dependency trees - it is unfortunately the nature of a 3rd party module-heavy ecosystem, and can be hard to tame the sheer size of the tree. We will update or pin dependencies as needed, to solve the security issues being reported by NPM.
I should also mention that since budibase is self-hostable, it can be run inside all of your existing infrastructure and network - providing additional layers of security that you can control.
Appreciate the feedback, and the information regarding transitive dependencies - interesting article.
Hi, thanks for the feedback, sorry to hear you had some problems.
The Mongo connector in general could probably do with some love - there's a few features in mongo such as projections that budibase does not support. We'd love to know more about what you were trying to build and how we could help you achieve it.
We move quickly, however, and the platform has come a long way in even a few months. We hope you try the platform again soon and continue to provide feedback as to where it could be improved.
Docs are a big focus for us over the coming months and they will see significant improvement in short order.
We are actually currently planning work to greatly improve the experience of the REST API integration (including better docs) - due to it being such a fundamental part of building any software.
1) Good catch, we will fix that right away.
2) Great suggestion, this will definitely help guide the user.
3) Very valid - there will be a more wizard based experience for the REST connector soon. It's quite manual at the moment. Appreciate that you liked the handlebars templating experience!
4) This is a big feature for budibase - we try and auto generate as much as we can, to make the dev experience faster.
5) More docs and guidance around this is on the way with our "blocks" feature, which should make building forms a much more pleasant experience.
6) as above.
Gitbooks is a pretty nice platform - it takes a lot of the effort out of creating/designing docs and they recently updated their editor, so we are very happy with it!
We are currently in the process of shipping an oracle integration and it will be available in our release next week!
Our oracle integration will also include automatic schema fetching and query generation, so we can completely automate CRUD operations against your existing oracle database.
Thanks - we have been working hard on making UX a priority for budibase and glad to see that it's paid off!
We plan on introducing a self-hostable metrics stack built on exactly the technologies you mentioned in the next few months. Grafana, Loki, Prometheus and more.
This should give users total insight into what's going on in their budibase installations and allow them control over their budibase infrastructure.
Thanks, really glad to hear that! If you do ever end up trying the platform, don't hesistate to reach out and ask questions on our github discussions forum.
This is fantastic feedback, thank you very much for taking the time to write this up.
We totally agree with the points you have raised - in fact we are in the process of addressing the component deletion problem; providing the ability for users to delete components with the keyboard or use an action bar that will be shown in the preview.
As for mapping data - this is something that is requested a lot and as such is high priority. We will be working on this in the coming weeks, providing full JS support and transformation logic for any source of data that you fetch from your Budibase applications.
Great to hear you had a good experience using Budibase self hosted. We are constantly trying to make the Budibase setup process easier, both through our self hosting setup CLI and through standard deployment configurations that developers are used to - such as docker compose and helm charts for kubernetes. Which method did you use?
Please do continue to follow Budibase - We are confident that you will love the features we planned on our roadmap for the next few months!