Show HN: Budibase – An open-source low code platform
budibase.com
budibase.com
Budibase is a low code platform for creating CRUD apps, and an open-source alternative to PowerApps, Mendix, and OutSystems.
The Github repo is : https://github.com/Budibase/budibase
And our website is: https://budibase.com
Before Budibase, my cofounder and I worked together, and we were constantly tasked with creating CRUD apps for internal operations - the development process was repetitive, frustrating, and time-consuming. At the time, I looked at low-code options, but there was no standout open-source option.
So, my cofounders and I have spent the last 3 years creating Budibase, an open-source low code platform, to make it faster, easier, and more enjoyable to build CRUD apps [forms, admin panels, approval apps, portals].
We believe low-code platforms should seamlessly integrate with a company's tools and operations. With Budibase, you can create apps using: MySQL, PostgreSQL, Rest API, and more. Or you can start from scratch with Budibase's built-in database (built on Apache CouchDB). Right now, Budibase supports Open ID Connect and Google Auth. It also supports automations using Slack, email, Zapier, Integromat, Webhooks, JavaScipt, and you can run scripts, queries, CRON jobs.
To design your apps, you basically add pre-built components [forms, tables, charts, buttons] to screens, then bind data to those components using Handlebars or JavaScript. Budibase apps work across desktop, tablet, and mobile.
As you create more apps and automate more processes, the reliance on Budibase grows. So, we think it's important that you can 100% own your data and self-host Budibase on your own infrastructure (Docker, Digital Ocean, Kubernetes). Deploy Budibase with our pre-packaged Redis, MinIO, and CouchDB or connect to your own existing Amazon S3 compliant buckets, Redis clusters or CouchDB instances.
Happy to answer any questions. We have a lot more to build and love to hear use cases and feedback.
If you are interested, try it out:
The dependency graph includes a lot of crap, like packages containing trivial single-line functions like "is-object" and "is-stream". That's a very large attack surface considering the poor security practices in the npm ecosystem[0] and the growing frequency of attacks on transitive dependencies[1].
I'm interested in hearing from the creators what steps they take to audit their transitive dependencies in order to prevent this application from being compromised. Given that a tool like this would typically be given privileged access to internal data sources, it seems like a tempting target. I don't think I'd be comfortable using this in production.
[0]: https://www.bleepingcomputer.com/news/security/52-percent-of... [1]: https://news.ycombinator.com/item?id=28962168
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.
Note: Seems like source [0] has a broken link.
Your critique about packages for is-object is valid, though.
What ones did you see that you think can "compromise" this JavaScript application? I'd be curious.
I've never understood introducing this kind of dependencies. Depending on the legal conditions (usually favorable) one can simply extract the code they need from those packages and put it into some consolidated lib on their own.
Did the same for Budibase, and here's some feedback (on just the REST API integration):
1. Please link the (?) icon to the correct place in the docs. eg, if I'm on the REST screen, it makes more sense to send me to https://docs.budibase.com/quickstart-tutorials/crud-app-with..., instead of https://github.com/Budibase/budibase/discussions/
2. Provide html input placeholders in all fields. Understanding whether "Url" field refers to the base URL, or a complete endpoint URL (different platforms treat this differently) is confusing. Even things like whether or not it needs a trailing slash. Having a placeholder with a standard API (such as OpenAPI Pets example) makes it easier.
3. The Jinja template format is great (I don't think any other platform came close to what this simple solution does) - but it isn't documented well enough. The API endpoint creation form should guide me to it as a possibility - without me having to look for it.
4. Really liked the auto-schema detection.
5. The forms really need to be more explanatory. ("Parameters" could refer to HTTP body parameters, or REST API parameters, but it's unclear)
6. Rough edges such as [1] should either be fixed, or automatically be disallowed.
As an aside, I'm curious why the entire nocode industry docs are on GitBooks.
[0]: https://stoplight.captnemo.in/
[1]: https://github.com/Budibase/budibase/discussions/1385#discus...
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!
i can totally see using this but "handholding" would be great.
i tried to get started but a new app from scratch is just not possible for me.
i have a simple question though. can this "self hosted option" work completly offline?
Do check out Appsmith (https://github.com/appsmithorg/appsmith), I work here and we're an open source low code framework for building internal applications. We haven't really thought about the accounting use case, but now that you mention it, it could be super interesting (we've ofcourse had a lot of users building for HR, IT, Sales & Marketing use cases, other than the support).
Btw, on an unrelated note, I'm Kashmiri too :)
this looks like something i can use internally and love. yeah, thanks for this.
oh, great. good to know i have friends here as well. last time i told someone i was on HN and /., their eyes went wide in shock.
edit: yeah, anything is better than proprietary ;-)
Budibase is definitely a product I could see preferring to spend on Enterprise, unless there was a very compelling my team could accomplish "more" with self-hosting. I just ask that if you end up with some sort of per-user/seat fee, that you follow Slack's lead and charge only for activity. This will win my heart over.
Also, custom domain support. Execs love their vanity URLs.
And who doesn't love a vanity URL?!
maybe something like $10/dev plus upcharges for storage and data transfer. but unlimited apps(or at least a generous amount of apps). and an issue escalation charge.
Great to hear some opinions on it :)
We can't wait for the community to use and get value from budibase - in both our cloud and self hosted offerings.
Happy to answer any questions about our tech and our plans for the future!
I've seen this approach used in a lot of different workflow systems over the years, and it's always struck be as awkward. Have you considered designing the automation language in such a way that it is sufficiently expressive to cover the full range of needs for apps, from the high-level aspects to the low-level details?
The approach I prefer to use is to pick a suitably generic language (generally based on a formal process calculus and extended with useful primitives). I'm on my second round of doing this now (first as an academic research project, now in industry) and in both cases it's been based on lambda calculus (and in the industry project, based on Scheme). The language constructs and model of computation are identical whether you're implementing high-level aspects of the workflow logic (a sequence of steps, with optional conditional branches, looping etc) and low-level aspects (iterating through a list of numbers to compute the sum). One language + interpreter takes care of both. I discuss this approach in Chapters 2 and 3 of https://www.pmkelly.net/publications/thesis.pdf.
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.
Had you guys made the decision to create your own grammar/DSL, it's very unlikely that I would be seriously considering using it.
It was interesting to me that you mentioned “functional programming as a model for data-oriented workflow languages”. I find it interesting because we are building Lowdefy [0] with which you can express feature rich apps in yaml / json, and have been considering how to implement DAG type stuff in future versions.
We’ve taken a lot of inspiration from Mongodb aggression query language and as a result built a json / yaml parser which evaluates functions (operators) to implement logic throughout the app. This proved to be extremely flexible, easy to use for data manipulation, and surprisingly performant as we can actually evaluate the expressions during the render loop.
Going to read more parts of your thesis.
I think this is my favorite typo/autocomplete of the year.
An open-source platform is the missing piece to the low-code/no-code landscape - I'm also here to answer any questions!
Would recommend everyone have play with it!
Budibase is meant to be used by IT Professionals (sysadmins, dbas, IT managers, PMs, developers). AppSmith is more targeted at developers. Because of this, Budibase has much less of a reliance on code - we like to say “code optional”.
Also, you will see us talk more about “Business apps”, rather than “Internal Tools”. A Budibase app is a real, single-page application - which you would happily give out to external users and folks in other departments who do not need to know your team’s internal processes. The apps are also responsive by default.
Another differentiator is that Budibase comes packaged with a database (runs on CouchDB). This makes creating new applications easy - without having to spin up another DB. We also offer 1st class support for SQL Databases - Budibase will automatically fetch your tables and automate the basic INSERT, UPDATE, SELECT and DELETE statements (like an ORM).
If you want to place us in the overall low-code landscape, we are more like an open-source Powerapps/Mendix/OutSystems. I sometimes say (half-jokingly) that Budibase is what would happen if Retool and Stacker had an open-source baby.
At Chartmat we also provide internal apps, forms & dashboards (we are at an early stage though). however, we are targeting non-technical users (no-code niche), since we found it hard with our previous low-code iteration to get enough users.
I wish you guys all the best on your way & I'm always happy to exchange experiences. Keep the good work up!
Like MJshanks mentioned, there's some overlap in the usecases but there are significant differences in the platform direction. Budibase is more no-code, while Appsmith is geared towards developers aiming to build complex applications.
Appsmith is a more popular and mature tool with high quality documentation, video tutorials and stellar community support. The GitHub stars, issue list, and size of Discord community reflect this. [0]
1. According to users who've tried both, Appsmith's UX is simpler and enables building information dense UI. Appsmith has drag and drop to build absolute UI vs. relative positioning in Budibase. This does make Budibase apps more mobile responsive than Appsmith ones. Links to comments by other HN users [1] [2]
2. Appsmith is a more powerful platform with a high ceiling and low floor for entry. You can build simple apps quickly by auto-generating them. In Appsmith, you can write full-fledged JavaScript anywhere on the platform. This ensures all your business logic is always expressed correctly. You can map over data, merge data from different data sources, trigger conditional workflows, and conditionally control widget properties all with a few snippets of code.
Few more feature differences:
1. Appsmith has more UI components and support for 100+ charts
2. Built in git sync for version control
3. Real-time commenting and real-time editing(WIP) to enable collaboration between users
4. Appsmith has organizations/workspaces to help freelancers manage multiple projects
5. Error logger and linter to debug issues
Honestly at a more fundamental level, it's just great to see all the different products that have come out over the years that are trying to tackle the same problem space. When we started out initially, we didn't find any open-source alternatives (Budibase wasn't open source then), and so we embarked on building it. And now it's great to see so many different products, which gives users more choice and power over finding the platform that fits their needs best.
[0] https://github.com/appsmithorg/appsmith
We've thought about pricing per MAU. The difficulty is that we would always be charging for last month's usage, rather than more predictable upfront charging. Also - coming up with an exact definition of "active" is not trivial!
Thanks for the feedback!
When using the REST connector, the API keys you hard code, as headers for example, are stored in CouchDB.
We don't currently have rate limiting in the platform, but that's a great suggestion - especially if users can control the intervals.
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.
I really wish someone would come up with a tool like this that isn't targeted at the enterprise, there is definitely a market for it. I could see using this for a host of use cases if user sign-ups were supported.
Btw I love seeing the monthly updates Budibase showcase on your YouTube channel, keep them coming! Makes me excited seeing more and more features added each and every month on top of everything that is already there.
Would it be worth hosting the demos instead of just putting gifs?
As a solo developer, I am creating an app for a customer with the typical JS ecosystem. So, my questions is:
Could an application created with Budibase be put in front of final customers? With authentication/authorization?
If you are building a SaaS platform, then Budibase is not the right platform.
If the form looks good and works, I would put it as a solution for my customers.
Maybe I would not create the whole application with Budibase, but for some screens for entering data + showing tables, yes.
What reasons do you think this is not feasible?
And as a business idea, I think that the first "no code"/"low code" that removes the "only for internal apps" will get the most developers interested. (like me)
There is absolutely no reason why you could not give login's out to your customer - i.e. a customer portal.
It's just difficult to draw this distinction with simple terms, so sometimes we say "Internal" to try and separate from "SaaS Product". Naming is hard - we've been using the term "Business App" more often now.
i gotta ask about the tradeoffs of being open source. It's great for trust and marketing, but if people can self-host Budibase they're always weighing DIY vs paying you. I also work in an open source company and I know product development is often slowed because you have to consider the open ended needs of the open source users vs the constrained assumptions of your cloud.
Any insights or rules of thumb you've developed to think about running an open source business?
Of course, you're exactly right - we now have another ball to juggle; keeping our cloud up and running!
It took us nearly 3 years to open our cloud up, but I'm so glad that we left it this long. Only now do we have the engineering resource to handle open-source/self-host and cloud whilst still keeping the pace of development up.
So, for tips - work on product, product, product. Build your community and give them a great open-source offering. Your community will give back in return - even pure product feedback is gold. Then launch cloud when your direction is solid and you're confident in your product.
How are the applications stored internally? Is it possible to do Git-based versioning with apps?
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.
Our oracle integration will also include automatic schema fetching and query generation, so we can completely automate CRUD operations against your existing oracle database.
Nope it isn't - our website is built with hugo https://gohugo.io/
Our hosting dashboard is built with svelte.
We currently do not have a documented direct REST API - but you can use our webhook feature to ping budibase and trigger actions within the platform.
We do plan to provide a custom API and a fully documented, official HTTP API in the next few months.
TL;DR - It ended up being orders of magnitude faster for me to just build it from scratch.
One of the biggest general UX issues I encountered was how data sources & queries are defined in the UI, and then how they're bound in the WSYWIG editor. It wasn't immediately obvious and the docs are pretty lean. In most cases, I'd just prefer a config file vs doing everything via the UI.
I like the idea and how flexible it aims to be generally, but its in very early stages right now.
(Small aside: There was also a showstopper mongo bug as well that would have prevented me from moving forward with the tool even if I liked it. It was a simple async issue, 11 line diff to fix, but took months to merge.)
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.
Thanks again!
I'll concede that no/low-code solutions have never historically worked out at my organization (context: I am cofounder and director of engineering at a wireless ISP). Theres always a set of tradeoffs that make it really hard to deliver value when you're dealing with business domain constraints that are hard to generalize.
That said, I am always willing to give things a fair shot and have a long list of small use cases that I use for prototyping when I go down that rabbit hole.
It is open source, self hosted and you write your apps in config (yaml / json). So your are not trapped in a UI, you are free to copy paste find and replace and you can version control as you like. Also, we use it extensively with mongo.
Shameless plug. Cofounder of Lowdefy
I mentioned elsewhere in this thread that no/low-code tooling rarely ever works out in my org (mostly because its hard to make a generic framework to encompass what we like to do with internal tooling) — but will absolutely check this out and provide some feedback if I think I have something useful to contribute.
Cheers.
The actual product does not use this format, so it has full safari support and will work as expected.
Is this any better: https://youtu.be/xoljVpty_Kw
The postgres fields are barely visible. I was also looking at the website templates for the score card. The screens get blurry there too. I might use the template ;) https://budibase.com/business-apps/templates/hashicorp-score...