<p>I am getting tired of adding last minute endpoints to our "REST" api. When functionality is constantly changing, and all the time I have is to just implement, the "REST" api starts to become a mess.</p>
<p>I'm thinking that with with graphql things should be a bit more organized, since there is really only mutations and queries.</p>
<p>But seeing the go libraries for graphql I'm not too sure if it's ready for production yet, or how convenient they are to develop in.</p>
<p>Has anyone been using Go with graphql in production? Whats your take on it?</p>
<p>Go is very important for us, but I'm beginning to think about gong back to, gasp, PHP or even try out Apollo's graphql server.</p>
<hr/>**评论：**<br/><br/>singular_pirate: <pre><p>It's a shame someone grabbed the very search engine friendly <code>graphql-go/graphql</code>.</p>
<p><a href="https://github.com/neelance/graphql-go">https://github.com/neelance/graphql-go</a> is very idiomatic and is actively developed. Go and GraphQL are a natural match, and this library leverages those strengths.</p></pre>joefitzgerald: <pre><p>We're also using <a href="https://github.com/neelance/graphql-go">https://github.com/neelance/graphql-go</a> and it's a great solution for us.</p></pre>sh41: <pre><p>For those who don't know, <a href="https://github.com/neelance">https://github.com/neelance</a> is the main creator of GopherJS (<a href="https://github.com/gopherjs/gopherjs/graphs/contributors">https://github.com/gopherjs/gopherjs/graphs/contributors</a>). He's actively working on graphql-go, so it's no surprise it's a great library.</p></pre>drink_with_me_to_day: <pre><p>Nice, good to have more people in vouching for it. I had seen a comment about neelance's version, but it was over 3 months ago, and the repo looked a bit empty. I'll take another look.</p></pre>saviorisdead: <pre><p>Disclaimer: we have GraphQL server built with <a href="https://github.com/graphql-go/graphql" rel="nofollow">https://github.com/graphql-go/graphql</a> running in production for almost a year now and actively working on replacing it.</p>
<p>I will say that Go is bad fit for that task. Main reason is nature of GraphQL, it's just too much for Go's type system and in the end you forced to use <code>interface{}</code> everywhere. As a result of that code looks worse, it's hard to support and maintain. And don't forget about performance penalty of <code>interface{}</code>.
Better approach, in my opinion is to build GraphQL server in different programming language, with better support for that kind of task (JS and TypeScript or even Scala) and fetch required data via gRPC calls to Go-based services.</p></pre>kidovate: <pre><p>I'm sorry to say that you guys are not using the right approach. In Go the best way to do it is static code analysis with interfaces, funcs, and labeled fields filling your GraphQL schema. </p>
<p>Neelance and I both do it this way:</p>
<ul>
<li><a href="http://github.com/neelance/graphql-go">http://github.com/neelance/graphql-go</a></li>
<li><a href="http://github.com/rgraphql/magellan">http://github.com/rgraphql/magellan</a></li>
</ul>
<p>Go is most certainly suitable for Graphql especially with it's strong parallelism and concurrency. You're just not using the right library for the job. </p></pre>thesnowmancometh: <pre><p>Really glad I read these threads before starting to use <code>graphql-go/graphql</code>! I haven't seen these alternatives before.</p></pre>drink_with_me_to_day: <pre><p>Yeah, Go's type system is a big pain, even doing just normal REST.</p>
<p>It's unfortunate, because Go is just a great fit for us, and being able to compile and deploy a single binary is very attractive.</p></pre>nemith: <pre><p>Go just doesn't fit the way you are used to. If you try to apply dynamic typed language ways to Go you will have a bad time.</p></pre>
