Angular 11 Features

Angular 11 was released on Nov 11, 2020. Angular, Google’s JavaScript (TypeScript) framework for building web applications mobile or desktop. Highlights include stricter types, router performance improvements, and automatic inlining of fonts.

Other improvements in Angular 11 include:

• Performance improvements and new APIs, with the parallel function making it easier to work with asynchronous actions in tests by enabling multiple asynchronous interactions with components in parallel.
• Stricter types are added for DatePipe and number pipes, to catch misuses such as passing an Observable or an array.
• Improved reporting and logging.
• An update to the Angular Language Service, providing a more powerful and more accurate experience.
• An update to Hot Module Replacement (HMR) support leverages the CLI to allow enablement of HMR when starting an application with ng serve.
• Experimental Webpack 5 support offers a path to faster builds with persistent disk caching and smaller bundles thanks to CommonJS tree-shaking.
• TSLint has been deprecated, with project creators recommending migration to ESLint.
• For the Angular compiler, keySpan would be added to the Variable node.
• The router in Angular 11 would change the default value of relativeLinkResolution from “legacy” to “corrected.” The migration updates RouterModule configurations that use the default value to now specifically use “legacy” to prevent breakages during updating.
• In a fix to the core, a Trusted Types policy is being introduced in the development mode. It allows arbitrary unsafe conversions to Trusted Types to support development features. Also, a module is being added to create a Trusted Types policy for use internally by Angular.
• New initialNavigation options are being added to legacy functionality.
• For code refactoring in the router, the type of parameter in navigateByUrl and createUrlTree is being adjusted to be more accurate.
• To improve router performance, ngDevMode can be used to tree-shake error messages.
• For service-worker, an UnrecoverableStateError notification is being added, fixing an issue in which a broken state would arise where only parts of an application would load properly. This situation has arisen when the browser has evicted eagerly cached assets from the cache that cannot be found on the server anymore.
• Support is removed for the Microsoft IE 9 and IE 10 browsers as is IE mobile support.
• ISO week-numbering year formats support is being added to formatDate.
• For the compiler-cli, interfaces are being defined that can be used for TemplateTypeChecker. Performance improvements have been made to compiler-cli, also.
• For the core, a migration is being added that finds all imports and calls to the deprecated async function @angular/core/testing and replaces them with waitforasync.
• null is now included in the types of .parent.
• A multitude of bug fixes are planned, including an improvement to typing of common pipes and another fix to ensure TestBed is not instantiated before the override provder.
• TypeScript 3.9 support has been removed from the compiler. An upgrade to TypeScript 4.0 is advised.

JWT : JSON Web Token

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA.
For example, a server could generate a token that has the claim "logged in as admin" and provide that to a client. The client could then use that token to prove that it is logged in as admin. The tokens are signed by the server's key, so the client and server are both able to verify that the token is legitimate. The tokens are designed to be compact, URL-safe and usable especially in web browser single sign-on (SSO) context. JWT claims can be typically used to pass identity of authenticated users between an identity provider and a service provider, or any other type of claims as required by business processes. The tokens can also be authenticated and encrypted.

Some concepts of this definition:
Compact: Because of their smaller size, JWTs can be sent through a URL, POST parameter, or inside an HTTP header. Additionally, the smaller size means transmission is fast.
Self-contained: The payload contains all the required information about the user, avoiding the need to query the database more than once.

JSON Web Token structure:
JSON Web Tokens consist of three parts separated by dots (.), which are:

• Header - identifies which algorithm is used to generate the signature
• Payload - contains the claims to make
• Signature - calculated by base64url encoding the header and payload and concatenating them with a period as a separator

To put it all together, the signature is base64url encoded. The three separate parts are concatenated using periods:

token = encodeBase64Url(header) + '.' + encodeBase64Url(payload) + '.' + encodeBase64Url(signature) 
# token is now: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI 

Some scenarios where JSON Web Tokens are useful:
Authentication: This is the most common scenario for using JWT. Once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token. Single Sign On is a feature that widely uses JWT nowadays, because of its small overhead and its ability to be easily used across different domains.
Information Exchange: JSON Web Tokens are a good way of securely transmitting information between parties. Because JWTs can be signed—for example, using public/private key pairs—you can be sure the senders are who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn't been tampered with.

OpenAPI Specification : Swagger

The OpenAPI Specification (originally known as the Swagger Specification) is a specification for machine-readable interface files for describing, producing, consuming, and visualizing RESTful Web services. A variety of tools can generate code, documentation and test cases given an interface file. Development of the OpenAPI Specification (OAS) is overseen by the Open API Initiative, an open source collaborative project of the Linux Foundation.

Swagger is a project used to describe and document RESTful APIs. The Swagger specification defines a set of files required to describe such an API. These files can then be used by the Swagger-UI project to display the API and Swagger-Codegen to generate clients in various languages. Additional utilities can also take advantage of the resulting files, such as testing tools.

Applications implemented based on OpenAPI interface files can automatically generate documentation of methods, parameters and models. This helps keep the documentation, client libraries, and source code in sync.

Features:

• The OpenAPI Specification is language-agnostic. It is also extensible into new technologies and protocols beyond HTTP.
• With Swagger's declarative resource specification, clients can understand and consume services without knowledge of server implementation or access to the server code.
• The Swagger UI framework allows both developers and non-developers to interact with the API in a sandbox UI that gives clear insight into how the API responds to parameters and options. Swagger may utilize both JSON and XML.
• Swagger-Codegen contains a template-driven engine to generate documentation, API clients and server stubs in different languages by parsing the OpenAPI/Swagger definition.

How to start:

If you're an API provider and want to use Swagger to describe your APIs - there are several approaches available:

• A top-down approach where you would use the Swagger Editor to create your Swagger definition and then use the integrated Swagger Codegen tools to generate server implementation.
• A bottom-up approach where you have an existing REST API for which you want to create a Swagger definition. Either you create the definition manually (using the same Swagger Editor mentioned above), or if you are using one of the supported frameworks (JAX-RS, node.js, etc), you can get the Swagger definition generated automatically for you. If you're doing JAX-RS have a look at the example at https://github.com/swagger-api/swagger-core/wiki/Swagger-Core-JAX-RS-Project-Setup-1.5.X.

If on the other hand you're an API Consumer who wants to integrate with an API that has a Swagger definition you can use the online version of the Swagger UI to explore the API (given that you have a URL to the APIs Swagger definition) - and then use Swagger Codegen to generate the client library of your choice.

Representational state transfer (REST)

Roy Fielding generalized the Web’s architectural principles and presented them as a framework of constraints, or an architectural style in his Ph.D. dissertation. Through this framework, Fielding described how distributed information systems such as the Web are built and operated. He described the interplay between resources, and the role of unique identifiers in such systems. He also talked about using a limited set of operations with uniform semantics to build a ubiquitous infrastructure that can support any type of application. Fielding referred to this architectural style as REpresentational State Transfer, or REST. REST describes the Web as a distributed hypermedia application whose linked resources communicate by exchanging representations of resource state.

Representational state transfer (REST) is an abstraction of the architecture of the World Wide Web; more precisely, REST is an architectural style consisting of a coordinated set of architectural constraints applied to components, connectors, and data elements, within a distributed hypermedia system. REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements.

Hypermedia

The description of the Web, as captured in W3C’s “Architecture of the World Wide Web” and other IETF RFC documents, was heavily influenced by Fielding’s work. The architectural abstractions and constraints he established led to the introduction of hypermedia as the engine of application state.

The idea is simple, and yet very powerful. A distributed application makes forward progress by transitioning from one state to another, just like a state machine. The difference from traditional state machines, however, is that the possible states and the transitions between them are not known in advance. Instead, as the application reaches a new state, the next possible transitions are discovered.

In a hypermedia system, application states are communicated through representations of uniquely identifiable resources. The identifiers of the states to which the application can transition are embedded in the representation of the current state in the form of links.

Example of hypermedia as the engine for application state in action

REST - An Architectural Style, Not a Standard ,while REST is not a standard, it does use following standards:

• HTTP
• URL
• XML/HTML/GIF/JPEG/etc (Resource Representations)
• text/xml, text/html, image/gif, image/jpeg, etc (MIME Types)

Principles of REST Web Service Design

1. The key to creating Web Services in a REST network (i.e., the Web) is to identify all of the conceptual entities that you wish to expose as services.
2. Create a URL to each resource. The resources should be nouns, not verbs. For example, do not use this:
           http://www.parts-depot.com/parts/getPart?id=00345
       Note the verb, getPart. Instead, use a noun:
           http://www.parts-depot.com/parts/00345
   
3. Categorize your resources according to whether clients can just receive a representation of the resource, or whether clients can modify (add to) the resource. For the former, make those resources accessible using an HTTP GET. For the later, make those resources accessible using HTTP POST, PUT, and/or DELETE.
4. All resources accessible via HTTP GET should be side-effect free. That is, the resource should just return a representation of the resource. Invoking the resource should not result in modifying the resource.
   
5. No man/woman is an island. Likewise, no representation should be an island. In other words, put hyperlinks within resource representations to enable clients to drill down for more information, and/or to obtain related information.
6. Design to reveal data gradually. Don't reveal everything in a single response document. Provide hyperlinks to obtain more details.
7. Specify the format of response data using a schema (DTD, W3C Schema, RelaxNG, or Schematron). For those services that require a POST or PUT to it, also provide a schema to specify the format of the response.
8. Describe how your services are to be invoked using either a WSDL document, or simply an HTML document.