Those are many topics, and you could spend years digging into them, you’ll need to find a balance between going too deep and knowning enough to keep moving.

I totally understand your inquietude. When I started doing web in 2000 the company I was working for used the Java abstraction for web development. Since everything was accessible as abstraccions, (GET/POST, sessions, etc.), I had the feeling of not understanding what was going on. In my case, the solution was to study CGI with Perl. There, you are naked, you are forced to get familiar with the basics.

TCP is the more low level of the set. When a user connects to your service a ton of things happen in between. One possible resource there is “Computer Networds and Internets”, by Douglas E. Comer. Spend a couple of months reading that book from cover to cover, and you’ll be a different developer.

The next level is HTTP, that is text that travels in the communication channel established with TCP, and that both parts speak to understand each other. A protocol. Version 2 of HTTP is not plain text, but I recommend you to understand 1.1 first. For that, and to understand REST too, “RESTful Web Services”, by Leonard Richardson & Sam Ruby, is an excellent resource.

AJAX allows JavaScript in the browser to do HTTP calls to the server the same way you can do HTTP calls with Elixir or any other programming language (or curl, wget, etc., any client). I read some books on AJAX in the past, but this is not a huge topic, any book or online tutorial will do.

MVC is a design pattern. For that one I recommend getting just the idea, and to be exposed to some concrete implementations. Because you can be lost in theoretical design discussions that will have little practical interest for what you are looking for now.

Basically, it means that you think about your application as a software system where things fall very broadly into one of three categories: C is a layer that acts as a broker so to speak, it connects the external world with the M and V layers. The M layer is the one who knows what to do (create a user, retrieve the movies of category “Comedy”, etc., which is called in jargon the business logic), and encapsulates that, so the C layer is able to execute it without knowing too much. The V layer knows how to present the information in the response back to the client. So, the request arrives to C, which invokes some API from M, and then prepares information for V. Done.

Having that idea in mind, and learning Phoenix, is enough. You’ll recognize the parts. The rules are soft, guidelines that help you organize mentally the code, and that normally also translate to the actual directory structure or file names.

Regarding the workflow, basically when a request arrives, eventually the router decides which function of which controller should be invoked to handle it. The function gets invoked, its implementation talks to the model layer, sets up info for the view, the view is rendered.

If you read “Programming Phoenix” you’ll understand how these pieces connect.

As I said at the beginning, you could spend years getting deep into these topics. Books are the best resource, but don’t get paralized if you don’t know everything. You won’t, you’ll need to find a sweet spot in which you keep going while in parallel studying. That’s a feeling and attitude that never ends, it’s for a lifetime :).

If you have a look at the MVC Family Tree (MVC past, present and future, MVC: misunderstood for 37 years) it should become clear why it’s clear as mud - what it actually means depends entirely on context.

For example in the context of Phoenix with EEx templates you are dealing with Server MVC. Meanwhile those EEx templates can contain JavaScript and depending on what that code is doing there also could be some Client MVC going on.

In Server MVC you are usually dealing with PageControllers that, based on the contents of the HTTP request, fetch the necessary information from the model in order to “fill in the blanks” on a Template View. The template is then rendered on the server with the information and the rendered page is sent back in the HTTP response.

Often a “server page” is implemented by a specific PageController/Template pair. There is usually also a Front Controller that processes all the HTTP requests coming to the server - in Phoenix that’s the Router.

I think my first exposure to Server MVC was through ASP.NET and it wasn’t pretty. Staring at the page source was a bit overwhelming: HTML, CSS, JavaScript, template markup, C# code all interlaced into one big mess. It was very easy to get disoriented as the server-side template markup disrupted the HTML flow - and you needed to keep a firm grasp on how that server-side template markup would be transformed into HTML.

I found that it was necessary to learn to mentally “zoom in” separately on either the server-side aspects or the client-side aspects of the page - while still paying attention to what is happening on the boundary between the two. In a way you need to be able see the various technology layers inside the template source - but this also requires some basic understanding of each of the technologies involved (and working with it).

1. HTML - source code that tells the browser what to put on the page. The markup adds some structure and context to the text (what any particular text is about). HTML carries the content. This technology can be explored with just a browser and a text editor.

2. CSS - directives that determine how the HTML content is presented. Now it’s popular “to simply use Boostrap” but the Bootstrap documentation does expect you to know how CSS works. This technology can be explored with just a browser and a text editor.

3. ECMAScript - at this point you have to realize that HTML is only a textual representation of the page content. The browser transforms the HTML into a DOM tree. ECMAScript can interact with that DOM tree and even change it. The DOM also adds an event system to the page. Now rather than the page just being a wall of pretty text, with the help of ECMAScript the page can actually change in the browser. Lots of ECMAScript can be explored with just a browser and a text editor.

HTTP

Now rather than your browser reading the page from a file on your local file system it can GET it from an HTTP server. And that is exactly how a static web site works.

However now the browser is decoupled from the actual page that is being served - because the browser has to go through the server, there doesn’t have to be a complete page on server’s file system, the server can just generate the page as needed. So now you can have a template that captures the parts of the page that don’t change and combine it with information that will change and serve an up to date version of the page to the browser.

HTTP also supports the sending of form data in a request - that allows a page in the browser to get information to the server (even without ECMAScript). So the browser can now receive information via a page and send information via form data. The server can use that form data to make changes to server side information.

Server MVC is a way to structure dealing with the HTTP requests for pages (or incoming form data) and generating the appropriate HTTP (page) responses.

AJAX

AJAX introduced the idea of not just serving whole pages but page fragments or other data. This only became possible when browsers started to have the capability to issue HTTP requests that were separate from the page loading cycle (then XMLHttpRequest, now fetch). With the help of JavaScript the fetched information could be used to alter the content of the page. It’s during this time that jQuery became popular as it abstracted away various browser implementation differences (including jQuery.ajax) and simplified various page modification and event handling tasks.

REST

AJAX was pretty much the “Wild West” and while it kind of worked it often used HTTP in a way that didn’t respect the intent behind the HTTP protocol and specification. In 2000 Roy Fielding formalized an architecture based on “Representational State Transfer” which embraced the way HTTP works. While AJAX was often just RPC in disguise, REST respected the constraints that the Web was based on and worked well within those constraints (i.e. it was more “webby” than RPC (RPC controversy)).

REST is (RESTful Web Services, p.105):

It’s just four concepts:

1. Resources
2. Their names (URIs)
3. Their representations
4. The links between them

and four properties

1. Addressability
2. Statelessness
3. Connectedness
4. A uniform interface

• Resources (p.81): If it’s important enough to be referenced “by itself” then it should be a resource with its own unique name/identity.
• Addressability (p.84): Resources have to be referenced somehow. In the case of the Web the resource’s URI (p.81) becomes its URL.
• Representations (p.91): Often the actual “resource” cannot be manipulated directly. So instead the resource is manipulated through one of it’s “Representations”. The resource representation can be simultaneously published in multiple formats like XHTML, XML, JSON or any other IANA MIME media type. However a strong preference is given to media types that support another REST property - connectedness; the representation format should allow for standardized links to other resources. In the case of the Web you want to the format to expose URIs in a standard way (e.g. HTML’s anchor element). To change a resource’s state you retrieve the representation, modify it, and write it back.
• Statelessness (p.86): No server-side application (client) state. The only state that exists on the server is resource state (which is captured in its representation). Application state stays on the client.
• Links and Connectedness (p.94) of resources (hypermedia as the engine of application state - HATEOAS): Any resource can and should link (in it’s representation) to other resources (via the URIs). A RESTful application tends to have one single root resource where each “session” starts. The possible client application state transitions are described as links to other resources inside each resource’s representation. So the navigation from one resource to the next is what is changing (and defining) application/client state.
• Uniform Interface (p.97) exposed by resources: Every resource implements the same Uniform Interface (or at least a significant subset). In the case of the Web, the Uniform interface is defined through the HTTP methods (GET,PUT,DELETE etc.) - one should stick with the safe and idempotent methods whenever possible.

Now there are lots of tools that claim to be RESTful but they really aren’t.
Example: Swagger ain’t REST - is that OK?

All the previous technologies relied on the HTTP/1.1 request/response cycle. But then other technologies like Web Sockets came into play. AJAX also introduced the notion of the page changing in response to server generated events. In the past this often meant that the page had to poll the server periodically with HTTP requests to determine if there were any new server side events (Phoenix.Transports.LongPoll). With web sockets the server can deliver events to the page without having to wait for an HTTP request from the (client) page.

And these days HTTP/2 is slowly being adopted.

@peerreynders , @fxn Thank you all for the explanations ! At least now I understand the basics. The mistake beginners like me do is trying to understand everything quickly and deeply. Now I know that all this needs patience. I will start building and study theory everytime I need more details or I’m stuck.

Specials thanks to @peerreynders who is very reactive to my questions on this Forum.