Just In Time and Ahead Of Time compilation

  • In JIT compilation, the application compiles inside the browser during runtime.
    Whereas in the AOT compilation, the application compiles during the build time.
  • Done using ng-serve
  • All the ng-if and ng-for etc are compiled when the page is loaded
  • The files downloaded on the browser during JIT is higher because the JIT compiler itself is downloaded into the browser
  • The advantages of using AOT compilation are:
  • Since the application compiles before running inside the browser, the browser loads the executable code and renders the application immediately, which leads to faster rendering.
  • In AOT compilation, the compiler sends the external HTML and CSS files along with the application, eliminating separate AJAX requests for those source files, which leads to fewer ajax requests.
  • Developers can detect and handle errors during the building phase, which helps in minimizing errors.
  • The AOT compiler adds HTML and templates into the JS files before they run inside the browser.
  • Due to this, there are no extra HTML files to be read, which provide better security to the application.
  • Done using ng build –configuration=production

Advantages and Challenges in Angular

Advantages

  • Compilable
  • The component & module based design which allows reusing the code
  • Faster Development Process. (build easy, environment progress)
  • Readable and Testable code
  • Lightweight Web Application. (Lazy Loading, Minified prod files)
  • Ready-made components readily available like Material, Prime NG, Bootstrap etc
  • Can be used with any backend stack by using JSON REST API
  • Can handle complex requirements
  • PWA – Progressive Web Apps
  • Community support
  • LTS Support by Angular

Challenges

  • Takes a lot of time to learn
  • Too many files are created if file count and project structure is not configured properly

What is the meaning of OAuth and How OAuth Works?

Two major flow

  1. Authorizing a third party
  2. Giving them the access token

Authorizing a third party

  1. User logins to tool to access a regular system backup service.
  2. The tool requires access to Google Drive to store the backup.
  3. The tool ask Google Drive to take the User to their page login and authenticate the user
  4. The Google show the list of permission that Backup tool needs.
  5. The User authorizes the backup tool on Google Drive
  6. Google Drive grants a authorization token to the tool
  7. Next time the tool needs to store backup on Google drive it presents the auth token to Google
  8. Google gives the access token to tol

Reference :

HTTP Methods and idempotentency

  • Indempotent Methods – Are those methods which cannot be called repeatedly since they create multiple entries in Database which may cause inconsistencty
  • Safe Methods – Are those methods which is only a ready only operatoin

According to HTTP specification, Indempotent methods should be safe for the client to be called multiple times without worrying or creating multiple entries

So this is the reason PUT (update) request is Idempotent and POST request is non-idempotent, PUT request can be called multiple times without affecting the response while POST cannot do the same

Hence idempotent methods are cache by a web server if called multiple times in a consecutive batch

Browser safe guard the repeated call of post request on a browser refresh. i.e it shows “Do you really want to resubmit the form” because it a non-idempotent request

  • Get – Read Data
  • Post – Create Data
  • Put – Update Data
  • Delete – Delete Data
  • Options – Check what are HTTP methods are allowed by a server we check using OPTIONS
  • Head – Like Get but only returns Header Info and Http Status, no payload in returned
  • Patch – Like PUT but cannot be re-called since the status is changed now in DB (Non Idempotent)

Reference :

Concept of Stateless REST

  • Note if the REST is Stateful then there has to be handshake between two parties which again takes extra steps and can cause a delay in communication.
  • The REST architecture is designed in such a way that the client state is not maintained on the server. This is known as statelessness. The context is provided by the client to the server using which the server processes the client’s request. The session on the server is identified by the session identifier sent by the client.
  • The concept we mostly use is of JWT here, the time until which the JWT is valid is mentioned inside the token itself

HTTP Status Code

What are HTTP Status Codes?

These are the standard codes that refer to the predefined status of the task at the server. Following are the status codes formats available:

  • 1xx – represents informational responses
  • 2xx – represents successful responses
  • 3xx – represents redirects
  • 4xx – represents client errors
  • 5xx – represents server errors

Most commonly used status codes are:

  • 200 – success/OK
  • 201 – CREATED – used in POST or PUT methods.
  • 204 – No Content – Used with Delete method of HTTP
  • 304 – NOT MODIFIED – used in conditional GET requests to reduce the bandwidth use of the network. Here, the body of the response sent should be empty.
  • 400 – BAD REQUEST – This can be due to validation errors or missing input data.
  • 401 – FORBIDDEN – sent when the user does not have access (or is forbidden) to the resource. (Authentication not successful)
  • 403 – Authorization not successfull
  • 404 – NOT FOUND – Resource method is not available.
  • 409 – Conflict
  • 500 – INTERNAL SERVER ERROR – server threw some exceptions while running the method.
  • 502 – BAD GATEWAY – Server was not able to get the response from another upstream server.
  • 503 – Service Unavailable Error – When you dynamically generated a page and that paged reopened after a while