@Armin Gayl we'll soon have a lot of news regarding source code management in VS Code. Of course, out of the box you can use any client-side SCM you want, with git being the obvious choice since it's built-in to the product. We're working hard on server-side SCM as well, which you will see in beta this summer.

By SPA you mean single-page application, yes? 

Will your product also be a progressive web app? Will you use a framework like React or Angular or Vue?

Hi @Renan.Lourenco. Yes VS Code is way behind Studio in features today, but Studio has a head start of many decades! We'll get there...

I agree with @Eduard Lebedyuk and I'd just emphasize that in most cases the extra minute it takes to create the issue is usually worth it, except for the simplest of fixes.

Thanks @Alexander Koblov . We'll look into it.

You can find the Python Native API wheels in dev/python in IRIS 2019.2 and above as well.

Hi Neerav. Here's a sample used in a presentation from Global Summit this year. Hope it helps!

https://github.com/intersystems-community/angular-material-iris-starter
 

@Yone Moreno are you working on "Learning Path Exercise: Building a Server-Side Application with InterSystems IRIS"?

If so, it's helpful to use the "Show Answer" button.

Sorry I don't have a good answer for you using FHIR if you don't have an address for the patients.

Yes! Storing queries that are re-used a lot is a great use of REST. I haven't implemented anything recently so no code to share with you but the client interface would be like any other REST resource. You could even POST a query that had one or more parameters that could be set when GETting the resource, so your query resource would be more extensible. For example, the resource might always query the same field name in a table, but you might pass a query string in the GET that would define what you were searching for in that field. But then you're on a slippery slope to not being RESTful anymore...

I agree that query, in general, doesn't fit into the pure REST architecture, and that POST/PUT should be used to create or update resources. I worked in a standards organization for many years and we had many "religious wars" regarding query and REST. There was never any clear answer. What we decided was to use GET with query parameters whenever possible, and when you needed a message body (for example to integrate with SOAP architecture), use POST.

The only truly REST way to handle query is to POST/PUT a query to make it a resource, then use GET to execute the query, then use DELETE to get rid of the query. But this is an awkward way to solve the problem, simply to stay truer to the spirit of a REST architecture.