App Framework

<p>A few years ago I made Operation Go (<a href="http://gocode.io" rel="nofollow">http://gocode.io</a>) for fun at GopherGala. Since then, I unfortunately haven&#39;t built or launched anything in Go, but I have several ideas that target different markets but follow a highly similar backend pattern.</p> <p>I was wondering if anyone has a good solution or toolset for building the following social web app:</p> <ul> <li>User Auth (local &amp; oAuth)</li> <li>Follow/unfollow users</li> <li>User content (text, image uploads, tags, upvotes, comments)</li> <li>Content feed (with search, sort and filter)</li> <li>Basic admin (ban user, delete content)</li> </ul> <p>I&#39;m hoping to build the app(s) in Go because I enjoy the language and am efficient in it, but I was wondering if there were any suggestions on rapidly building this functionality or recommendations on packages to use before I start scouring GitHub.</p> <hr/>**评论：**<br/><br/>qxclpxzk: <pre><p>You&#39;ll most likely have to write everything yourself. There are ORMs that can simplify your database interaction, and there are REST frameworks that can simplify your routing and access control. JavaScript front-ends will make it so you only have to create JSON endpoints on the back-end which you can consume with your front-end app (and just as easily a mobile app).</p> <p>As far as tools, here&#39;s what I enjoy using:</p> <ul> <li><a href="https://github.com/go-pg/pg" rel="nofollow"><code>go-pg</code></a> is an ORM for PostgreSQL that is pretty darn efficient. The only SQL you&#39;ll have to write is for table creation.</li> <li><a href="https://vuejs.org/" rel="nofollow"><code>Vue.js</code></a> is a lightweight and trendy front-end.</li> <li><a href="https://gin-gonic.github.io/gin/" rel="nofollow"><code>Gin</code></a> is a great REST mini-framework in my opinion, and it makes for very terse and orthogonal code. <ul> <li>Supports router groups and applying middleware to them. You can, for example, create an <code>authed</code> group and an <code>admin</code> group that are each protected by a middleware that will verify that the user is logged in or is an admin, respectively.</li> <li><code>gin.Context</code>&#39;s <code>Bind(&amp;yourStruct)</code> method is something you&#39;ll learn to love when developing REST APIs. It binds POSTed JSON or any URL query parameters to a struct in one statement.</li> </ul></li> <li><a href="https://github.com/golang/oauth2" rel="nofollow"><code>OAuth2</code></a> will get you OAuth support.</li> </ul> <p>Here&#39;s an <a href="https://github.com/Qxcl/skeleton" rel="nofollow">example</a> of a basic application I wrote as a learning exercise with <code>go-pg</code> and <code>gin</code> that provides local user authentication. It may give you some ideas on how to architect your solution.</p></pre>everdev: <pre><p>Thanks! This is the same thing I was thinking of doing, piecing together a few packages as a personal boilerplate.</p></pre>fawa123: <pre><p>Mind me asking but why would you use a frontend framework if working with Go? Isn&#39;t the templating engine enough? To me it looks as if it is just introducing overhead while achieving nothing I could not do out of the box.</p></pre>nstratos: <pre><p>Quite a few reasons. If you are working with a small and simple web app, I&#39;d say that Go&#39;s template engine is more than enough. But if you are working on something more complex than that, I find that templates are harder to work with at scale. The alternative is to keep Go as a pure back-end language to develop the API and use your favorite front-end framework to write the HTML/JS/CSS UI, usually as a single page application.</p> <p>This separation gives you quite a few benefits, one of which is that as soon as you have your API then you can attach different front-end apps to it. Think about creating a console UI, a single page UI, a native mobile UI and heck even a Go web app that uses the template engine all of which will get their data from that single API. Some people also call this dog-fooding because in order to build your view, you pass through your own API, instead of just using it for external apps.</p> <p>Another nice benefit, in case you are working with a front-end team/person is that they can focus on building the UI using their favorite front-end tech, while you can enjoy working with pure Go on the back-end. Sometimes it even helps keeping the codebase as two separate projects.</p> <p>One more benefit, in case you&#39;re plan on developing an API for your template powered web app later is that with this method you start with the logic and design of the API from the very start, which will end up creating a much better and battle-tested API and will also reduce the amount of work and duplication. Why have a bunch of handlers that parse and validate forms and also an API that does the same using JSON while you can have just the API?</p> <p>Obviously, as with every decision there are trade-offs. Indeed it adds some overhead and complexity as for example suddenly you need to start worrying about implementing some kind of authentication/token mechanism for your API, use stuff like CORS to allow AJAX calls etc. Furthermore, if you are working alone and front-end is not your strongest point, maybe you will find it harder working with the pure HTML/JS/CSS app while sprinkling some CSS or importing a JS library for a template is usually easier to grok.</p> <p>Last but not least there is always the argument of server-side rendering (template generating views) vs client-side rendering (Go API + JS front-end) and depending on what you are trying to achieve, one method might be more suitable for the task than the other.</p></pre>fawa123: <pre><p>So disregarding server vs client side rendering it pretty much comes down to the team preference you are working with for the frontend (golang vs web stack)?</p> <blockquote> <p>But if you are working on something more complex than that, I find that templates are harder to work with at scale. </p> </blockquote> <p>I would disagree with this tough seeing templates can be arranged heavily modular thanks to the define statement. It always heavily reminded me of the React approach.</p></pre>4silvertooth: <pre><p>Check out <a href="https://github.com/go-gitea/gitea" rel="nofollow">https://github.com/go-gitea/gitea</a> stack, macaron for routing and middleware, xorm for orm.</p></pre>