I am currently writing a quiz web-app with a React front-end and a Golang backend, with a PostgreSQL database to keep track of the quizzes, the questions on the quizzes, and the choices in the questions.
My approach currently involves having Quiz, Question, and Choice structs, where I've abstracted the SQL away into functions such as GetQuizzes() (which just does a SELECT * FROM quiz), (q *Quiz) AddQuestion(/*question data*/), and other things that would help common actions on my website.
On the frontend, I will most likely not be needing every field from a table each time I display data related to that table, and while I could pare down the structs in my handlers, only sending the data needed for that view, it seems wasteful to be grabbing every field when I GetQuizByID or what have you. I know I could write the SQL directly in my handlers, which would allow me to have complete control over my data where I could even do things like JOIN (which does not make any sense in my current architecture, which seems like a bad sign). However, this would abandon the whole MVC pattern that I am trying to practice/think about.
My quetion is whether I should continue with this and just take my lumps grabbing every field and having little control over what I load and what I don't, versus abandoning this model layer and just using SQL wherever I please. Obviously, this app isn't super reliant on having state-of-the-art performance, but my goal is to use my knowledge here to apply to more real circumstances that I might run into later on in my career.
Disclaimer: I am pretty new to this web-programming stuff (especially backend), so let me know if I'm totally off base and need to hit the books again.
