Some questions on building a webservice from a noob

<p>I&#39;m fairly new to GO and have convinced the company I work for to look at replacing some of our old services written with Ruby on Rails with much nicer GO services. I really enjoy the language so far but really want to try and do this as well as possible to set the foundation for redoing other services.</p> <p>I have setup a project using gorrilla/mux for routing, defined all of my routes, stubbed out all of my handlers, and created structs for most of my responses. </p> <p>My first issue is a question of what the best way to handle parameters that filter what gets returned. Some of our objects are large (20-30 fields) which is not great but something I cannot change and so it would be useful for a client to specify what fields they would like in a query string such as &#34;?fields=[field1,field2,field3,etc]&#34;. Is there an easy way to only marshal part of my struct to JSON? Omitting fields with empty values won&#39;t work since that is sometimes a valid value we would want returned. Should I be using maps instead of structs and is there a good guide on how to best marshall maps into JSON if that is the case?</p> <p>My second issue comes in part due to the design of the old API which I must first replicate before I can build a new version. In the old API we had responses that involved data from many tables. IE we return a client with its subscriptions attached, or a list of clients all with their subscriptions attached. This leads into an N+1 issue where if we had a list of clients we could then have to do a query for each of them for their subscriptions. Obviously it would be better to do a single query with a list of clients whose subscriptions we need and then zip the data together. I thought I would get subscriptions with a list of client ID&#39;s and and return them as a map with the client ID as a key and a value that is an array of the actual subscriptions. Then I would go through each client and bring in the subscriptions from that map. I was just not sure if there were some better patterns to do this.</p> <hr/>**评论：**<br/><br/>CaptaincCodeman: <pre><p>If you want the response to be fully dynamic based on the parameters passed then you should probably be looking at using a map[string]interface{} to encode as JSON instead of a struct so you can add and remove fields as needed.</p> <p>As a general approach a new version is the ideal time to introduce a new API otherwise you&#39;re doing a lot of work to build the &#39;old thing&#39; using the new tech before then building the &#39;new thing&#39;. But I understand people wanting to prove that things work first.</p> <p>I didn&#39;t completely understand the issue you described but Go has some nice constructs to fire things off in parallel and then build the response when everything comes back. If you have an N+1 problem though that may indicate it might be worth looking at denormalising the data. i.e. get a document per client from MongoDB (or whatever) that already has all the subscriptions embedded. It doesn&#39;t matter if the subscriptions are also stored elsewhere as well for not-by-client access - disk space is cheap, duplicate data.</p></pre>lambenttelos: <pre><p>I think I will take a look at using maps. I was a bit hesitant because it it will be a bit more complicated and I had not seen any examples using them, but it seems like that is the way to go.</p> <p>On N+1 issues, spinning things off in GO Routines could make things a bit faster but you are still having to carry out a ton of request to the database. I&#39;ll keep playing around with better SQL and combining things manually here. I should be able to at least get it down to something like 2 DB calls (one for all clients, one for subscriptions). </p></pre>albatr0s: <pre><p>Have you considered just proxying the requests to the old API and start building only the new API in Go?</p></pre>lambenttelos: <pre><p>That is actually a pretty good idea. Unfortunately some changes are being made to the underlying database so we would have to rework the old service a bit anyways. Still might be a decent option though, thanks.</p></pre>