<p>Im trying to learn how to build a web application. I am still researching, but I was just wondering if someone could check to see if my understanding is correct.</p>
<p>So far this is my understanding of the main parts to building a web application. Yet I just feel there is so much more (e.g. load balancing) to building a web applcation, so aswell as whats listed below if you could suggest anything else that is needed to build a web application it would be greatly appreciated:</p>
<p>Hosting</p>
<blockquote>
<p>Amazon AWS</p>
</blockquote>
<p>Server side</p>
<blockquote>
<p>Go</p>
<p>Learn net/http, which will help you choose a go web framework</p>
</blockquote>
<p>Front End</p>
<blockquote>
<p>Javascript templating library - React</p>
</blockquote>
<p>Tools</p>
<blockquote>
<p>Version control - Git</p>
<p>Text Editor </p>
</blockquote>
<p>Furthermore I have no understanding how the front end technologies interacts with the serve side technologies. So again any help on this would be greatly appreciated aswell.</p>
<hr/>**评论：**<br/><br/>iends: <pre><p>You can build a web application locally with just Go. Focus on learning one thing at a time. If you try to learn full stack development and DevOps all at once you are going to get very discouraged very quickly. </p>
<p>Start with learning how to build traditionally multi page apps with Go (using net/http) first. </p></pre>edsionmax: <pre><blockquote>
<p>You can build a web application locally with just Go</p>
</blockquote>
<p>You see even this I am not sure what you mean. Does "locally" imply that you would otherwise build a web app <em>remotely</em>?</p>
<blockquote>
<p>traditionally multi page apps</p>
</blockquote>
<p>What other apps are there? and presumably they are more complicated?</p></pre>nameless912: <pre><p>Okay so basically, here's what you need to know:</p>
<p>Fundamentally, there's nothing that makes your computer different than a compute node on AWS other than the fact that the AWS one has a static IP address and DNS pointing to it. If you run <code>ListenAndServe(":8080", nil)</code> on your own machine, you'll be able to type <code>localhost:8080</code> into your web browser and see your web server running.</p>
<p>In terms of where to start, it really depends on what you want to do: if you're interested more in the front end, learn that first. If you're interested in the back end, learn that first. On a very basic level, here's how the two interact:</p>
<p>The front end is usually your HTML/JS/CSS code. It's loaded as a static asset (i.e. from some address, like <code>localhost:8080/index.html</code>), and parsed by the browser. Usually, you'll have some Javascript code in your front end which makes calls to your back end using what's called REST (stands for "<strong>RE</strong>presentational <strong>S</strong>tate <strong>T</strong>ransfer), which basically boils down to calling specially-formulated URL's (web addresses) to pull down and push up information from/to the back end.</p>
<p>Your back end usually interacts with your data store (for example, a database, but could also just be a regular old file if you're just getting started), and potentially does some transformation on that information.</p>
<p>For example, let's say I have a form on my website for people to input a story about programming. I would set up a page with a text form and a button and store that in <code>index.html</code>. Then I would write some CSS "styles" (rules on what to style and how to style it) and store that in <code>styles.css</code>. Then I would write a Javascript file (<code>script.js</code>) that sets up an event listener to the button so that when someone pushes the button, we use AJAX (another technology that provides a Javascript API to talk to web servers) to push the text in the text box to a special URL called <code><domain>/story/</code> using what's called a "POST" call. your backend would accept that URL and push the data into a file. Finally, I would have some server (not necessarily your application server [the one that hosts the <code>/story/</code> endpoint], but it can be) serve the <em>static assets</em>, i.e. <code>index.html</code>, <code>styles.css</code>, and <code>script.js</code>. That's the web server/endpoint presented to your user; they shouldn't have to care about your app API, because your front end (i.e. your HTML/CSS/JS) will take care of interacting with it for you.</p>
<p>If all that sounds overwhelming, sorry :) that's just programming for you.</p>
<p>I would make a couple of suggestions:</p>
<ol>
<li><p>Take the Coursera course from Johns Hopkins about front end web development. It's free, open source, and relatively simple. You <em>must</em> learn regular old web development without any fancy frameworks or anything before trying to use something like React.JS. If you don't know the basics, you will get <em>boned</em> when you encounter something you don't understand, which happens a lot with fancy front-end frameworks.</p></li>
<li><p>Don't try to use <code>net/http</code> directly right now. It's much easier to use something relatively prebuilt (like gorilla mux) and work through their prebuilt examples, and the extra speed and understanding that <code>net/http</code> offers you won't make a huge difference in the end until you get to much more advanced situations.</p></li>
<li><p>Develop locally. Don't worry about AWS until you actually want to put your site up somewhere.</p></li>
<li></li>
</ol></pre>SportingSnow21: <pre><blockquote>
<p>You see even this I am not sure what you mean. Does "locally" imply that you would otherwise build a web app remotely? </p>
</blockquote>
<p>"Local"/"Locally" refers to the laptop/desktop computer you have in front of you. Any deployment to AWS/GAE/DigitalOcean, etc is not local. <a href="/u/iends" rel="nofollow">/u/iends</a> is recommending you start small and build a web app that runs on your computer, so you can test it out from the same machine. I second this recommendation. Work on one part at a time, so you're not bogged down by the complexities of getting them to work together.</p>
<blockquote>
<p>What other apps are there? and presumably they are more complicated? </p>
</blockquote>
<p>Multi-page apps are the webapps of the 90's, before the big javascript craze. The web-pages are generated on the server, so there's little to no javascript framework to deal with. Go's standard library has all the tools to build out a simple multi-page app (net/http, html/template). You can focus on learning the server-side code, html, and templates. Once you're comfortable with that, move on to incorporating a JSON API to the site. Then you can focus on building a single-page app using those API endpoints. Single-page applications, which is the target of React/Angular/Aurelia/etc javascript frameworks, are more complicated than traditional multi-page apps because they need all three of these parts (back-end, API, front-end) at once. Each one can be a career, so avoid trying to tackle them all at once. Focus on one at a time and you'll get comfortable with the ideas involved.</p>
<p>EDIT: Starting with a small Go codebase will allow you to get comfortable with your text editor and git/github and experiment with different setups without worrying too much about making mistakes. </p></pre>thesilentwitness: <pre><p>I'd recommend skipping React unless it's strictly necessary for your project. You're not just learning React, you're learning ReactJS, Javascript, ES6, JSX, Babel, maybe TypeScript, webpack, and probably a bunch of other stuff I'm unfamiliar with. If you're unfamiliar with all of the things you've already mentioned then you'll be doing a years worth of learning before you're even in a position to write something.</p></pre>
