Question
Ian Meinert · Nov 4

CSP Use in IRIS

We have CSP deployed using CACHE and after research, though it's still supported, CSP isn't recommended for production.  What is Intersystems recommended direction?

 

Advisory: Discontinued Technologies and Features | InterSystems Developer

CSP | InterSystems IRIS Data Platform 2021.1

https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI.Page.cls?KEY=GSTD_Intro#GSTD_Int_CSPFile

Product version: IRIS 2021.1
10
3 0 13 230
Log in or sign up to continue

Frontend world where is CSP is supposed to be part of, is growing very fast, and the best results you’ll achieve if you choose any way offered by the frontend community. And this is always depends your needs. Mostly known Angular, React and Vue.js.  The good things of using such popular frameworks, will be a lots developers for you, and that they are driven by the community and grows so fast. You still can use IRIS, as a backend, with REST for instance. Frontend developers may even don’t know what’s drive the backend, and how to deal with IRIS.

Your reference explicitly mentions CSP files (with CSP markup language)
that are stored outside of Caché / IRIS. 

But this doesn't affect class-based CSP and the related server technology.  

I understand the usability in IRIS, but InterSystems specifically states "CSP is not recommended for use in new applications" Why? Any further discussion of CSP in that document doesn't support that statement.

Is it as @Dmitry Maslennikov mentioned above, that it's because of the age of the framework vs SPA's or reactive technologies that are in the open source community now? Is it due to security and protection of the data? I'm sure I could come up with a hundred different answers, but if the Company's product isnt recommended in new applications, an explanation of why should provide clients the necessary justification to either stay with CSP or move to a new frontend platform.
 

A  rather personal view:
The development of customized tags was an attempt to hide COS from "TAG-SHUFFLERS"  
as we named back at the start of this century WebPage coders. Neither JS nor CSS was there yet,
But something more  "modern" than the previous VB5 and VB6 tools were required.

ISC was never a leader in WebPages rather a follower. Also with ZEN and MOJO.
And CSP was definitely never a buying argument for Caché or IRIS.
It was never a core business. Rather a necessary requirement, demanding quite some effort.
Today nobody is forced to drop existing development.  
It is there and it will persist, and it's not hidden, but it will not be pushed.

A personals note.
The first CSP Training for customers was written by my friend Salva (@Jose Tomas Salvador) 
And I did the translation of this training to German and English.( ~ 2 decades back)

> ISC was never a leader in WebPages  

I don't agree: Weblink/CSP was Ajax-avant-la-lettre, it was absolutely amazing what you could accomplish with CSP/CSR. Rob Tweed and Chris Munt invented it and Stavros Macrakis marked it. We were able to rewrite our VB based application (dll-hell) within a few months and being much more flexible.
I still think CSP is very useful for 'internal' applications, combined with Tailwind ccs and Alpine js anything is possible.

2 decades went by Robert??? 😰 Time flies... CSP was great at that time... it was a breath of fresh air for our installed base and competed very well with other technologies in those years... But current front-end technologies make magic nowadays... they're powerful and change a lot and fast. Which is good... and bad... Angular versions change in a blinking... in 7 years, 11 major versions.....difficult to follow them up. I realize the beauty and simplicity of our proposals...with CSP, ZEN,... when you start to learn other front-end frameworks... but the communities behind them let them improve and grow up day-to-day... no way that a single company can compete against that.

But it's not about the front-end, you can use any you like.
The power of CSP is in the back-end: hybrid server-side rendering, seamless integration with Classes, #server/#call.
If you are developing an InterSystems-only web application, not using CSP would be foolish.
You can still use Bootstrap, Tailwind, etc for the UI sugar, but for data integration and routing there's no match.

Hi @Herman Slagman ,
You got exactly my point and my interpretation of the message.
- forget about the file and CSP-TAG-based frontend.

No word on the backend this works perfect and there is no reason for change.
 

I have to agree with Herman.  When WebLink was first acquired by ISC, and during the period 1996-2000, we were demonstrating things that no other web tech at the time could do.  Chris's Event Broker technology, originally released as a Java-based technology that ran in the browser, preceded and delivered what much later became known as Ajax.  I remember during that time John Bertoglio, then a non-ISC user web guy who discovered what we were doing, telling me that in his estimation, we had a lead of between 5 and 8 years over what the rest of the industry was doing.   We did try to lead the horse to water and all that, but hey...

Looking at the responses, its mainly because of the age of the technology and its capabilities when compared to todays best practices.

Could the decision to not recommend for production fall within the scope of the known CVEs?

IT techniques and trends go in cycles - it's always been that way and still is.  Watch for the latest trend that's beginning to gain traction that's known as "HTML over the wire".  It's basically server-side code that generates fragments of markup that are delivered over either HTTP or WebSockets and which dynamically update the DOM - stuff we were doing years ago in WebLink Developer and then EWD (which could be compiled to either (functionally identical) WebLink or CSP code).  The capabilities at the back-end really haven't changed or improved since the mid 1990s - just lots of new buzzwords to describe the same old ways of skinning the cat. The key difference is the performance you'll get from an IRIS/Cache/M back-end compared with every other database-linked back-end out there. Anyway the good news is you have loads of choice these days for how you want to engineer and architect your web technology using IRIS, via what ISC provide and what others such as ourselves provide as Open Source solutions (eg see our mg_web, mg_web server and QEWD technologies)

Front-end technology changes much faster than back-end technology. As Dmitry also suggests, for best results I can recommend you for writing web based apps to use modern front-end frameworks like Vue.js/NuxtJS, React, Angular, Svelte. These frameworks allow you to write well-structured and maintainable code, separating front-end nicely from your back-end. See also this NuxtJS tutorial article. Btw, if you're most used to HTML/CSS/JS in your pages, Vue.js will feel the most familiar to work with and it allows you too to update your existing pages gradually by including the Vue.js script in your <head> tag and start using it for parts of your existing HTML code.

To interact with you back-end IRIS/Caché server, you have two major options: using the REST application server built into IRIS/Caché (if you want to write your back-end completely in ObjectScript) or use a Node.js applications server built on the very popular Express npm module: QEWD-Up. This Node.js back-end server is both a REST & WebSockets application server. It allows you to write JavaScript both in your front-end and back-end code.

In addition, the Node.js option has the advantage you can use all existing npm modules too: for nearly every feature you can imagine, you'll find an existing npm module - you don't need to re-invent the wheel! E.g. you need Google maps in your app? There's a module for that!

WebSockets in contrast to REST give you a very efficient open connection to your IRIS/Caché back-end without the overhead of a REST call. And the most important part: QEWD-Up takes care of all setup and boilerplate code so you can focus on your application code.