<p>I am curious how do you people work with Go in an enterprise environments when you often need to talk to unknown (often shitty) SOAP endpoints or consume messages from proprietary MQs etc.
How do you deal with it ?</p>
<hr/>**评论：**<br/><br/>egonelbre: <pre><p>It really doesn't differ much from other languages. Usually drinking and crying in a bath helps.</p></pre>bob123456778: <pre><p>I have to disagree. Other languages/platforms have out of the box support for the ugly stuff mentioned in the post. Unless you have the time, money, and patience to reinvent the wheel, or trust in <ENTER NAME> random open source library, choose a different language. Go is great, but it is a poor fit for effectively dealing with a big ball of legacy enterprise mud.</p></pre>egonelbre: <pre><p>Sure, the substance being drinked and the amount of tears collected in the bath, depends on the libraries and languages. But I've yet to see language/library to completely eliminate the pain. </p>
<p>Of course when you don't have to deal with them there isn't a problem.</p></pre>vompatti_: <pre><p>So you're saying that all this time all I needed was a bath? </p></pre>jimijiim: <pre><p>lol what? even PHP has better support for all that XML bullshit. Go has basically next to none. good luck working with SOAP in Go.</p></pre>globalgobble: <pre><p>It has some but it's cumbersome. Looks like a lot of people resigned to use proxies.</p></pre>metamatic: <pre><p>There's no XPath and no XML normalization, which means you can't properly implement XML signature and encryption, which means you can't implement SAML, which is commonly used for enterprise single sign-on.</p></pre>shovelpost: <pre><blockquote>
<p>There's no XPath</p>
</blockquote>
<p><a href="https://blog.labix.org/2013/06/07/efficient-xpath-for-go" rel="nofollow">https://blog.labix.org/2013/06/07/efficient-xpath-for-go</a></p></pre>metamatic: <pre><blockquote>
<p>an efficient and strict subset of the XPath specification
[...]
Richer expressions and namespaces are not supported</p>
</blockquote>
<p>Which is not XPath 1.0, let alone 2.0, and not enough for XMLsig and SAML support.</p></pre>niosop: <pre><p>We're not super "enterprise-y", but the biggest issue I've run into is not being able to talk to Informix. Which leaves me a couple choices. I can use some other language for the project, I can write up a python proxy to make the actual queries, or I can write my own driver using the C bindings. Right now I've implemented the proxy option, which seems to work fine, but I'm not locked into the decision yet.</p></pre>globalgobble: <pre><p>Well I do not think python and Go can compare but we often find ourselves implementing proxies / middleware in Java / C# and then the question arises why not to do the whole project in it as well</p></pre>niosop: <pre><p>It's a valid question for this project as well. Part of the reason for going with Go was ease of deployment. A static binary plus the use of an in process database would make deployment and setting up test environments dead simple.</p>
<p>But if we have to end up having a python proxy and NATS for communication (could use other stuff, but I like NATS), then that pretty much kills most of the deployment advantage.</p>
<p>Right now it pretty much comes down to what I feel like coding in. At the moment I'm a bit more motivated to use Go than starting another python project, but if I hit another blocker then that might change.</p></pre>mobiledevguy5554: <pre><p>There is no odbc driver for Informix?</p></pre>niosop: <pre><p>There is, but I haven't had any luck getting it to work and the one other post I found of someone trying under linux was just them giving up and using Windows.</p>
<p>Maybe my google-fu has failed me, or maybe I just need to try again, but I banged my head against it for quite a while before giving up.</p></pre>mobiledevguy5554: <pre><p>It did take me a while to figure out how to get freetds and unixodbc working on my mac with SQL Server but it works great.</p>
<p>i'm using this ODBC go library</p>
<p>github.com/alexbrainman/odbc</p></pre>niosop: <pre><p>Thanks for motivating me to try again. Updated unixodbc to a newer version, found some a hint on SO from someone who had gotten it working recently (UNICODE=UCS-2), and it's working!</p>
<p>Just had to wait a bit for smarter people than me to hit the same problems and come up w/ solutions.</p></pre>kardianos: <pre><p>Is there docs on the Informix wire protocol? Is there a native Java or C# version that can be used for reference?</p></pre>PaluMacil: <pre><p>I'm lucky to have not had a SOAP endpoint to talk to in two years now. I'd probably be fine with using something on Github. I tend to have good experiences with high traffic libraries such as those used in communications since they get so much testing as soon as you turn it on. The only thing I deal with a lot that I don't want to use go for is talking to Active Directory, but for that I maintain an application in C# which produces a change feed the goes to the Go application (and some .Net Core stuff running on Linux Docker containers).</p></pre>globalgobble: <pre><p>How does the change feed look like ? What is your .NET app producing and how do you handle availability / throughput ?</p></pre>PaluMacil: <pre><p>The change feed is serialized JSON (compression is intended but hasn't been implemented) with a few important fields like email, department, manager, etc for users and also groups and group membership is sent. There are infrequent feeds (http at the moment, but we're looking at different protocols) of the entire configuration and there are delta (small, frequent) feeds which are serialized changes since the last full feed / delta feed. If it sounds like we're duplicating a lot of stuff that is built into AD, that's exactly true, but then only 20% of our users come from an AD system, so we needed to build our own user, role, and auth system anyway.</p>
<p>Part of it has to do with political decisions rather than technical. My team operates outside of IT with our own products and we cannot write changes back to AD when role memberships, user info, etc changes in our products. In fact, our products (APIs and websites) actually live outside our domain and only get information from inside the network via the feeds. Unless someone has weird needs, our setup probably isn't something to emulate but... then again, most developers wind up with some weird needs. :)</p></pre>globalgobble: <pre><p>This sounds interesting. Did you do it because it was faster / easier to do in C# than with Go ? Because I am sure this can be done in Go as well it just requires extra effort.</p></pre>PaluMacil: <pre><p>In this case it's simply because I have written a lot of AD integration stuff in the past (before I knew Go or worked for a company that used Go) and it's also really easy to type <code>using (PrincipalContext ctx = new PrincipalContext(ContextType.Domain))</code> instead of spending a few seconds thinking about the LDAP query string which you'd need for a Go library. We're thinking about moving that bit to Go if we decide to use gob instead of JSON, but I don't see us making time for that, so it'll probably stay.</p></pre>Redundancy_: <pre><p>I don't think there's a need to do everything in a single language. Enterprise Integration Patterns even has patterns like the "messaging bridge" or "service activator" etc. These patterns are made even easier these days with containers.</p></pre>globalgobble: <pre><p>I fully agree but do not forget that enterprise companies are mostly concerned about being able to quickly hire/fire people. They need you to be replaceable and in certain parts of the world it's difficult to find Go programmers hence most of the companies will want to stick what is defacto standard (C#/Java)</p></pre>peterhellberg: <pre><p>I've found that when working in enterprisey environments it is often beneficial to isolate the "shitty" parts and then use these isolating services from the rest of the services being actively developed. Using event streams or message queues can be a way to "liberate" otherwise hard to reach data.</p>
<p>(I am also a big fan of decoupling services by using JWT:s)</p></pre>binarypie: <pre><p>We are one of the largest game companies in the industry. I've centered my entire org around using golang for infrastructure automation, monitoring, and orchestration. It has worked very well. The cross-compilation is a huge win for our needs as is the quick compile time and binary distribution of said packages. The language is easy to learn and thus even those that have never programmed before are able to pick it up and start making contributions. To me Go is a better C with an python-like ease of entry.</p></pre>shovelpost: <pre><blockquote>
<p>We are one of the largest game companies in the industry.</p>
</blockquote>
<p>Which company?</p></pre>egonelbre: <pre><p>Did a quick write-up of consuming bizarre message formats <a href="https://medium.com/@egonelbre/specification-types-ed9ddf35ec8f" rel="nofollow">https://medium.com/@egonelbre/specification-types-ed9ddf35ec8f</a></p></pre>metamatic: <pre><p>I work for a big well-known enterprise software company, and SOAP is on the way out. All the new stuff is REST-based. (Which suits me fine, because after using it once with Java, I decided I never wanted anything to do with it again because it's a disaster of a standard.)</p></pre>ants_a: <pre><p>Standard? SOAP is a designed by committee heap of garbage with about 12 different incompatible ways to solve things that aren't even problems. But at least there's a specification to work to. REST is a pile of wishy washy feel good language and wishful thinking. It's a non standard. The only reason why it makes any sense is that SOAPs features are worse than useless due to the unnecessary complexity. </p></pre>bob123456778: <pre><p>Always easy to spot someone who has done their time in the trenches with SOAP :-)</p></pre>
