Hacker News Reader

Comment by gervwyk | Hacker News Reader

Why build in YAML?

- 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.

View on HN

Are all features available when writing the files in JSON format?

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.

Can completely understand. We support both YAML and JSON. This isn’t documented that well, so we can add a section in the docs on that.

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.

Hope you give it a try!

Couldn’t a code formatter solve your issue?

This is pretty cool, add data federation to this and boom web 3.0

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?

Reply on news.ycombinator.com