Answer
"JavaScript Promises
One of the keys to effectively working with asynchronous events in JavaScript is understanding that the program continues execution even when it doesn’t have the value it needs for work that is in progress. Dealing with as yet unknown values from unfinished work can make working with asynchronous events in JavaScript challenging — especially when you’re first getting started.
 
Promise (as it is called in JavaScript) or Future is a concept of handling asynchronous calls in an easy synchronous way. It is a proxy for a value that is not available now but in somewhere in future.
 
A good hint when to use Promises is a massive asynchronous application with many nested callback chains.
 
In short:
 
a promise represents a value that is not yet known
a deferred represents work that is not yet finished
Considered from a high level, promises in JavaScript give us the ability to write asynchronous code in a parallel manner to synchronous code. 
 
Dependency Injection
Any nontrivial application is made up of two or more classes that collaborate with each other to perform some business logic. Traditionally, each object is responsible for obtaining its own references to the objects it collaborates with (its dependencies). When applying DI, the objects are given their dependencies at creation time by some external entity that coordinates each object in the system. In other words, dependencies are injected into objects
 
 
3-tier architecture
A special type of client/server architecture consisting of three well-defined and separate processes, each running on a different platform:
1. The user interface, which runs on the user's computer (the client).
2. The functional modules that actually process data. This middle tier runs on a server and is often called the application server.
3. A database management system (DBMS) that stores the data required by the middle tier. This tier runs on a second server called the database server.
The three-tier design has many advantages over traditional two-tier or single-tier designs, the chief ones being:
The added modularity makes it easier to modify or replace one tier without affecting the other tiers.
Separating the application functions from the database functions makes it easier to implement load balancing.
 
Technical Debt
 
Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
 
The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.
 
 
Closures
A  Closure is like a code block or a method pointer. It is a piece of code that is defined and then executed at a later point. It has some special properties like implicit variables, support for currying and support for free variables (which we'll see later on). We'll ignore the nitty gritty details for now (see the formal definition if you want those) and look at some simple examples.
A closure in Groovy is an anonymous chunk of code that may take arguments, return a value, and reference and use variables declared in its surrounding scope. In many ways it resembles anonymous inner classes in Java, and closures are often used in Groovy in the same way that Java developers use anonymous inner classes. However, Groovy closures are much more powerful than anonymous inner classes, and far more convenient to specify and use."