#JavaScript

So, one day you're working away at WidgetsDirect, the leading supplier of widget and widget accessories, when your boss asks you to develop the new customer facing portal to allow the client base to access the next generation of Widgets..... and he wants you to use Angular 1.x to read into the department's Caché server.   

There's only one problem:  You've never used Angular, and don't know how to make it talk to Caché.

This guide is going to walk through the process of setting up a full Angular stack which communicates with a Caché backend using JSON over

Something that shot up the popularity stakes last week was this article on a very interesting initiative: RealWorld:

https://medium.com/@ericsimons/introducing-realworld-6016654d36b5

I decided it would be a good idea to use this as a way of creating an exemplar implementation of a RESTful back-end using QEWD against their published API (https://github.com/gothinkster/realworld/tree/master/api)

The results are here:

https://github.com/robtweed/qewd-conduit

Actually it's the first 3rd-party implementation out of the blocks!

Full-Stack JavaScript development allows you to create state-of-the-art applications with Caché. With any (web) app you build nowadays, one has to make a lot of architectural decisions and you want to make the right ones. With the Node.js connector available for Caché, you can create a very powerful server side application server, allowing you to use the latest JavaScript technology and frameworks client- and server-side.

With all these new technologies, the most important is to integrate them in the most efficient way and to create a very productive development experience. This article willl get you started step-by-step with Node.js technology.

Developing a Full-Stack JavaScript web app with Caché requires you to bring together the right building blocks. In the previous part, we created a basic front-end React application. In the second part of this article series I will show how to choose the right back-end technology for your application. You will see Caché allows you to use many different approaches to link your front-end to your Caché server, depending on your application's needs. In this part we will set up a back-end with Node.js/QEWD and CSP/REST. In the next part we will enhance our basic web app and connect it to Caché using these technologies.

Overview

The typeorm-iris project provides experimental support for integrating TypeORM with InterSystems IRIS, enabling developers to interact with IRIS using TypeORM’s well-known decorators and repository abstractions. This allows a more familiar development experience for JavaScript and TypeScript developers building Node.js applications with IRIS as the backend database.

While the project implements key integration points with TypeORM and supports basic entity operations, it’s not yet battle-tested or suitable for production environments.

In our last lesson, we implemented a new REST Service to allow us to perform CRU operations on Widgets, and refactored our Controllers to allow the page setup to be decouple from the content.

When we created our Widget Services, we did not implement a Deletion operation, which the HTTP Delete verb provides.  As this is a base table for other parts of the Widgets Direct empire, we don't want to be able to do a hard Delete of the WIdget values, as this could cause issues with our ordering and billing modules.

Developing a Full-Stack JavaScript web app with Caché requires you to bring together the right building blocks. Previously, I outlined the basic steps to install and connect Node.js to Caché and make it's powerful multi-model database capabilites available for use with Node.js. You can use Caché as a NoSQL-, document- (with unique key-level access!), SQL- and object-database with Node.js. When developing JavaScript applications, you'll see how powerful this combination is and makes Caché a perfect fit for Node.js.

In the first part of this article series I will show how to get started with the React framework, one of the most popular frameworks currently taking over front-end development. In the next parts you'll learn how to connect a basic web app to a Caché back-end.

You'll see, it's very easy to get started with this technology - you can even compare the amount of basic knowledge you need to COS because you only need to know a few basic concepts to start!

This is a basic JavaScript Vue.js example how you can use REST calls using plain HTML.

Intro

Most server-client communication on the web is based on a request and response structure. The client sends a request to the server and the server responds to this request. The WebSocket protocol provides a two-way channel of communication between a server and client, allowing servers to send messages to clients without first receiving a request. For more information on the WebSocket protocol and its implementation in InterSystems IRIS, see the links below.

In our last lesson, we implemented a linkage to our WidgetAccessory class, and debugged some errors we encountered along the way.  We now have our data being returned by REST, but what if we want to update or add new data to our application?  

So far we have only used HTTP GET commands with our REST Services, we now have to implement PUT (which roughly corresponds to an Update) and a POST (which roughly corresponds to a Create.  Author's note: there is a lot of writing online about why this statement isn't entirely correct, I'm not going to go into the detail here).

ˮ This is one of my articles which was never published in English. Let's fix it!

Hello! This article is about quite a practical way of developing InterSystems solutions without using the integrated tools like Studio or Atelier. All the code of the project can be stored in the form of "traditional" source code files, edited in your favorite development environment (for example, Visual Studio Code), indexed by any version control system and arbitrarily combined with many external tools for code analysis, preprocessing, packaging and so on.

Some time ago I got a WRC case transferred where a customer asks for the availability of a raw DEFLATE compression/decompression function built-in Caché.

When we talk about DEFLATE we need to talk about Zlib as well, since Zlib is the de-facto standard free compression/decompression library developed in the mid-90s.

Zlib works on particular DEFLATE compression/decompression algorithm and the idea of encapsulation within a wrapper (gzip, zlib, etc.).
https://en.wikipedia.

Those of you who are following the FullStack competition here in the Developer Community will know that I submitted an entry named qewd-conduit.  I wanted to summarise why I think it's something worth you taking a bit of time to check out.

qewd-conduit uses the Node.js-based QEWD framework alongside IRIS to implement the back-end REST APIs for something known as the RealWorld Conduit application:

https://github.

IRIS provides us with anti login CSRF attack mitigation, however this is not the same as a CSRF attack, as login attacks only occur on the login form. There are currently no built-in tools to mitigate CSRF attacks on api calls and other forms, so this is a step in mitigating these attacks.

See the following link from OWASP for the definition of a CSRF attack:

https://www.owasp.org/index.

Introduction

Managing databases and performing CRUD operations are fundamental tasks for developers building data-driven applications. While many database management systems (DBMS) exist, they can be complex and cumbersome to interact with, especially when it comes to creating databases and tables, handling constraints, and performing real-time data operations through an API.

This web-based Database Management Tool simplifies the entire process, offering an intuitive UI for managing databases and tables, alongside a powerful REST API for interacting with the data.

As a result of Evgeny's recent questions regarding the use of QEWD.js with IRIS in another post, I thought it would be a good idea to create a separate post focusing specifically on how to use QEWD.js to create REST APIs for IRIS.

QEWD.js is,  of course, a Node.js framework, and all the REST API code can be written entirely in JavaScript. 

The RealWorld Conduit reference application makes a great exemplar for this kind of thing, as the APIs are all published and there are numerous implementations of both front-ends and back-ends for it, using different technologies, frameworks and databases.

or "Didn't you say you would cover Persistent Objects in Part 5, Chris?"

Yes, that was the plan.  This is a pretty important topic, so it get's its own Article

Up until now, we've display widget JSON that has been created by a basic loop.  Clearly this isn't of much value.  Now we have our stack connected together, and we can see that the data is flowing to the Welcome page, it's time to complete the stack and start feeding our service from "real" data.

Let's start with our (very basic) Persistent class for Widgets.  We have 4 properties to hold Name, Description, Price and current Quantity.

Hi everyone!

Just wanted to share here a quick post about my project for the Grand Prix :)

FHIR Patient Viewer is a single-page, reactive rendering tool built on Vue.js that displays in a human-friendly way the data returned from a /Patient/{id}/$everything call made to an InterSystems FHIR server. In the readme, I've included 3 main things: 1. A video demo connecting FHIR Patient Viewer to a sandbox IRIS FHIR server (the fastest way to test it); 2.

Developing a Full-Stack JavaScript web app with Caché requires you to bring together the right building blocks. In this third part of this article series I will show how to link our React app to our three back-ends we created in part 2.

or "Things are going to break"

We left our application over the weekend, secure in the knowledge that it was returning data from our primary persistent class, User.Widget.  However, Widgets Direct are the premier supplier of both Widgets AND Widget Accessories, so we should really start working on adding these Accessories to our application. 

We should do some housekeeping first though.  Our Page Controlller code is currently sitting in the widgetmaster.js file.

We finished our last lesson with our Widgets Direct page iterating over a list of widgets, displaying an ID and a Name value.  While we have been able to achieve this with only a small amount of coding, the page itself is not the most visually appealing place to be.  The AngularJS framework is providing a powerful Model-View-Controller framework for our structure and logic, but it does not implement anything that will provide a nice UI experience.  For that we need to implement a UI toolkit.

In my previous posting about the new support in QEWD for JSON Web Token (JWT) support, I mentioned that it was a key step in enabling Micro-Service support in QEWD.  In this post I'll give some background to how they work and the thinking behind them.

If you haven't heard about Micro-Services and/or want to learn more, there's lots of information available if you do a Google Search.  Here's a good starting point:

https://smartbear.

There's a new and exciting enhancement to QEWD that has just been released - it's an additional layer of abstraction known as QEWD-Up.  QEWD-Up hides away all the mechanics of QEWD itself, allowing you to focus on just your REST APIs and the code that implements them.

Additionally, and importantly, QEWD-Up simplifies the maintenance of your REST APIs, allowing you (and others) to quickly and easily understand their life-cycle and implementation.

QEWD-Up supports both monolithic application designs and MicroService-based architectures where APIs are broken down by, for example, functional role.

This is a quick note on what happens when, on your CSP page, you call a cache script which returns a %Boolean and store that value in a javascript variable.

When you call a script with language="cache" and returntype="%Boolean" from a javascript script, the return value is interpreted as a string, not as a boolean.

This concept may be known to some, but I just found it very useful and I would like to share as it may help someone else.

If you are working with CSP or Zen you sometimes come across the need to use embedded JavaScript. Suppose you are working with some loops, which use < or > as shown in example below:

&js< 

               var test = document.getElementById('seTest');

               for (var i = 0; i < test.options.length; i++) {

                              // Do Something here with my test.options[i].

or "Bonus Breakage"

In our last lesson, we added a relationship between 2 persistent classes.  We are clearly going to need to start creating REST Services to expose CRUD operations for each of these classes, but before we do that, we should really finish defining our linkages.  We added code to our Widget toJSON to spool off related Accessory data, so we should really do the reciprocal and allow Accessories to return all Widgets that are compatible.

The code we can use is essentially the same as we used on the Widget side.

Previous post - Using AI to Simplify Clinical Documents Storage, Retrieval and Search

This post explores the potential of OpenAI's advanced language models to revolutionize healthcare through AI-powered transcription and summarization. We will delve into the process of leveraging OpenAI's cutting-edge APIs to convert audio recordings into written transcripts and employ natural language processing algorithms to extract crucial insights for generating concise summaries.

Whats NLP Stands For?

NLP stands for Natural Language Processing which is a field of Artificial Intelligence with a lot of complexity and techniques to in short words "understand what are you talking about".

And FHIR is...???

FHIR stands for Fast Healthcare Interoperability Resources and is a standard to data structures for healthcare. There are some good articles here explainig better how FHIR interact with Intersystems IRIS.

My Solution

Chatbot to query FHIR

The most common approach in chatbots is use machine learning to train the model based in old

I received some really excellent feedback from a community member on my submission to the Python 2024 contest. I hope its okay if I repost it here:

you build a container more than 5 times the size of pure IRIS

and this takes time

container start is also slow but completes

backend is accessible as described

a production is hanging around

frontend reacts

I fail to understand what is intended to show

the explanation is meant for experts other than me

The submission is here: https://openexchange.intersystems.

For a long time I have wanted to learn the Django framework, but another more pressing project has always taken priority. Like many developers, I use python when it comes to machine learning, but when I first learned web programming PHP was still enjoying primacy, and so when it was time for me to pick up a new complicated framework for creating web applications to publish my machine learning work, I still turned to PHP.