Hi HN, I'm looking for resources and advice on building a schema-driven user-interface.<p>I'm building a CRUD project management web app for construction (yes, I'm sure there's existing apps out there, but they're paying me to build a custom one). Currently, I'm using Django with DRF, React with MUI, and generating frontend OpenAPI endpoints using drf-spectacular.<p>When building the frontend, I originally designed it to be generated from the backend database structure because:<p>1) The database might change<p>2) I don't have to hard code the database structure on the frontend<p>For example, the `Employee` entity has properties like `email`, `first_name`, `last_name`, etc. The entity data and metadata (e.g., max character length of `email`) are sent to frontend components which then generates forms to create new employees and a data grid with employee information.<p>The alternative approach I can think of is to hard code each forms' fields and data grid columns on the frontend instead of receiving this information from the backend and then generating the forms and data grid.<p>I'm wondering if building an application with this schema-driven architecture is common? Will this solution be performant if I'm making requests to the backend for this information? I'm finding I'm spending a lot of time updating the metadata API endpoint and making the frontend components generalizable for edge cases.
You are going about this all wrong.<p>The front end should know nothing about the back end and the back end should know nothing about the front end. They are separate systems running independently on separate computers.<p>What you are doing is called tight coupling. <a href="https://cleancommit.io/blog/whats-the-difference-between-tight-and-loose-coupling/" rel="nofollow">https://cleancommit.io/blog/whats-the-difference-between-tig...</a><p>You want the flexibility to do anything you want with your data and simultaneously do anything you want with your front end. That means you can generate any queries you want against any shape of data you want without making any changes to the front end. Likewise, you want the ability to make any changes to the content that is displayed to the user and the ability for the user to interact with that content no matter what is happening with the data.<p>I was laid off from a project with tight coupling, exactly as you envision, last year and it was horrible. Clearly, that tightly coupled project was intentionally designed with tight coupling in mind because the people making those decisions were supremely insecure in their ability to write logic for the front end. They had no idea what they were doing, everything was scary, and just wished the front end logic auto-magically reflected the database world where they found comfort. If that is you then its rough times ahead.