Gin framework use cases?

<p>Do you guys know of any projects that use the Gin framework in Go, so I could look at their code? Thanks</p> <hr/>**评论：**<br/><br/>shark1337: <pre><p>From their github repo:</p> <p>Awesome project lists using Gin web framework.</p> <p><a href="https://github.com/drone/drone" rel="nofollow">https://github.com/drone/drone</a></p> <p><a href="https://github.com/appleboy/gorush" rel="nofollow">https://github.com/appleboy/gorush</a></p></pre>sfdfssdsdf: <pre><p>Thanks, but I&#39;m looking for frontend heavier projects (so i can look at their structure and management of a lot of templates, etc)</p></pre>shark1337: <pre><p>Hmm, gin is a backend framework, not a frontend one (like react, angular etc), but I got you. Most of the big projects (that are NOT open source) keeps their code private, but I don&#39;t see such a big deal with gin. If you&#39;re gonna inplement an graphql api or working bit sql database, gin is not gonna be needed here. Other than that, gin could be usefull for routing and applying some middlewares, but don&#39;t think that&#39;s gonna build the project for you. I like to make my project starting from the base so I can easily customize it. I coded like half a year in node js and was using express js (the most popular http framework out there, gin API is inspired from express js ) and most of time I only needed to make some routing, server some files and sometimes to apply 1-2 middlewares which was kinda useless to get framework, but it was the simplest way to do it. I know it can make your life easier, but sometimes it won&#39;t really. If you&#39;re gonna run in production, serving the files should be done with nginx and routing could be easily made with httprouter that is full net/http compatible and accepts custom middlewares. Now gin might also be a good choice, I heard that the standard net/http library has some &#34;bugs&#34; for production and need some deeper configuration, maybe gin includes it out of the box. Other than that, gin framework is a fat framework, you can start using gin firstly and after you finished the project try to reduce as many dependencies as possible and replace the gin code with the vanilla one. You&#39;ll be fine either way ;)</p></pre>snippet2: <pre><p>It&#39;s just cool for testing. It&#39;s really a tool to use then take off. As most good go tooling is. It tracks the posts/gets as you build your API.</p> <p><a href="https://medium.com/@etiennerouzeaud/how-to-create-a-basic-restful-api-in-go-c8e032ba3181#.ovs0uix9k" rel="nofollow">https://medium.com/@etiennerouzeaud/how-to-create-a-basic-restful-api-in-go-c8e032ba3181#.ovs0uix9k</a></p></pre>tmornini: <pre><p>You would do yourself a favor and consider separating the front-end and back-end of your app.</p> <p>Use HTML/CSS/JS for UI/UX front-end and go for API back-end.</p></pre>mixedCase_: <pre><blockquote> <p>You would do yourself a favor</p> </blockquote> <p>But depending on the site&#39;s audience, he may not be doing the users a favor.</p> <p>Plus you don&#39;t need different technology stacks to separate concerns. Turn your application into a library and in a separate package implement the web server.</p></pre>tmornini: <pre><p>And the audience would care why?</p> <p>Because they love waiting for page loads?</p> <p>Or because they&#39;re using IE 5?</p></pre>mixedCase_: <pre><blockquote> <p>Because they love waiting for page loads?</p> </blockquote> <p>Precisely because they don&#39;t love waiting for your JavaScript to be JITted and slug around, if it doesn&#39;t outright OOM the browser. Plenty of people develop sites for audiences that use low and medium end phones.</p> <p>Not to mention not having to put a fortune onto SEO and being accessible.</p> <p>I&#39;m saying this as I develop a web app (rather than web site) in Elm on my workstation; JS frameworks have their place but are not silver bullets and much more often than not are completely overkill for the projects they&#39;re used for. They&#39;re clearly good for one thing though: web <strong>applications</strong>.</p></pre>tmornini: <pre><p>The less of an application it is, the less JS than overload the browser, and the more reason to keep it HTML/CSS/JS native.</p> <p>I agree with you on JS frameworks. Bloatware supreme.</p></pre>emansom: <pre><p>None. Use net/http</p></pre>UnknownTed: <pre><p>write less &gt; write more</p></pre>