
Can you scaffold an entire Application just by writing GraphQL Queries? - jensneuse
I&#x27;ve developed a new concept where we take Persisted Queries one step further.<p>Based on the Queries we might be able to scaffold UI components or event an entire Application.<p>Unfortunately I cannot post a codebox on HN so you have to click the link below for an example, I&#x27;m sorry!<p>There are a few questions I&#x27;d like to ask the community around this concept. We&#x27;re mixing a lot of things together here. Data Fetching, Authorization and UI components, all in one view. Is this really something we should pursue? I see potential use cases for low code scenarios when you want to build Admin Dashboards but beyond that. I&#x27;m still not sure if this is a good idea. Would be great to hear your thoughts. If you want to get a bit more details on the idea here&#x27;s a link to the full concept.<p>https:&#x2F;&#x2F;wundergraph.com&#x2F;blog&#x2F;2020&#x2F;09&#x2F;06&#x2F;scaffolding_react_app_with_graphql
======
mattmanser
I've not even touched graphql, but based on the 101 versions and variations of
the same concept before it, theoretically, yes, practically, hell no.

I've seen it done with SOAP queries, XML schemas, strict REST interfaces,
OData APIs, etc., etc.

It just doesn't, ever, work. You'll end up making the code crazy convoluted
jumping through tons of hoops to get it to work with the invariable plethora
of edge case, or worse, you'll leave a ton of easily exploitable security
holes. No new programmer joining your team will have a clue how it works,
people will come up with different 'fixes' to get around the limitations
meaning there's 101 ways to do things, badly, and ultimately you'll regret it.

Maybe I'm being an old cynic, but it seems to always turn into a nightmare,
the flexibility of a simple HTTP POST seems much better than these inflexible
and often impenetrable query languages.

They're great for hooking up to datatables though.

