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.

AWS Lambda Layers

Serverless developers frequently import libraries and dependencies into their AWS Lambda functions. While you can zip these dependencies as part of the build and deployment process, in many cases it’s easier to use layers instead. You can configure your Lambda function to pull in additional code and content in the form of layers. A layer is a .zip file archive that contains libraries, a custom runtime, or other dependencies. With layers, you can use libraries in your function without needing to include them in your deployment package. Layers let you keep your deployment package small, which makes development easier. You can avoid errors that can occur when you install and package dependencies with your function code. You can create layers, or use layers that AWS or an AWS customer has published. Layers support resource-based policies for granting layer usage permissions to specific AWS accounts, AWS Organizations, or all accounts.

Layers are extracted to the /opt directory in the function execution environment. Each runtime looks for libraries in a different location under /opt, depending on the language. Structure your layer so that function code can access libraries without additional configuration. You can also use the AWS Serverless Application Model (AWS SAM) to manage layers and your function's layer configuration.

New Year Greetings 2021

AWS CloudShell

AWS CloudShell is a browser-based shell that makes it easy to securely manage, explore, and interact with your AWS resources. CloudShell is pre-authenticated with your console credentials. Common development and operations tools are pre-installed, so no local installation or configuration is required. With CloudShell, you can quickly run scripts with the AWS Command Line Interface (AWS CLI), experiment with AWS service APIs using the AWS SDKs, or use a range of other tools to be productive. You can use CloudShell right from your browser and at no additional cost.

Benefits

No extra credentials to manage
CloudShell inherits the credentials of the user signed in to the AWS Management Console, so there's no need to spend extra effort managing credentials locally.

Always up to date
CloudShell provides a fully managed Amazon Linux 2 environment that has the latest versions of popular tools already installed and updated. You don't need to patch the environment or update the pre-installed tools.

No cost
CloudShell provides you with a browser-based shell to run scripts and commands. It includes 1 GB of persistent storage per Region at no extra cost to you. You only pay for the AWS resources you use with CloudShell to create and run your applications.

Customizable
With 1 GB of persistent storage per Region, you can store scripts, files, configuration preferences, and additional tools in your home directory. You can begin working immediately, without customizing your environment every time you use the shell.

Link: https://aws.amazon.com/cloudshell/

Snowflake - Tasks

User-defined tasks allow scheduled execution of SQL statements. Tasks run according to a specified execution configuration, using any combination of a set interval and/or a flexible schedule using a subset of familiar cron utility syntax. Tasks currently run in user-specified warehouses but will eventually run in a serverless environment using Snowflake-supplied compute resources. Currently, a task can execute a single SQL statement, including a call to a stored procedure. Tasks can be combined with table streams for continuous ELT workflows to process recently changed table rows. Streams ensure exactly once semantics for new or changed data in a table. Tasks can also be used independently to generate periodic reports by inserting or merging rows into a report table or perform other periodic work.

Task Scheduling
There is no event source that can trigger a task; instead, a task runs on a schedule, which can be defined when creating a task (using CREATE TASK) or later (using ALTER TASK). Snowflake ensures only one instance of a task with a schedule (i.e. a standalone task or the root task in a tree of tasks) is executed at a given time. If a task is still running when the next scheduled execution time occurs, then that scheduled time is skipped.

Task History
Query the TASK_HISTORY table function to verify the task did not run. It is possible that the task ran successfully but the SQL statement in the task definition failed. In particular, note the scheduled and completed times, as well as any error code and message. If the task has a parent task (in a tree of tasks), verify whether the parent task completed successfully.

There is a 60 minute default limit on a single run of a task. This limitation was implemented as a safeguard against non-terminating tasks.

Link: https://docs.snowflake.com/en/user-guide/tasks-intro.html

Snowflake - Stored Procedures

Unlike MS SQL server, Snowflake's stored procedures are written in JavaScript. A stored procedure returns a single value. Although you can run SELECT statements inside a stored procedure, the results must be used within the stored procedure, or be narrowed to a single value to be returned.

Snowflake stored procedures use JavaScript and, in most cases, SQL:

• JavaScript provides the control structures (branching and looping).
• SQL is executed by calling functions in a JavaScript API.

Stored procedures allow:

• Procedural logic (branching and looping), which straight SQL does not support.
• Error handling.
• Dynamically creating a SQL statement and execute it.
• Writing code that executes with the privileges of the role that owns the procedure, rather than with the privileges of the role that runs the procedure. This allows the stored procedure owner to delegate the power to perform specified operations to users who otherwise could not do so. However, there are limitations on these owner’s rights stored procedures.

One common use for stored procedures is to automate a task that requires multiple SQL statements and is performed frequently.

Snowflake API consists of JavaScript objects and the methods in those objects.

Link: https://docs.snowflake.com/en/sql-reference/stored-procedures-api.html

Multi-tenant Application

According to the definition available online is "Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers". The term "software multitenancy" refers to a software architecture in which a single instance of software runs on a server and serves multiple tenants. Systems designed in such manner are often called shared (in contrast to dedicated or isolated). A tenant is a group of users who share a common access with specific privileges to the software instance. With a multitenant architecture, a software application is designed to provide every tenant a dedicated share of the instance - including its data, configuration, user management, tenant individual functionality and non-functional properties. Multitenancy contrasts with multi-instance architectures, where separate software instances operate on behalf of different tenants.

Types of multi-tenant architecture:

There are three main multi-tenancy model types, all with varying levels of complexity and costs. A single, shared database schema is a multi-tenancy model with a multi-tenant database. This is the simplest form out of the three and is a relatively low cost for tenants because of the use of shared resources. This form uses a single application and database instance to host tenants and store data. Using a single, shared database schema allows for easier scaling; however, operational costs can be higher.

Another multi-tenant architecture includes the use of a single database with multiple schemas. This tenant system uses a single application instance with individual databases for each tenant. In addition, this architecture has a higher cost with more overhead with each database. It is a valuable architecture when data from different tenants need to be treated differently -- such as if they had to go through different geographic regulations.

The third type of multi-tenant architecture hosts data in multiple databases. This model is relatively complex in terms of management and maintenance, but tenants can be separated by a chosen criterion.

In cloud computing, the meaning of multi-tenant architecture has broadened because of new service models that take advantage of virtualization and remote access. A software-as-a-service (SaaS) provider, for example, can run one instance of its application on one instance of a database and provide web access to multiple customers. In such a scenario, each tenant's data is isolated and remains invisible to other tenants. Multi-tenancy can also be implemented in multi-tier systems such as an SAP system.