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.

ASP.NET Core Middleware

ASP.NET Core introduced a new concept called Middleware. Middleware is software that's assembled into an app pipeline to handle requests and responses. Each component:

• Chooses whether to pass the request to the next component in the pipeline.
• Can perform work before and after the next component in the pipeline.

Request delegates are used to build the request pipeline. The request delegates handle each HTTP request. Request delegates are configured using Run, Map, and Use extension methods. An individual request delegate can be specified in-line as an anonymous method (called in-line middleware), or it can be defined in a reusable class. These reusable classes and in-line anonymous methods are middleware, also called middleware components. Each middleware component in the request pipeline is responsible for invoking the next component in the pipeline or short-circuiting the pipeline. When a middleware short-circuits, it's called a terminal middleware because it prevents further middleware from processing the request.

In the classic ASP.NET, HttpHandlers and HttpModules were part of request pipeline. Middleware is similar to HttpHandlers and HttpModules where both needs to be configured and executed in each request.

Typically, there will be multiple middleware in ASP.NET Core web application. It can be either framework provided middleware, added via NuGet or your own custom middleware. We can set the order of middleware execution in the request pipeline. Each middleware adds or modifies http request and optionally passes control to the next middleware component.

1. Use: chain multiple request delegates together. The next parameter represents the next delegate in the pipeline. You can short-circuit the pipeline by not calling the next parameter.

2. Run: delegates don't receive a next parameter. The first Run delegate is always terminal and terminates the pipeline.

3. Map: extensions are used as a convention for branching the pipeline. Map branches the request pipeline based on matches of the given request path. If the request path starts with the given path, the branch is executed.

RxJS library

Reactive programming is an asynchronous programming paradigm concerned with data streams and the propagation of change. RxJS (Reactive Extensions for JavaScript) is a library for reactive programming using observables that makes it easier to compose asynchronous or callback-based code. RxJS is a library for composing asynchronous and event-based programs by using observable sequences. It provides one core type, the Observable, satellite types (Observer, Schedulers, Subjects) and operators inspired by Array#extras (map, filter, reduce, every, etc) to allow handling asynchronous events as collections.

RxJS provides an implementation of the Observable type, which is needed until the type becomes part of the language and until browsers support it. The library also provides utility functions for creating and working with observables. These utility functions can be used for:

• Converting existing code for async operations into observables
• Iterating through the values in a stream
• Mapping values to different types
• Filtering streams
• Composing multiple streams

The essential concepts in RxJS which solve async event management are:

• Observable: represents the idea of an invokable collection of future values or events.
• Observer: is a collection of callbacks that knows how to listen to values delivered by the Observable.
• Subscription: represents the execution of an Observable, is primarily useful for cancelling the execution.
• Operators: are pure functions that enable a functional programming style of dealing with collections with operations like map, filter, concat, reduce, etc.
• Subject: is the equivalent to an EventEmitter, and the only way of multicasting a value or event to multiple Observers.
• Schedulers: are centralized dispatchers to control concurrency, allowing us to coordinate when computation happens on e.g. setTimeout or requestAnimationFrame or others.

New Year Greetings 2020

Blockchain

A blockchain is a growing list of records, called blocks, that are linked using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data. At its most basic level, blockchain is literally just a chain of blocks, but not in the traditional sense of those words. When we say the words “block” and “chain” in this context, we are actually talking about digital information (the “block”) stored in a public database (the “chain”).

Blockchain is a cryptographically secured, time-stamped, public and distributed database of every bitcoin transaction that has ever occurred on the network. "Distributed" here means that the information in the blockchain is broadcast to and recorded by every node in the network. There is no one central database. Any user can refer to this list of transactions and check exactly what how many bitcoins have ever belonged to any specific address at any point in time. This way the system is transparent, double-spending is prevented, and there is no need for a trusted central authority.

The goal of blockchain is to allow digital information to be recorded and distributed, but not edited. That concept can be difficult to wrap our heads around without seeing the technology in action, so let’s take a look at how the earliest application of blockchain technology actually works.

Blockchain technology was first outlined in 1991 by Stuart Haber and W. Scott Stornetta, two researchers who wanted to implement a system where document timestamps could not be tampered with. But it wasn’t until almost two decades later, with the launch of Bitcoin in January 2009, that blockchain had its first real-world application.

Integrate Qlik Sense with Web Application

Qlik Sense apps, sheets and visualizations can be embedded in for example:

• Portals
• Web applications
• Intranet and Extranet sites

There are different ways of embedding the Qlik Sense content:

• iFrame integration using the URL Integration APIs
• Div integration using the JavaScript libraries
• Standard Qlik Sense charts and custom visualization extensions can be created programmatically without having to be built in the Qlik Sense UI first, using the qlik-visual web component

Mashups overview

In the context of web development, a mashup is a web page or web application that uses content from more than one source to create a single new service displayed in a single graphical interface.

The Capability APIs enable you to easily and quickly integrate with your Qlik Sense objects to produce enriched results that were not necessarily the original reason for producing the source app in Qlik Sense. You can reuse Qlik Sense visualizations, including your custom extensions, and you can also make use of Qlik Sense data and calculations.

By using active content, your visualizations are updated when state changes. You can also subscribe to data and change the state through the visualizations.

In short it works like the following:

    You open a WebSocket to Qlik associative engine using the qlik.openApp method.

    Objects use the same WebSocket, that is the same session, which means they are connected.

    Qlik Sense objects work just as they do in the Qlik Sense client.