Oauth-2 and OpenId Connect

OAuth 2.0 is a authorization framework where a user of a service can allow a third-party application to access his/her data hosted in the service without revealing his/her credentials (ID & password) to the application. OAuth 2.0 is a set of defined process flows for “delegated authorization”.

OpenID Connect is a framework on top of OAuth 2.0 where a third-party application can obtain a user’s identity information which is managed by a service.  OpenID Connect  standardizes the flow for person authentication using OAuth2. OpenId Connect is a set of defined process flows for “federated authentication”.

OAuth 2.0 Terminology:

Resource Owner:


Resource Server:

Authorization Server:



Key Terms and Concepts in Scalability


Performance tuning.- This step would consist of refactoring a web application’s source code, analyzing a web application’s configuration settings, attempting to further parallelize a web application’s logic, implementing caching strategies, detecting hot spots and another series of often invasive — code wise that is — procedures throughout a web application’s tiers. These topics will be detailed as the book progresses.

Vertical Scaling: In scaling terminology, this implies that a box or node on which a web application is running can be upwardly equipped with more CPU, Memory, Bandwidth or I/O capacity. Thus if a web application encounters a greater demand for any of these resources, and you are able to move a web application or one of its tiers to a box or node with greater capacity, you will have vertically scaled an application.

Horizontal Scaling: Horizontal scaling refers to assigning resources on a lateral basis. In scaling terminology, this implies that the node on which a web application is running cannot be equipped with more CPU, Memory, Bandwidth, or I/O capacity and thus a web application is split to run on multiple boxes or nodes.
The process of horizontally scaling a web application is more elaborate than that of vertically scaling. The reason is that by relying on horizontal scaling, you need to devise a way to decouple a web application. The simplest way to decouple a web application is by means of its tiers. Recapping from the previous paragraphs, these tiers would be:

Static content tier.- Consists of static images or other resources that make up an application’s interface and don’t need processing. In most web applications this would be JPEG/GIF images, Javascript libraries, Cascading style sheets or pre-built HTML pages.
Business logic tier.- Consists of a web framework for processing data provided by users or stored in the permanent storage tier. Depending on your preferences, this could be Ruby on Rails, PHP Cake, Django, Grails(Java) or MonoRail(.NET) among many others.
Permanent storage tier.- Consists of a permanent storage location for data. In most web applications this is a relational database system(RDBMS).

What are B-Trees


a B-tree is a self-balancing tree data structure that keeps data sorted and allows searches, sequential access, insertions, and deletions in logarithmic time. The B-tree is a generalization of a binary search tree in that a node can have more than two children (Comer 1979, p. 123). Unlike self-balancing binary search trees, the B-tree is optimized for systems that read and write large blocks of data. B-trees are a good example of a data structure for external memory. It is commonly used in databases and filesystems.

All terminal nodes are the same distance from the base

Features of Object Oriented Programming

Encapsulation is a mechanism by which you restrict the access to some of the object’s components, as well as binding the data and methods operating on the data. Encapsulation is a way to obtain ‘information hiding’.

Abstraction is the process of moving from a specific idea to a more general one. For example take your mouse. “Silver Logitech MX518” is a concrete, specific item, and “mouse” is an abstraction of that.


Displaying multiple behavior. Achieved via virtual functions, operator overloading, function overloading, etc

Virtual Function: Without “virtual” you get “early binding”. Which implementation of the method is used gets decided at compile time based on the type of the pointer that you call through. With “virtual” you get “late binding”.

Virtual Constructor:

Stack vs Heap

The Stack

What is the stack? It’s a special region of your computer’s memory that stores temporary variables created by each function (including the main() function). The stack is a “LIFO” (last in, first out) data structure, that is managed and optimized by the CPU quite closely. Every time a function declares a new variable, it is “pushed” onto the stack. Then every time a function exits, all of the variables pushed onto the stack by that function, are freed (that is to say, they are deleted). Once a stack variable is freed, that region of memory becomes available for other stack variables.

The advantage of using the stack to store variables, is that memory is managed for you. You don’t have to allocate memory by hand, or free it once you don’t need it any more. What’s more, because the CPU organizes stack memory so efficiently, reading from and writing to stack variables is very fast.

A key to understanding the stack is the notion that when a function exits, all of its variables are popped off of the stack (and hence lost forever). Thus stack variables are local in nature. This is related to a concept we saw earlier known as variable scope, or local vs global variables. A common bug in C programming is attempting to access a variable that was created on the stack inside some function, from a place in your program outside of that function (i.e. after that function has exited).

Another feature of the stack to keep in mind, is that there is a limit (varies with OS) on the size of variables that can be stored on the stack. This is not the case for variables allocated on the heap.

To summarize the stack:

  • the stack grows and shrinks as functions push and pop local variables
  • there is no need to manage the memory yourself, variables are allocated and freed automatically
  • the stack has size limits
  • stack variables only exist while the function that created them, is running

The Heap

The heap is a region of your computer’s memory that is not managed automatically for you, and is not as tightly managed by the CPU. It is a more free-floating region of memory (and is larger). To allocate memory on the heap, you must use malloc() or calloc(), which are built-in C functions. Once you have allocated memory on the heap, you are responsible for using free() to deallocate that memory once you don’t need it any more. If you fail to do this, your program will have what is known as a memory leak. That is, memory on the heap will still be set aside (and won’t be available to other processes). As we will see in the debugging section, there is a tool called valgrind that can help you detect memory leaks.

Unlike the stack, the heap does not have size restrictions on variable size (apart from the obvious physical limitations of your computer). Heap memory is slightly slower to be read from and written to, because one has to use pointers to access memory on the heap. We will talk about pointers shortly.

Unlike the stack, variables created on the heap are accessible by any function, anywhere in your program. Heap variables are essentially global in scope.

Stack vs Heap Pros and Cons


  • very fast access
  • don’t have to explicitly de-allocate variables
  • space is managed efficiently by CPU, memory will not become fragmented
  • local variables only
  • limit on stack size (OS-dependent)
  • variables cannot be resized


  • variables can be accessed globally
  • no limit on memory size
  • (relatively) slower access
  • no guaranteed efficient use of space, memory may become fragmented over time as blocks of memory are allocated, then freed
  • you must manage memory (you’re in charge of allocating and freeing variables)
  • variables can be resized using realloc()

In a multi-threaded situation each thread will have its own completely independent stack but they will share the heap.


Functional vs Procedural vs Object Oriented Programming

In a purely procedural style, data tends to be highly decoupled from the functions that operate on it. Procedural is a type of imperative programming style. An imperative language uses a sequence of statements to determine how to reach a certain goal. These statements are said to change the state of the program as each one is executed in turn.

In an object oriented style, data tends to carry with it a collection of functions.

Functional programming (often abbreviated FP) is the process of building software by composing pure functions, avoiding shared state, mutable data, and side-effects. A function is called ‘pure’ if all its inputs are declared as inputs – none of them are hidden – and likewise all its outputs are declared as outputs. Functional programming is about writing pure functions, about removing hidden inputs and outputs as far as we can, so that as much of our code as possible just describes a relationship between inputs and outputs. Let’s not hide what a piece of code needs, nor what results it will yield. If a piece of code needs something to run correctly, let it say so. If it does something useful, let it declare it as an output. When we do this, our code will be clearer. Complexity will come to the surface, where we can break it down and deal with it.

Explain FLUX

Flux is an architectural pattern that enforces unidirectional data flow.

MVC vs Flux:
MVC did not scale well for Facebook’s huge codebase. The main problem for them was the bidirectional communication, where one change can loop back and have cascading effects across the codebase (making things very complicated to debug and understand).

How does Flux solve this? By forcing an unidirectional flow of data between a system’s components.
In general the flow inside the MVC pattern is not well defined. A lot of the bigger implementations do it very differently (e.g. Cocoa MVC vs. Ruby on Rails MVC).
Flux on the other hand is all about controlling the flow inside the app?—?and making it as simple to understand as possible.

Action –> Dispatcher –> Store –> View

Facebook found that two-way data bindings led to cascading updates, where changing one object led to another object changing, which could also trigger more updates. As applications grew, these cascading updates made it very difficult to predict what would change as the result of one user interaction. When updates can only change data within a single round, the system as a whole becomes more predictable.