I attempted to use this a few months ago to prototype a unified ticketing solution (just an experiment to see if it would be worth adopting for small internal apps) using pre-existing mongo data. Seems super early to use this for anything serious in my view.
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.)
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.)