What are the benefits of creating interfaces for datastores?

<p>I&#39;m in the process of creating a datastore that will be utilized by the handlers of a web app that I am working on. I&#39;ve found a lot of example datastores, particularly these [<a href="https://sourcegraph.com/sourcegraph.com/sourcegraph/thesrc@ed5b6d4e8d990094112494c0e6764964f655541c/.tree/datastore/posts.go" rel="nofollow">1</a>,<a href="https://github.com/spbooks/go1/blob/master/chapter7/4_displaying_images/image_store.go" rel="nofollow">2</a>]. Both of these datastores use interfaces to outline the capabilities of the datastore. The interface for the datastore from <a href="https://sourcegraph.com/sourcegraph.com/sourcegraph/thesrc@ed5b6d4e8d990094112494c0e6764964f655541c/.tree/datastore/posts.go" rel="nofollow">example 1</a> is defined from lines 40 to 52 on <a href="https://sourcegraph.com/sourcegraph.com/sourcegraph/thesrc@ed5b6d4e8d990094112494c0e6764964f655541c/.tree/posts.go" rel="nofollow">this page</a>, and the interface for the datastore from <a href="https://github.com/spbooks/go1/blob/master/chapter7/4_displaying_images/image_store.go" rel="nofollow">example 2</a> is defined from lines 9 - 14 in the same golang file. What are the benefits of using an interface to outline the capabilities of the datastore. The author of <a href="https://github.com/spbooks/go1/blob/master/chapter7/4_displaying_images/image_store.go" rel="nofollow">example 2</a> states in his book, &#34;Interfaces are an ideal way to mock out parts of your code while testing; however, they’re not always the best solution for mocking parts of your code. If the only reason an interface exists is to allow you to create a mock interface in your tests, chances are it’s introducing more complexity in your codebase than is required.&#34; I am debating whether to implement a interface for my datastore? Any opinions on this matter would be greatly appreciated. </p> <p>Thanks</p> <hr/>**评论：**<br/><br/>ecmdome: <pre><p>Also allows you to easily switch to a different datastore later on while keeping the same interface </p></pre>jerf: <pre><p>When you don&#39;t accidentally prevent yourself from doing this from day 1 by accidentally over-binding to a specific storage technology, you&#39;ll be surprised just how often this comes up in practice. People end up swapping data stores far less often than they should, or they would if it were cheap. Everyone&#39;s so inured to being stuck on a particular data store than they don&#39;t really realize it.</p></pre>vegasje: <pre><p>Even using interfaces as a method to prevent from binding to a specific storage technology, I have found it very difficult to architect an application that is flexible enough to allow swapping out of storage mechanisms at will.</p> <p>Moving between two RDMS, or moving between two KV stores is pretty simple, but architecting in a way that would allow you to move between, say, MySQL and DynamoDB has proven to be quite difficult.</p> <p>I would be extremely interested in seeing any examples of storage layer abstractions that provide enough flexibility to allow for my latter example.</p></pre>willnorris: <pre><p>Just one data point - our team at Google is working on a new App Engine app using Google CloudSQL and have a interface for our datastore for exactly that reason... providing easy mocking for testing our frontend code.</p></pre>digitalGardener: <pre><p>huh, well if Google does it ... I&#39;m just kidding, thanks I&#39;m leaning towards going with interfaces because I appreciate the structure and ease of mocking.</p></pre>mc_hammerd: <pre><p>how does one do mock testing for the front end code regarding go interfaces? ive never tried that, is there an example anywhere i can look at?</p></pre>Emperor_Earth: <pre><p>A tangential point: </p> <p>How about having a struct wrapping a database implementing io.Writer? </p> <p>I will be playing around with this idea for fun later this week. The practical goal is to log to Cassandra using pkg log. </p> <p>log.SetOutput takes an io.Writer as a parameter, so I thought it would be cool to write 401s/500s/etc to a Cassandra db.</p></pre>