As @brightball said, people seem to be treating this library as a major software architecture statement and criticising it as such (not configured, not enough decoupling, single data source, etc). This is not supposed to be usable for everyone. This is a labor saving device for the common case, and should be treated as such. If one wants to save typing, of course it’s going to be limited, and coupled to the database and all those evil things. But in some cases, that’s exactly what the user wants
Personally I think this is very useful, and I’d like a complete CRUD layer, like Django Admin, or it’s Flask cousins (FlaskAdmin and FlaskAppBuilder), which which I’m most familiar (all python libraries).
To expand a little on this point, in FlaskAdmin once you’ve defined your
Post models (approximately the same as Ecto schemas), you can do this:
from flask_admin.contrib.sqla import ModelView
# Initialize your app
admin = Admin(app, name='...', template_mode='bootstrap3')
And get this for free: http://examples.flask-admin.org/sqla/simple/admin/user/
Yes, it’s extremely coupled to your database. Yes, it’s not very easy to customize. Yes, it supports only a single data source. Yes, it requires an ORM where it’s not easy to predict when the DB is queried (not that much harder than Ecto if you know what you’re doing; if you don’t it might be bad). Yes, you don’t have websockets because Python. Yes, route matching in Flask is very hard to predict (really; the author explains the problem with another framework but all that applies to Flask). Yes black magic happens behind the scenes. But with about THREE lines of code I get a functional admin backend.
Formex is not supposed to help you write Facebook (you should use PHP for that, of course), it’s supposed to help you write FlaskAdmin.