Hi Evgeny, I'm using this technique for sending e-mails (using a template engine like handlebars) in my own applications, but I don't have an easy example stripped-down to the bare essentials right at hand. But I'll write an example post how to do this as soon as I have some spare time and I'll add a link to it in this post too.

Hi John,

I'm happy to hear the course was useful for you! 

Btw, I can also recommend the YouTube channel from the Frontend Developer conference lately in Amsterdam:
https://www.youtube.com/channel/UC1nBp6ouBB1o5P8YvPznPOw

You'll find a featured video there from the creator of Vue.js (Evan You) about how Vue.js will go forward. Btw, in terms of GitHub stars, the Vue.js project currently has 88k stars while React has 91k - it became quickly one of the leading frameworks and adoption is comparable to React. 

I'm also more and more convinced Vue.js is a very complementary front-end for Caché/IRIS (and a natural fit) because of it's simplicity, flexibility and feature richness:

• simplicity: if you worked with HTML, CSS & JavaScript in a CSP page, your can write Vue.js pages too
• flexibilty: excellent for existing (bigger) applications because you can even replace pieces of your application with Vue.js controlled fragments - no need to rewrite your existing applications completely!
• feature rich: under the hood, it uses modern JavaScript technology in the browser (it won't work on Internet Explorer 6 ) to make your client side application code reactive by design

It's very easy to learn and allows to bind your front-end to your back-end using the technology you prefer like WebSockets (using QEWD), REST, GraphQL, ...)

To use SQL from Node.js - keeping the advantages of both worlds (JS & COS) - I created a small helper module you can use in your own Node.js handler modules.

The way it works is:

• you call a function/method in COS from your Node.js handler, passing all necessary parameters in

• the helper module puts them in a temp global (this means you don't have any limits on the amount of data you pass to Caché)

• your COS code uses the input data (parameters) in the  $$$jsData("params", ...) global (I defined a macro for readability)

• your code fills  the $$$jsData("json", ...) global with the result data (remember that JSON maps 1-to-1 on a Caché global)

• you get the response back in you Node.js handler and you have your result data available as a JSON object ...

I released a new module for this: qewd-cos - it's explained in detail in the module how it works with a working example. This module defines a standardized way of calling your own functions in Caché - take a look at the source code to see how you can call Caché functions and return standard responses in QEWD.

Btw, you can also use QEWD in the other direction: you can call from your COS code your own QEWD REST (or microService) endpoints using HTTP calls using  ##class(%Net.HttpRequest). This is e.g. very useful to send e-mails using standard NPM modules allowing you to use templating engines (like handlebars, ...). It allows you to create more advanced e-mails much easier. Or more in general, to make external Node.js modules/functionality available in Caché which is not built-in.

I completely agree - Vue.js uses the more modern features in JavaScript cleverly (btw which finally rules out IE <= 8). But anyway, Vue.js is a great initiative taken by an Angular developer to create a much faster, more natural and lighter library - keeping the good parts of Angular.

To compare them in terms of GitHub stars:

• Vue.js: 67.437
• Angular: 85.077 = 27.955 (version 4) + 57.122 (older version 1.6)
• React: 75.941

Vue.js has an exponentially growing popularity, compares well to Angular but is much more compact and is nearly as popular as React (but React came out one year earlier!).

Last week I found this excellent blog article comparing the most popular JavaScript libraries and frameworks.

I must say I'm currently using React/Redux for my projects, but last week, Vue.js drawed my attention by coincidence. When I started trying out some examples, this library felt immediately like "this is it" and "why didn't someone else think of this before?" to me. It comes very close to HTML + vanilla JavaScript and the way of coding is very intuitive.

I completely agree Herman! Vue.js looks so "natural" once you start coding with it that you ask yourself the question: "why didn't I think of this before?" ...

IMHO, there's also one big difference between Angular and Vue.js: Angular is a "complete" framework in the sense that it contains all functionality you may need (what makes it big and heavy - 452 kB minified!) while Vue.js is a library for your view + business logic (what makes it so compact and lightweight - only 16 kB minified). With Vue.js, you only include functionality you need for your application. One would argue that with current hardware devices this is no longer an issue, but the performance hit lies in the execution of this amount of code at runtime, which makes it slower the bigger the framework code is.

In fact, the guy who started Vue.js (Evan You) was first working at Google Labs with Angular where he saw the need to make an easier to understand, much more compact library allowing you to do the same with a flat learning curve. When you see Vue.js now with it's companion libs like Vuex, I think he did a really great job!

You can also perfectly communicate with the back-end using CSP/REST, using Caché as the application server (as you can see in parts 2 & 3). This is a choice the developer has to make.

However, using Node.js as the application server (and Caché serving as the database - or even application server too) gives you a lot of advantages:

• as I wanted to show in this article series, you develop using the same programming language at the front- and back-end, JavaScript is very popular for several years now and it's much easier to find JS developers
• you can use all readily available functionality in Node.js standard modules in your back-end code: e.g. if you'd choose a front-end framework in the future that pairs out of the box with a standard Node.js back-end module, you'd need to re-implement this from scratch in COS ... modern development tends more and more to the use of existing building blocks instead of re-inventing the wheel
• the same goes for all kinds of modules to external services you'll find on npm providing you with many thousands of building blocks out of the box
• you even have the freedom to choose what you implement in JavaScript and what stays in COS - e.g. call a COS wrapper function from your JavaScript back-end in Caché - the function can contains parts of your business logic with all specific COS functionality you need like SQL, classes, ... communicating JSON (a temp global) in and out from/to your Node.js back-end - giving you the best of both worlds
  Additionally - IMHO - if Caché would also support JavaScript syntax internally one day as a develoment language you could really develop full-stack using one single mainstream language and allow Caché to come out of its market niche

In terms of comparing performance: if someone - as Rob suggests - can write the RealWorld Conduit example back-end in CSP, you'll have a very realistic comparison between the two options!

For an excellent, more in-depth application example, there is now a very useful RealWorld platform available, made by the people of Thinkster allowing you to easily compare many different modern web app technologies (front-end and back-end solutions).

This example app is a quite advanced real-world example you can use as a reference app to write your own apps and get the idea what development with modern app technology is all about.

The best news: Rob Tweed created a Caché Node.js back-end using QEWD/Express REST calls for this example  app and also made a React/Redux demo version available to test using Caché as the underlying database.

Please check out this example as the results with Caché in terms of performance and development speed are really impressive!