Lowdefy is an open-source (Apache-2.0) low-code framework that lets you build web apps with YAML configuration files.
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.
Hi pchal. We've often been surprised with how flexible Lowdefy is. One can easily build everything from simple websites, public webforms, to complex multi-tenant web apps - which is very exciting.
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.
Hey Thanks for building this - looks really cool! This may be a more basic question but I'm curious how we would lock down the application for internal use alone. Ex. is there any built in authentication / user management?
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.
- 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.
Hi, Yes. you can switch over to JSON as you like. You can write everything in JSON or mix it up if that is useful. Like reference JSON files in your YAML using the _ref operator.
Thanks! Although I'm not familiar with data federation or any web 3.0 spec, I did some light reading and it seems like we are already working in the data federation direction.
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?
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.
Thanks a lot. We were really excited the day we realised we could use Lowdefy to build our own docs, and that we could create a playground where you can see what happens when you change a property.
It would be very interesting to see what your ideas and approaches to the same problem are.
We definitely find a lot of value in being able to make references to pieces of configuration that can then be used throughout the app. Then you can change something in one place, and it is consistent everywhere.
This seems super powerful. Nice to see a new approach in lowering the technical bar for building web apps over flow programming. I'd be really interested to see what culture this creates in technical orgnisations. Allows devs to focus on pure-play stuff and integration teams to really hear what operations team needs.
Thank you!
Exactly what we are currently experiencing with the integration team. Essentially creating more time to focus on understanding and solving the business problem at hand, and spend less time creating the implementation. Which in return frees up engineering to solve more challenging problems.
Also really excited see devs open sourcing solutions like CRM starter projects etc.
Very nice tool. Especially keen on the YAML format and rendering for form purposes. Is it possible to abstract that part out on my own? Does it also come with a GUI editor? I’d like to plug it into our production platform to allow our customers to design their own forms.
Thanks! I'll go through some things that are possible, and hopefully that answers your questions. Please let me know if I missed/misunderstood anything.
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.
This is very useful! I was going through the code and it seems quite simple to add new connections. But I didn't find any documentation around it. Are you not planning on community contributions for connectors anytime soon?
Hi dreamer. Yes, it is quite simple to add new connections, they are logically separated, since we do have plans to add custom connections, much like we have custom blocks, and also to only include the connections used by the app in the server, since bundle size becomes important in serverless applications.
If you would like to contribute a connection to the project, we would be more than happy helping with that.
Haha, thanks! Yes is really simple for even non-devs to pick up in a few minutes and become more productive than being trapped in a GUI. We find it's a nice balance between the freedom you have with coding and schematic structure that is required to make something like this work.
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.
To give a bit more detail, I’m a single founder with way too much on my plate so the promise of this being able to enable me to put a GUI in front of my FastAPI-based application is really great.
We are so excited that people are excited to try our project. This sounds like a great use case. Please let us know how things go, and get in contact if you get stuck.
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.
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.
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.
- 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.
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!
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?
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!