I don't think this is a great idea, to mix the technologies, as both will try to manipulate the DOM, and you would likely see strange behaviour

If you are migrating the application in a modular fashion, I've found it's best to keep the functionality seperate, and tune the navigation to switch between the appropriate technologies and migrate the existing pages as you go.  The only thing to be careful about is your %session state if you do this (I've barely used %session on my Angular code, and instead try to write everything to work in a stateless fashion)

There can be more to "speed" that just execution time of your code.  If you need to add an index to help performance, then a Caché SQL query will be able to utilise it without any code changes.  If you are using $Order, then you need to spend some time writing and testing your new code.

I typically use SQL to identify objects, then Object methods to interact with them, but for simple updates of large numbers of objects, I'll usually use a simple SQL Update.  The beauty of Caché is the flexibility to use the best tool for the task at hand

Hi Javier

I did this by implementing a fromJSON method on each class, which allows me to do what you describe.  By moving this to the persistent class, I don't have to worry about instantiating or accessing the object, but can just apply a JSON update to an object

The details are in https://community.intersystems.com/post/lets-write-angular-1x-app-cach%C3%A9-rest-backend-part-9

Hope this helps
Chris

Just to add a word of warning.  The syntax for %Object is only available in 2016.1, and is deprecated in favour of similar but incompatible objects and syntax in later versions.  If you have the choice of versions, it would be wisest to adopt 2016.2+ and use the DynamicObject class and methods, as this will be more futureproofed

Details are at https://community.intersystems.com/post/json-changes-cach%C3%A9-20162

HI Jennifer

I started building my application quite some time ago (over a year ago), so Angular 1.x was the best choice at the time with the support of the Material UI platform, and I didn't want to have to start again since the new version of Angular isn't compatible with the old syntax, or easy to migrate to.  However, one of the nice things about structuring the application with REST is that it is pretty straightforward to bolt a new front end, or even run a new one side by side with the old one.

Hi Joe, 

Are you using Chrome to debug?  You should be able to click through to the error on the Network tab from the Deubgger.  Anything that returns an error code should be highlighted in red, and if you click that red text, then it should give you the specific error coming from Caché.  If you get this error, I should be able to find my mistake in the exported code.

There's example of this debug process at the end of part 7.  I've also added an example logo to the github repo

Thanks

Chris