nt:file or dam:Asset for better performance | Community
Skip to main content
Uppari_Ramesh
New Participant
November 6, 2023
Solved

nt:file or dam:Asset for better performance

  • November 6, 2023
  • 3 replies
  • 1896 views

Hi Team,

 

I am programmatically creating pdf , docx and txt files and saving in /content/projectFolder. I need good/fast performance when I want to save these files in AEM programmatically . I am thinking if I create nt:file as jcr:primaryType then it will be faster as compared to dam:Asset(since nt:file will not create renditions, related or metadata nodes) . Shall I go ahead with nt:file? 

 

Thanks!!

Best answer by Uppari_Ramesh

Hi @kautuk_sahni  @aanchal-sikka @himanshu ,

 

What I found was it's better to go with dam:Asset because if I want to put some custom properties on nt:file,  jcr is not allowing to add custom properties on nt:file or nt:resource node . Hence I am switching to dam:Asset. Also we have good no of APIs to create and manage dam:Asset as compared to nt:file. Hence I believe it's better to go with dam: Asset.

 

Thanks,

Ramesh.

3 replies

kautuk_sahni
Employee
November 9, 2023

@uppari_ramesh Did you find the suggestions from users helpful? Please let us know if more information is required. Otherwise, please mark the answer as correct for posterity. If you have found out solution yourself, please share it with the community.

 

Kautuk Sahni
Uppari_Ramesh
Uppari_RameshAuthorAccepted solution
New Participant
November 10, 2023

Hi @kautuk_sahni  @aanchal-sikka @himanshu ,

 

What I found was it's better to go with dam:Asset because if I want to put some custom properties on nt:file,  jcr is not allowing to add custom properties on nt:file or nt:resource node . Hence I am switching to dam:Asset. Also we have good no of APIs to create and manage dam:Asset as compared to nt:file. Hence I believe it's better to go with dam: Asset.

 

Thanks,

Ramesh.

aanchal-sikka
New Participant
November 10, 2023

Thanks for sharing the reasons with us @uppari_ramesh .

 

Wishing you a great day !

 

Aanchal Sikka
aanchal-sikka
New Participant
November 6, 2023

Hello @uppari_ramesh 

 

Its not just the upload that you need to worry about, but also how these assets/files are to be used/maintained.

 

If the authors want to use features specific to PDF, DOCX, then these need to uploaded as dam:Asset

Example of features:

https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/assets/manage/manage-pdf-documents.html?lang=en

 

Aanchal Sikka
Uppari_Ramesh
New Participant
November 7, 2023

Hi @aanchal-sikka @himanshu ,

 

My requirement is the assets should not be visible to authors and that's the reason I am not storing assets in /content/dam. These assets are always accessed via Java program only. So I am thinking of creating nt.files instead of dam:Asset. Would like to if it increases the performance.

 

Thanks

Employee
November 7, 2023

For access control, use ACLs to hide the assets from authors. given the assets are only required to be accessed programmatically (TBH, without the detailed use-case its hard to validate if this is a good approach) you should anyway use a service user.

 

Have you done any performance test for Assets API (REST) or AssetManager(Java) to compare the performance with nt:file creation? is the volume/frequency really that significant to build this custom?

 

Again, without looking at the detailed use-case its hard to advice but having assets outside DAM is certainly an anti-pattern.

Employee
November 6, 2023

Why are you bringing in these files to AEM if you don't want them to be treated as assets?

 

/content/dam is the designated area in AEM for assets. By placing these files outside DAM you will not get the assets UI to access these files.

 

Review your use-case and decide if these files are not needed in AEM as assets. If you need them, let them be assets.