Web Application front-end and back-end misunderstanding - angularjs

Question

I need a bit of guidance/advice. I have decided to build a web application but I’m having difficulty putting all the components together.
I’ve made basic websites in the past but have forgotten a lot of it. I studied JavaScript and Java in the past but I’m a little rusty so if you decide to reply please treat me like a person that’s new to all of this.
Basically I am having difficulty understanding the backend and front end of the whole web application and what exactly I will need. I’ve done some research found out that I will need MySQL, Tomcat server or Apache? (I don’t understand this part), Spring Tool Suite, knowledge of Java and AngularJS for the front-end. I have basic SQL knowledge. I’m having difficulty binding all this together.
The application I am trying to create is a prototype so not a full application. I’d like to be able to enter data into text boxes which is then visually represented on graphs/charts. I understand that AngularJS is capable of achieving this. Is AngularJS the same as JavaScript? Where does Java come in all of this? I thought a web programming language is needed so why is Java used? Is Java used for the backend? What will MySQL be used for and the Tomcat or Apache server also? I prefer to stick to JavaScript/Angular and Java if possible because I haven’t learned any other languages like PHP or C.
I am working on a Mac if anyone is wondering. I have the following already installed on my machine:
Latest JDK
Spring Tool Suite
MySQL
Could anyone please clarify this for me as best as possible? I don’t think it will take a lot for me to understand it all as I do have knowledge in computing but I’m a bit rusty since it’s been a while since I last used it all.
Any help is greatly appreciated!

Answer 1

There's a lot packed into this question. I'll try to answer it all, but bear with me. Because I hope to cover so much ground, keep in mind that a lot of what I say will be imprecise, and you should definitely read up some more on these topics. You're on the verge of entering a whole new world of programming possibilities if you enjoy it, so take your time and try to soak it all in at your own pace.
First, some basics on web technologies. Possibly the most fundamental thing to understand here is the separation between the client and the server. These terms are broadly used in software discussions to refer to the thing processing, storing, and providing data (the server) and the thing allowing the user to request, view, interact with, and make changes to that data (the client) . What exactly the client and server are will vary widely based on what sort of context you're talking about, but in the world of web development:
The client is generally assumed to be a web browser. There are lots of different web browsers (e.g. Chrome, Firefox, Safari, Internet Explorer/Edge, Opera, ...) and they each have their own quirks, but by and large if you don't try anything too fancy and you stick to recent version of browsers your results will be basically the same no matter which browser you use to view your web page.
When talking about "the server", you can be referring to a few things depending on the sentence you use it in: the server-side code you write (more on this in a minute), the piece of software that handles your server-side code and serves your web pages (this would be Apache or Tomcat), or the physical collection of aluminum, silicon, and plastic on which the above software is running (that is, a computer, anything ranging from your laptop to a dedicated machine). For the purposes of this discussion we'll stick to the first two.
As I said earlier, the most important part of the client/server distinction is in the separation of concerns between presenting and enabling interaction with data on the client and processing and storing data on the server. As much as possible, try to keep those separate; it will make your life much easier in the long run. The client code shouldn't have any idea how the data is stored or processed; that's the server's job, and the client shouldn't need to know. Similarly, the code you write on the server shouldn't care in the least how the data is being formatted and presented to the user. Instead, it should try to provide data in a format that is easy to deal with in lots of different ways.
But I'm getting ahead of myself. First we need to talk about the technology questions you asked. So let's drill down a bit.
The Client
Usually, different programming languages are used on the server and the client1. There are three primary languages used in the browser, and each has a distinct purpose that compliments the purpose of the other two. Forgive me (and feel free to skim or skip) if I tread ground you've already covered; I'm writing for the beginner here, so I want to make sure all the bases are covered.
HTML
HTML (the HyperText Markup Language) is the absolute foundation on which web pages are built. HTML's job is to describe the structure of the page and the data being presented in it. HTML separates things into sections, including headers, footers, articles, paragraphs, asides, and other such containers. HTML also tells the browser about images, videos, and flash games, which text or picture should be a link to somewhere else in the web, which text should be emphasized or where you're making a strong point. It can contain forms containing various sorts of input devices, and it can tell the browser where to send that form's content when you submit the form. Put another way, it describes the composition of your document, the relationships between sections of your content, and, to some degree, the purpose of certain sections of the document2.
HTML looks something like this:
<html>
<head>
<title>A Sample Web Page</title>
</head>
<body>
<header>
<h1>Sample Code FTW!</h1>
</header>
<main>
<section id="introduction">
<h1>Introduction</h1>
<h2>Where it all begins...</h2>
<p>
This is the first paragraph of the intro.
</p>
<p>This is the second one.</p>
</section>
<section id="picture-show">
<h1>Pictures</h1>
<h2>They're fun!</h2>
<p>Here is a cat:</p>
<img src="https://i.imgur.com/MQHYB.jpg" />
<p>Here are some more (the internet is full of these things):</p>
<img src="https://i.imgur.com/sHQQJG5.gif" />
</section>
</main>
<footer>
<small>© KenB 2015; All rights reserved. (just kidding, do what you want with it)</small>
</footer>
</body>
</html>
Here's a link to see the above in action: http://codepen.io/kenbellows/pen/GZvmVy
As seen if you clicked that link, you can technically make a whole web page with just HTML. The thing is, it's pretty boring. First, it's very plain; this is because HTML contains no formatting information. It has structure, but no layout, color, typeface, border, or any other presentation-related information; that's the job of CSS3. Second, it's entirely static; this is because HTML isn't made to describe dynamic content or behaviors. HTML is intentionally static. If you want anything to move, change, or react to user interaction, if you want to display any dynamic content based on calculations made on the fly, that's where you need JavaScript.
Learn more about HTML here: https://developer.mozilla.org/en-US/Learn/Getting_started_with_the_web/HTML_basics
CSS
CSS (Cascading Style Sheets) solve the formatting problem. If you're writing a static page that just displays the same content every time you load the page and doesn't require any user interaction, like a blog post, you probably only need HTML and CSS.
Here's just a little CSS for that HTML I posted up there:
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
color: #333;
background-color: #ccc;
}
header, main, footer {
margin: 1em auto;
width: 60%;
padding: 1em;
}
header {
text-align: center;
}
header > h1 {
font-size: 4em;
}
main {
background-color: #fff;
}
main h1 {
font-size: 2.5em;
margin-bottom: 0;
}
main h2 {
font-size: 1.5em;
margin-top: 0;
}
And a link: http://codepen.io/kenbellows/pen/wGqewE
See what just a little styling can do for a document?
Learn more about CSS: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Getting_started
JavaScript
JavaScript is what powers all the dynamic parts of a web page4. This is the most important section for the chart stuff you were talking about. JavaScript, unlike HTML and CSS, is a real, proper programming language, Turing-complete and everything, with all the usual branching, looping, function, and object oriented constructs you would expect from a modern language. Because of this, it's a lot more complex than either HTML or CSS, and it can take as long to master as any other full-fledged programming language.
Learn more about JavaScript here: https://developer.mozilla.org/en-US/Learn/Getting_started_with_the_web/JavaScript_basics
Frameworks
Like any other modern language, JavaScript has plenty of libraries and frameworks written for it to help you handle a lot of the messier, boilerplatier parts of writing a web application. Angular.js, the one you mentioned, is a particularly popular framework at the moment, but you should know that it's only one of many, many frameworks. Don't get me wrong, though, it's a good one. But here's something to keep in mind: if you're just starting out with JavaScript as a language, it might not be the best idea to jump head first into a framework. For one, you're just compounding the amount of knowledge you'll need to get up and running; for another, and this is very important, you should probably learn the language in its own right before you start with a framework, to avoid becoming dependent on that framework. I've known a few too many developers who started with Angular right away, then a year later didn't have a solid grasp of why the code was behaving the way it was because they didn't take the time to get a firm understanding of the language fundamentals. Angular is wonderful, I use it all the time, but again, do yourself a favor and at least go through the MDN tutorial on JavaScript I linked above and try writing a couple toy applications before jumping into Angular.
A thought on your app idea
I actually think that for the purposes of your application, you don't need the server at all, other than for hosting it if you decide to publish it on the web or on your company's intranet or something. I'll talk about the server briefly below to answer your questions, but really, if all you need is to take in some user data and show it in real-time as a chart, you can do that with just some JavaScript. Angular would definitely be helpful since you sound like you want real-time updating charts. There are a few Angular-based chart/graph libraries out there that you should look into, e.g. https://jtblin.github.io/angular-chart.js/
The Server
Generally, the server handles data processing and storage. Instead of going into theory like I did for the client, let me answer your questions directly:
Tomcat and Apache - Tomcat and the Apache HTTP Server are two options for web servers. (These guys fit the second definition of "server" I gave above.) They are definitely popular choices, though Apache tends to be more popular for production servers, and Tomcat for development setups (in my experience; people argue about this all the time).
Spring - Spring, including all its various modules and tooling (SpringMVC, Spring Security, Spring Tool Suite, etc), is a Java framework to help you write your server code (server definition #1). In my personal opinion (worth what you're paying for it), Spring is great for large, complex applications with lots of moving parts, but is unnecessarily complicated for a simple app like the one you described.
MySQL - MySQL, like all flavors of SQL, is a database program. It stores data in tables and provides an interface for you to query that data in all sorts of convenient ways. Databases are great, and MySQL is a popular choice, but it's important to figure out whether you need a database for your project. Are you planning to store the data entered by the user for later use? If not, skip the database.
Other languages - Web server code can be written in any language you can run on the command line. If you like Java and you're good at it, stick with Java. If you want to be adventurous, maybe look into Node.js, a JavaScript server solution; you're learning JavaScript anyway, right? It's all about personal preference and what will get the job done for you. No need to learn PHP (and definitely no need to learn C, good god; please don't write your server code in C) just to write the backend for a simple app like the one you've got. Sounds like you're already learning a lot for this project; no need to add more to your plate.
1. (Might be best to read this footnote again after you're done with everything above.) One notable exception that's becoming more popular is the use of JavaScript on the server-side using Node.js. If you try JavaScript on the client-side and fall in love (like many of us do), maybe give Node a shot.
2. Read up on semantic markup once you've got the basics of how HTML works.
3. To be slightly more accurate, HTML shouldn't contain any of this information, although it technically can contain some of it. This is a holdover from the pre-CSS days of the late-90s/early-2000s, when a lot of sizing, font, and color information was stored in the markup. Please, do yourself a favor: leave formatting to CSS.
4. With the exception of some more advanced CSS rules you can use to get pretty basic hover-effects and simple animation. JavaScript is still necessary for anything involving calculations, iteration, logic, basically anything non-trivial.

Answer 2

What you are building is generally called a "full-stack" web application.
Apache alongside Tomcat is used for transferring data between the front and back ends of the application. Specifically, Tomcat is where your Java code will live in the form of Servlets and JSPs (Java Server Pages). Java (like PHP) is only found on the back-end, and is used for "gluing" together the webpages. The back-end is responsible for connecting & talking with the database (MySQL) for storing data as well as moving data from one place to another.
Your front-end is all the HTML, CSS, and JavaScript of the application. It sends HTTP requests to the back-end in order to send/receive data to/from the back-end. Usually, you only need to reference the back-end when a user submits a form or needs to load more information (using AJAX) or even just a whole new page.
AngularJS is a special creature. It IS JavaScript, so it lives on the front-end and does front-end type things, but (other than communicating with the database) it pretty much replaces the back-end in modern web applications. AngularJS is a tool for creating a "single-page application". Which means that when you would normally be requesting new pages from the back-end, instead you would be requesting modifications of the current page.