<p>Let's say you just finished you big web app written in Go. For the sake of example, let's say that project is <a href="https://github.com/mattermost/platform">mattermost/platform</a>.</p>
<p>Now, you're about to start a new web app. It requires all of the common things that a web app requires today, sessions, authentication, authorization, data store, etc.</p>
<p><strong>How would you reuse what you already implemented to make the second web app process faster?</strong></p>
<p>Looking at mattermost/platform, I see many stuff are tightly integrated to the app itself. Am I right to say that they are not reusable?</p>
<p>I picked mattermost/platform because it sounds like other Go web apps also feel the same: You cannot reuse what you already wrote, if you try too hard to abstract the features into reusable components, your code looks less and less idiomatic Go.</p>
<p>For a concrete example, have a look at the <a href="https://github.com/mattermost/platform/blob/8406e854aa912f3d7f9179b10356444f07e25223/store/sql_upgrade.go">sql migration code</a>. This is so tightly coupled with the app itself.</p>
<hr/>**评论：**<br/><br/>egonelbre: <pre><p>Designing good reusable packages is difficult. To get to a reusable package I would write 3 applications by copy and pasting as necessary... then afterwards find the commonality and design packages for them.</p>
<p>You can make this easier, if you separate your application based on value you will end up in a good place. (Think of a project structure where you can delete a feature by deleting a single folder and one line from elsewhere.)</p></pre>epiris: <pre><p>You would refactor them into a separate package, learning along the way design patterns to make that process easier in the future by struggling with the things that made it difficult. Each time it gets easier until it's a matter of cp -a *.go $newpkg; and a package rename.</p>
<p>Identifying early the structure and components of your system to minimize doing the above is a general programmer trait that just comes with experienced. That trait just needs to become acquainted with language idiosyncrasies regardless of what it is, Go, c++, python, all may model differently for reuse.</p>
<p>To note on this app itself, it's intended to be tightly integrated it appears, because it's a standalone app.</p></pre>beeker1121: <pre><p>I agree.</p>
<p>If OP means how would you go about developing a new, separate web application that reuses the existing logic and components/pieces of the current app, then you're 100% right. Creating the structure for your application that makes sense and is easily reusable, testable, etc just comes with experience and fine tuning of ideas that come from building apps in Go (and reading articles and what not). This just takes time.</p>
<p>If OP means though how would you actually structure it, there's a few ways. For instance in my current web app, all of the backend logic is built into services. These services are each their own package and could easily be used to make a web app, CLI app, or whatever.</p>
<p>There's not many articles on this method afaik, but this is where the basic idea comes from <a href="https://medium.com/@benbjohnson/structuring-applications-in-go-3b04be4ff091#.hgjql7k9f" rel="nofollow">https://medium.com/@benbjohnson/structuring-applications-in-go-3b04be4ff091#.hgjql7k9f</a></p></pre>joncalhoun: <pre><p>So have a fever so this will be brief, but there are a few approaches:</p>
<ol>
<li><p>Use or create a generator to help generate similar but custom code for the common parts. <a href="https://goa.design" rel="nofollow">https://goa.design</a> does this well</p></li>
<li><p>Create reusable packages that can be connected together quickly. Eg you might build or use something like <a href="https://github.com/go-authboss/authboss" rel="nofollow">https://github.com/go-authboss/authboss</a> to share some of the auth functionality. </p></li>
<li><p>Stop trying to reuse everything. Sometimes copy pasting and adapting the codebase for a new app isnt so terrible. It is def better than having packages that are incredibly hard to customize or debug, which is a state I see a lot of Rails apps get in.</p></li>
</ol></pre>scheldkultur: <pre><p>premature modularization is the root of all evil</p>
<p>maintaining a bad abstraction is a thousand times more expensive than maintaining copy pasting</p>
<p>YAGNI</p></pre>_mattlondon: <pre><p>You could refactor everything into your own packages (could take quite a lot of time to get something general purpose), but if you care about making your second web app process faster then it could be worth considering a decent framework? </p>
<p>I've done several medium-ish things in AppEngine and it deals with a lot of your stated things (authentication, data store etc) for you.</p></pre>m3wm3wm3wm: <pre><p>Would you mind sharing which libraries/framework you used for your App Engine apps? Any open sourced?</p></pre>
