Isomorphic react with Go

<p>I saw a post a few months ago someone posted a repo for an isomorphic go app using gin gonic and ducktape I think. Was wondering what people are doing in production though. From what I&#39;ve been reading it seems best to just run node along side of the go app. </p> <p>This also beckons the question of is doing isomorphic react apps even necessary if your userbase always has js enabled and doesn&#39;t use a browser that too old for polyfills to sort out ecma5 requiremebts. Thanks gophers! </p> <hr/>**评论：**<br/><br/>nicolasmerouze: <pre><p>duktape performance for rendering React apps is really really bad. But I am working on a library using v8worker to render React apps: <a href="https://github.com/nmerouze/sgo">https://github.com/nmerouze/sgo</a> (performances are better than Node.js). In my mind, isomorphism is more for SEO than the small percentage of people with js disabled. If your website/webapp is not public, isomorphism is probably not necessary.</p></pre>Darxide-: <pre><p>Even without isomorphism doesn&#39;t react-router solve that problem too? Thanks for the reply it kind of reinforced my thoughts that it wasn&#39;t necessary and I should really stay away from reading too into these things! </p></pre>nicolasmerouze: <pre><p>In theory, Google is indexing Javascript so react-router is useful. In reality, Google is not yet very good at indexing Javascript so content will not be indexed correctly.</p></pre>jmking: <pre><p>Google Bot may be able to handle basic JS now, but I don&#39;t think it sits around waiting for AJAX calls to complete to populate the page. So if your content still isn&#39;t there on first load, Google won&#39;t index it.</p></pre>patataspuresi: <pre><p>I think the app should check if node is installed and fall back to being just an api server when not</p></pre>ericanderton: <pre><p>My understanding of isomorphic stacks, is that they offer much more than just being able to relocate where processing happens.</p> <p>It&#39;s notably insecure to have all of your business logic embedded in just your client (validations and whatnot), as a relational database alone is insufficient to represent all of your application&#39;s concerns. Instead, one should aim to have your business logic on both the front and back-ends, which adds both speed and security. An isomorphic stack grants an advantage here, in not having to program said logic in two separate languages (JS + what-have-you).</p> <p>I&#39;m looking into doing this using GopherJS right now, but I hadn&#39;t concidered going the other way and moving into a hybrid Go+JS space on the backend. Does this stack layout (Go+Duktape) make it that much easier? Is it worth having Go for database access and HTTP support over Node?</p></pre>Darxide-: <pre><p>| It&#39;s notably insecure to have all of your business logic embedded in just your client (validations and whatnot), as a relational database alone is insufficient to represent all of your application&#39;s concerns.</p> <p>you don&#39;t need an isomorphic setup to validate on both frontend and backend. It&#39;s just a simple ajax call to an API to find out if the action was ok. That doesn&#39;t make it isomorphic, what makes it isomorphic is the ability to render the state of the app on the server. </p></pre>esdffffffffff: <pre><p>In my uses, Isomorphic simply means a good UX on first load. With my apps (not typically websites, but webapps), i have a lot of logic to execute on runtime. It&#39;s just too much to put my firstload visitors through, imo.</p> <p>Sure, you can work on minimizing and lazying as much of that logic as possible, but it&#39;s just really really hard to beat a pure html pageload UX, imo.</p> <p>Regarding business logic, that&#39;s something else entirely imo. You should always be validating on the server - so whether or not you pre-render the first pageload has no bearing on security <em>(assuming you don&#39;t introduce any weaknesses lol)</em>. Eg, in my apps i have 2 servers typically (ignoring load balancers/etc) - render and api. All the validation is done on the api, render just acts as a client on the server.</p> <p>Regarding Ducktape, if you&#39;re using isomorphic js code i think you&#39;d be far better off using Node directly. In my above example, my render server is running isomorphic js on Node. Ducktape is unlikely to ever be faster than Node, and all you gain is not having to run a 2nd server... though, a single Binary would be really nice in some cases.</p> <p>And finally (long post lol), regarding GopherJS - it&#39;s really cool! I&#39;m experimenting with React bindings as we speak. So far my findings are that GopherJS JavaScript output can be fast, but interop back and forth can be really slow. So data communication with React&#39;s state is going to be difficult, and likely not worth it.</p> <p>I&#39;m thinking GopherJS -&gt; JavaScript interop is the only direction that should be done. But i don&#39;t have benchmarks for that statement, yet</p></pre>