Show HN: Lowdefy – Build internal tools with YAML on an open-source framework
lowdefy.com
lowdefy.com
We have developed a simple application schema that is easy to understand, write, remember and of course version control. Yet, flexible enough to create UIs that require advanced logic. This makes it easy to learn how to write applications and easier to maintain consistency from one application to the next.
Lowdefy only provides the application layer and connects to your external data sources or APIs, allowing you to access data where it is stored.
Lowdefy uses webpack module federation as a micro-frontend strategy to load blocks on demand. This enables developers to further extend the functionality by building custom Lowdefy blocks.
Our story:
We have been building Lowdefy since May 2019, and have been using it internally for client software projects since January 2020. We planned to sell it as a SaaS product but decided that an open-source approach is more in line with our ultimate vision for Lowdefy.
Why open-source?
It is important for us that our clients are not locked into a single provider when building a tool.
Building a community and trust is one of our primary objectives, since Lowdefy apps can be shared and open-sourced with ease, we hope to see many open-source Lowdefy apps in the future.
On our roadmap:
We plan to monetize Lowdefy by providing optional, nice-to-have services, that integrate well and empower the community.
Currently we don’t have any authentication or authorization built in, but it is the next feature we are adding. We will be adding OAuth/OpenId Connect authentication, and then you will be able to use services like Auth0 or Okta.
We also plan on providing our own user service, with group based user authorization that will integrate easily with Lowdefy apps.
We decided to limit what we currently market it as to first try and get some traction in a smaller niche for now. However, since resources are limited for an early days startup, we also made this decision based on the following technical considerations.
When designing internal tools, the aesthetics often takes less priority than functionality, thus it's ok and maybe even great if most internal tools look the same, which makes building a great component library a whole lot easier. Also for internal tools you mostly have repeat users, so browser caching helps a lot and thus we can be more lenient on bundle size. When building consumer apps aesthetics and load time is often a high priority, although we have a few ideas to improve on this as well in the future when we have more resources available.
However, if you are building an app where these two constraints is not a high priority, Lowdefy can be a great fit! We really tried to design config schema which can really scale as well.
As far as auth goes, that number 1 on our roadmap. We will be adding OAuth/OpenId Connect authentication, and then you will be able to use services like Auth0, Okta, or any OAuth provider.
We plan on providing our own user service, with group based user authorization that will integrate easily with Lowdefy apps, and offer different pricing tiers to support the needs of business users and SAAS apps.
- All Lowdefy apps use the same structured config schema, which makes it easier to debug large apps or pick up where others left off.
- Nothing is hidden in a GUI. This allows you to do the basics (copy, paste, find, replace, etc.), which makes developing apps more productive.
- Lowdefy app config is simply data, so you can even develop scripts to create and manage your apps.
- YAML files work with your favorite developer, source control, and CI tools.
- Building a GUI to build Lowdefy apps is possible but resource-intensive, so for now, our primary focus is to develop a really powerful and stable application engine.
Consider this definition: ”Data federation is an aspect of data virtualization where the data stored in a heterogeneous set of autonomous data stores are made accessible to data consumers as one integrated data store by using on-demand data integration.”
Since Lowdefy is only the application layer and we connect to any data store, an app can easily for example pull data from two different data bases and merge the data on the client through the _mql operator and display the combined data result in a chart to a user as if it is one.
The same can be said for writing data, for instance single webform writing some parts of the form to various different data stores can easily be built.
It is also quite obvious that a implementation like this does not scale very well for larger data sets, if the federation is done on the client, so a server implementation can really make sense.
I’d be interested to learn more if you have some interesting resources to share?
YAML is a catastrophe. I have spent hours trying to fix a whitespace error in a YAML file that silently changed the meaning of my document.
I'm interested in this but absolutely wouldn't gamble my time on it unless I could do everything with JSON-formatted YAML.
Hope you give it a try!
In particular, 1. You provide UI widgets (generated from your JSON schema, I presume) to generate the YAML and preview the result so the user can start building without having to invest so much time in learning your schema. 2. You represent web components in a structure (YAML/JSON) that is easy to manipulate with code. 3. Your project is open source so others can build on top of it. I'm amazed how almost every no/low-code project I have seen so far has some form of lock-in with expensive monthly rates when you finally want to deploy.
I recently started building something similar and was actually hacking on it past midnight last night only to wake up and see your post on HN (haha). But fortunately I haven't invested too much time in it--I'm going to rethink my hobby project and perhaps work on something that incorporates what you've done.
Bravo!
It would be very interesting to see what your ideas and approaches to the same problem are.
In Retool, to edit many components, I have to click in every one of them which takes so much time. With this approach there would be no problem.
Looking forward to test it out!
Thanks, and we hope you find it useful.
Looking forward to seeing OAuth/OpenID.
Also really excited see devs open sourcing solutions like CRM starter projects etc.
Firstly, we don't have an existing GUI that generates Lowdefy config, but you would be able to build a GUI that does that using Lowdefy. We kind of do that in the documentation, where we give you options to configure a block. So you would be able to write a "form generation app", where users define their forms.
To render the forms it would be possible (but would require a little engineering) to create a React component that renders Lowdefy config, that you could use in your production platform. (This already exists, but currently is connected to the browser router and graphql client in our "renderer" package).
Otherwise you should also be able to run a Lowdefy app in an iframe to render the forms.
Does that make sense?
If you would like to contribute a connection to the project, we would be more than happy helping with that.
On a more unironic note, this definitely looks cool, and YAML (despite its criticism) is a really cool language
We use to write purely is JSON, and when we switched over to YAML we were surprised how much easier it was when writing it day in day out. However, when config is generated programmatically JSON preferred.
For the config schema a operator concepts we took a lot of inspiration from MongoDB’s aggregation framework, and still often jump over to their docs to see what design decisions they made when we plan and build out new features.
Great Work!