title: Excessive use of map[string]interface{} in go development?
body: <p>The majority of my development experience has been from dynamically typed languages like PHP and Javascript.  I've been practicing with Golang for about a month now by re-creating some of my old PHP/Javascript REST APIs in Golang.  I feel like I'm not doing things the Golang way most of the time.  Or more generally, I'm not use to working with strongly typed languages.  I feel like I'm making excessive use of <code>map[string]interface{}</code> and slices of them to box up data as it comes in from http requests or when it gets shipped out as json http output.  So what I'd like to know is if what I'm about to describe goes against the philosophy of golang development?  Or if I'm breaking the principles of developing with strongly typed languages?</p>
  
  <p>Right now, about 90% of the program flow for REST Apis I've rewritten with Golang can be described by these 5 steps.</p>
  
  <p><strong>STEP 1 - Receive Data</strong></p>
  
  <p>I receive http form data from <code>http.Request.ParseForm()</code> as <code>formvals := map[string][]string</code>.  Sometimes I will store serialized JSON objects that need to be unmarshaled like <code>jsonUserInfo := json.Unmarshal(formvals["user_information"][0]) /* gives some complex json object */</code>.</p>
  
  <p><strong>STEP 2 - Validate Data</strong></p>
  
  <p>I do validation on <code>formvals</code> to make sure all the data values are what I expect before using it in SQL queries.  I treat everyting as a string, then use Regex to determine if the string format and business logic is valid (eg. IsEmail, IsNumeric, IsFloat, IsCASLCompliant, IsEligibleForVoting,IsLibraryCardExpired etc...).  I've written my own Regex and custom functions for these types of validations</p>
  
  <p><strong>STEP 3 - Bind Data to SQL Queries</strong></p>
  
  <p>I use golang's <code>database/sql.DB</code> to take my formvals and bind them to my Query and Exec functions like this <code>Query("SELECT * FROM tblUser WHERE user_id = ?, user_birthday &gt; ? ",formvals["user_id"][0], jsonUserInfo["birthday"])</code>.  I never care about the data types I'm supplying as arguments to be bound, so they're all probably strings.  I trust the validation in the step immediately above has determined they are acceptable for SQL use.</p>
  
  <p><strong>STEP 4 - Bind SQL results to <code>[]map[string]interface{}{}</code></strong></p>
  
  <p>I <code>Scan()</code> the results of my queries into a <code>sqlResult := []map[string]interface{}{}</code> because I don't care if the value types are null, strings, float, ints or whatever.  So the schema of an <code>sqlResult</code> might look like:</p>
  
  <pre><code>sqlResult =&gt;
      [0] {
          "user_id":"1"
          "user_name":"Bob Smith"
          "age":"45"
          "weight":"34.22"
      },
      [1] {
          "user_id":"2"
          "user_name":"Jane Do"
          "age":nil
          "weight":"22.22"
      }
  </code></pre>
  
  <p>I wrote my own eager load function so that I can bind more information like so <code>EagerLoad("tblAddress", "JOIN ON tblAddress.user_id",&amp;sqlResult)</code> which then populates <code>sqlResult</code> with more information of the type <code>[]map[string]interface{}{}</code> such that it looks like this:</p>
  
  <pre><code>sqlResult =&gt;
      [0] {
          "user_id":"1"
          "user_name":"Bob Smith"
          "age":"45"
          "weight":"34.22"
          "addresses"=&gt;
              [0] {
                  "type":"home"
                  "address1":"56 Front Street West"
                  "postal":"L3L3L3"
                  "lat":"34.3422242"
                  "lng":"34.5523422"
              }
              [1] {
                  "type":"work"
                  "address1":"5 Kennedy Avenue"
                  "postal":"L3L3L3"
                  "lat":"34.3422242"
                  "lng":"34.5523422"
              }
      },
      [1] {
          "user_id":"2"
          "user_name":"Jane Do"
          "age":nil
          "weight":"22.22"
          "addresses"=&gt;
              [0] {
                  "type":"home"
                  "address1":"56 Front Street West"
                  "postal":"L3L3L3"
                  "lat":"34.3422242"
                  "lng":"34.5523422"
              }
      }
  </code></pre>
  
  <p><strong>STEP 5 - JSON Marshal and send HTTP Response</strong></p>
  
  <p>then I do a <code>http.ResponseWriter.Write(json.Marshal(sqlResult))</code> and output data for my REST API</p>
  
  <p>Recently, I've been revisiting articles with code samples that use structs in places I would have used <code>map[string]interface{}</code>.  For example, I wanted to refactor Step 2 with a more standard approach that other golang developers would use.  So I found this <a href="https://godoc.org/gopkg.in/go-playground/validator.v9" rel="nofollow noreferrer">https://godoc.org/gopkg.in/go-playground/validator.v9</a>, except all it's examples are with structs .  I also noticed that most blogs that talk about <code>database/sql</code> scan their SQL results into typed variables or structs with typed properties, as opposed to my Step 4 which just puts everything into <code>map[string]interface{}</code></p>
  
  <p>Hence, i started writing this question.  I feel the <code>map[string]interface{}</code> is so useful because majority of the time,I don't really care what the data is and it gives me to the freedom in Step 4 to construct any data schema on the fly before I dump it as JSON http response. I do all this with as little code verbosity as possible.  But this means my code is not as ready to leverage Go's validation tools, and it doesn't seem to comply with the golang community's way of doing things.</p>
  
  <p>So my question is, what do other golang developers do with regards to Step 2 and Step 4?  Especially in Step 4...do Golang developers really encourage specifying the schema of the data through structs and strongly typed properties?  Do they also specify structs with strongly typed properties along with every eager loading call they make?  Doesn't that seem like so much more code verbosity?</p>