Today we discuss the benefits of jquery plugin or javascript SDK to represent analytical capabilities.
We are well familiar with the analytical capabilities that come with say, the Machine Learning packages such as sklearn and Microsoft ML package or complex reporting queries for dashboards. We have traditionally leveraged such analytical capabilities in the backend.
This works very well for several reasons:
1) The analysis can be run on Big Data. The more the data, the better the analysis. Consequently the backend and particularly the cloud services are better prepared for this task
2) The cloud services are elastic - they can pull in as much resource as needed for the execution of the queries and this works well for map-reduce processing
3) The backend is also suited to do this processing once for every client and application. Different views and viewmodels can use the same computation
4) Performance increases dramatically when the computations are as close to the data as possible. This has been one of the arguments for pushing the machine learning package into the sql server
5) Such compute and data intensive operations are hardly required on the frontend where the data may be very limited on a given page. Moreover, optimizations only happen when the compute and storage are broadened to the backend where they can be studied, cached, and replayed.
6) Complex queries can already be reduced to use a few primitives which are available as query operators in both backend and frontend. The application or client that needs to do client side processing of such queries have the choice to implement it themselves using these primitives
Having reviewed these reasons, we may ask if we have enough support on the client side and if a new plugin is justified. Let us make the purpose of the plugin clear. It provides the convenience to reuse some of the common patterns seen from the analysis queries across charts and dashboards in different domains. Patterns that are well-known such as pivot operations as well as esoteric ones such as from advanced dashboarding tools may be consolidated into a standard plugin or sdk.
The QueryBuilder plugin allows conditions to be specified which is great to build conditions into the query. If we could also introduce piping of results into operations that would also help.
The QueryBuilder can either build a query or allow different queries to work in sequence where the results of one query is piped to the other. Queries written in the form of shell commands and piped execution is a form of the latter while complex predicates in SQL queries is an example of the former.
#codingexercise https://ideone.com/kAibv2
#OpenAI has algorithms more than what ML package and Turi implement
We will discuss incremental graph transformations next : https://1drv.ms/w/s!Ashlm-Nw-wnWtkxOVeU-mbfydKxs
We are well familiar with the analytical capabilities that come with say, the Machine Learning packages such as sklearn and Microsoft ML package or complex reporting queries for dashboards. We have traditionally leveraged such analytical capabilities in the backend.
This works very well for several reasons:
1) The analysis can be run on Big Data. The more the data, the better the analysis. Consequently the backend and particularly the cloud services are better prepared for this task
2) The cloud services are elastic - they can pull in as much resource as needed for the execution of the queries and this works well for map-reduce processing
3) The backend is also suited to do this processing once for every client and application. Different views and viewmodels can use the same computation
4) Performance increases dramatically when the computations are as close to the data as possible. This has been one of the arguments for pushing the machine learning package into the sql server
5) Such compute and data intensive operations are hardly required on the frontend where the data may be very limited on a given page. Moreover, optimizations only happen when the compute and storage are broadened to the backend where they can be studied, cached, and replayed.
6) Complex queries can already be reduced to use a few primitives which are available as query operators in both backend and frontend. The application or client that needs to do client side processing of such queries have the choice to implement it themselves using these primitives
Having reviewed these reasons, we may ask if we have enough support on the client side and if a new plugin is justified. Let us make the purpose of the plugin clear. It provides the convenience to reuse some of the common patterns seen from the analysis queries across charts and dashboards in different domains. Patterns that are well-known such as pivot operations as well as esoteric ones such as from advanced dashboarding tools may be consolidated into a standard plugin or sdk.
The QueryBuilder plugin allows conditions to be specified which is great to build conditions into the query. If we could also introduce piping of results into operations that would also help.
The QueryBuilder can either build a query or allow different queries to work in sequence where the results of one query is piped to the other. Queries written in the form of shell commands and piped execution is a form of the latter while complex predicates in SQL queries is an example of the former.
#codingexercise https://ideone.com/kAibv2
#OpenAI has algorithms more than what ML package and Turi implement
We will discuss incremental graph transformations next : https://1drv.ms/w/s!Ashlm-Nw-wnWtkxOVeU-mbfydKxs
No comments:
Post a Comment