Explanation of Web Development Modules

Front End

You've got basically anything you want, nowadays this is usually web, hybridish or native mobile (can also be a desktop GUI application).

The common languages are Angular, Ember, React, Aurelia, Boostrap, and whatever else. These are called front end frameworks. They are written in Javascript which is basically what makes dynamic things happen on HTML (otherwise static) web pages, and CSS is used for styling.

HTML provides the core elements like buttons, input boxes, etc. and JavaScript and CSS let you style them to make them look pretty. JS also makes everything dynamic. You know.. if you hover over a name on facebook and it shows you info on that person? That's JS at work. You can actually view this on any page by right clicking and hitting "Inspect Element" or something like that.

You can view the raw HTML framework of every page by hitting Ctrl+U or right clicking and hitting View Source.

For styling, you've got like SASS and LESS for that (look up those + CSS for more info), along with others. Bootstrap also does a lot of this stuff for you and looks dope. Check it out.

If this is going on a phone, it can also be done with something like React Native, which has the benefit of working on both iOS and Android without additional development needed. Ionic is similar.

These sorts of things just use JS, often with one of the frameworks I just mentioned for the code.

Beyond that you have standard native mobile development languages like Swift (nice) and Objective-C (a pain) for iOS, and Android Java (good) for Android.

Native apps are installed locally onto the phone. You can use them offline. They may access online resources, but the app is fully offline. Also they are not coded in a web language.

Hybrid apps are generally kind of half and half. They have a native dock if you will, but they are written in web languages (even if you can access some data offline), and generally sync with the web regularly.

Web apps are only viewed through a browser without a native "dock" so to speak.

Native apps can take full advantage of all the phone's hardware. Hybrid apps can take some advantage of this, and web apps are limited to what the browser can provide.

Data Transport

All of the info you need comes up from the back end through a data transport layer. This can be anything, but typically it's done through a REST API.

They look like this:

yourdomain.com/api/credentials/get

yourdomain.com/api/credentials/set

You can do this however you like. You don't need the fancy standards. Often this is done using POST, but if you need to pass a lot of data all the time, you're better off opening a socket. (Look all this shit up for more info if you want it).

Random side note: sockets + JSON + Node.js makes a decent back end server for gaming.

JSON is an object notation. Looks like this:

{"propertya":5, "propertyb":"value"}

A bit more complex than that, but not much more. You use that to pass info back and forth like if the front end needs someone's first and last name, you might hit a back end REST API called yourdomain.com/api/names/get and it might return something like this to the front end which you can use:

{"first_name":"Carlos", "last_name":"La Borde"}

XML isn't much different, though nicer for viewing out of the box IMO. It's a bit heavier:

<xml ..../>
<firstname>Carlos</firstname>
<lastname>La Borde</lastname>
</xml>

Because it's a bit heavier, it's fallen a bit out of fashion, but it still gets the job done effectively. K... now the back end.

Back End

A lot is made of web languages, but truth is, you can use whatever you like. I have some back end systems hooked up to REXX (ancient IBM language) and they run like a charm.

The standard ones you'll hear a lot about nowadays are PHP, Ruby (+on Rails), Python, and Node.js.

All of them are good except PHP which is still good in smaller projects and for newbies, but IMO teaches you bad habits and has some serious flaws. I'm not saying you can't use it, just read up and consider your use cases before you invest a lot of time in it. A lot of people get bogged down with PHP because it's easy and don't want to change.

IMO Ruby, Python, and Node work brilliantly with REST out of the box, and Node works brilliantly with JSON, because.. well, it's JS.

You're not limited to those. Java and C# also work reasonably well in the back end, though they're a bit heavier. Personally I'd hold off using them unless it was for a big enterprise thing.

Also.. like I said technically you can use any language (C++ works too). Hell, you can literally use goddamn Assembly (I know of a guy who does).

DB Transport Layer

To get at stuff in the back end.. You need a way to connect your web language to a DB. For some languages and DBs, this is a piece of cake.

With Node and MySQL or mongo you just use npm to install a package, include it and you're good to go.

For some other languages, like Java or DB2, it becomes a bit of a pain. You may have to use something like ODBC or JDBC (which you install on your server and pick your DB). The details of those of the scope of this answer, but they are out there and those are what to look for if you're stuck trying to connect a DB to your language.

Databases

OK now onto the databases themselves. There are a shitload of pros and cons and best practices for different use cases. This is kind of important, so do the research given what you're trying to do.

The standard ones are SQL. This stands for Structured Query Language. Basically that means in your language you create a string called a query and run it against this database and it returns what you asked for. This is in a semi English language.

Here's a sample query:

SELECT * FROM users WHERE email_address='[email protected]'

The * means "all" in this context.

There's a lot more to it than that, but you can do a lot only knowing a little.

Basically all of these suckers are structured like tables with columns. So users in this context is a table, and email_address is a column. The SELECT * piece will select an entire row of data where the email_address matches.

The rest of that row might look like:

first_name | last_name | email_address
"Carlos" | "La Borde" | "[email protected]"

See what I'm saying? There could be a hundred rows with different data, but the select grabs just this one with this column.

Think of it like slicing and dicing an Excel sheet. That's almost exactly what it is.

Now.... You also have NoSQL DBs. These have made a big splash in the past few years. Personally I think people often pick them blindly because they're new rather than logically assessing if they would benefit their use case.

Anyways... these include popular names like MongoDB and Redis.

Mongo is popular because it's part of the MEAN stack. M = Mongo, E = Express (couples well with Node), A = Angular (a JS front end framework we mentioned earlier), and N = Node.

I will say that NoSQL DBs are good for holding onto data that comes in chunks. Like (social media) post data, for instance. They are easy to scale and shard nicely in ways that SQL DBs really struggle with, and they can be wicked fast and kicking back an entire object (Mongo plays nice with Node and Angular because these objects are all JSON).

That said, they are shitty if you need to join or perform similar complex data operations (e.g. getting totals would be a bit of a pain, but trivial in SQL).

If you're on Bluemix, Cloudant is a good choice of NoSQL DB that I love using (when the use cases are right).

I mentioned Redis, so I'll chat a bit about that. It's not just NoSQL, it's called a key store or a key value database, which means you just send in pairs of data. It's wicked fast and relies on in-memory caching.

There are also queue DB structures that I didn't mention here (like Rabbit/MQ). These are good for temporarily holding onto a lot of data you need to parse very quickly. Redis is often used to enable these.