From a developer experience perspective, what shortcomings do you find in the current Forge component approach?

Use Case,  think of your system as a media database, lot’s of meta data, and lots of fat digital assets, Audio, images, video, all flavors, and formats.  Meta data does the definitions work in the DB.  Since you really do not want these things laying around in the data base because it makes database obese.  We store them in S3 buckets.  The issue is that the assets are of high value, and need backup.  So then we want the initial version backup to Glacier and any incremental new data of the asset type.  Also sometimes there is multithreaded access required, so having these independent of the database is valuable.  They need to be tightly coupled with the meta data, Keys, and Universal ID’s so that re-keying can be accomplished.  This is not a CDN,  That may be needed later, and could definitely reference this master data set, and pull from it.
 
How I would like to see it:
1.       Upload widget or maybe a new entity/object type would be more appropriate with a couple of choices:
a.       Database Storage (Binary Object) Thumbnails, small assets
b.      Disk Storage (some people will want this, actually high risk for us)
c.       S3 Storage (Real time, with or without versioning) Not a backup, live asset store, versioning is important in some cases
d.      Glacier Storage (3-5 hour access, great for non-interactive data, analytics, data mining sets)
e.      S3 Storage with Glacier backup (this we would use the most) This is the combo S3 – Glacier backup
2.       Widget should also generate directory screens (Lists)
3.       Reporting and management widget also needed.
4.       Meta data is stripped from asset and kept in OSP (Format, Size, etc….) probably previewed in loader
 
My initial thoughts, this will greatly streamline your platform, and remove what I expect to be days’ worth of individual customer service issues implementing this over and over again.
 
As more of your clients go toward dynamic content, and highly automated publishing of the content, this will prove invaluable.

Hi Allen,

I am sorry that I somehow missed your reply. I agree that there is an interesting value on having a component that takes care of all those things... but that's the reason why we built extensibility into OutSystems Platform, so that customers, partners, and community members in general can create great components and applications.

I also agree that such component may be useful to a number of customers, but what's components are made for, right?

Joao

er... "that's what components are made for"

Joao -

The AWS APIs are a MESS. They don't work in a standard REST fashion. Just getting authentication to work is a challenge.

Notice that there is no S3 component in the Forge that actually works. It isn't due to a lack of need, it's because it is insanely difficult to do this well/right.

This is a great example of where we need OutSystems to step up to the plate and do the work. I am struggling to find a good way to do this in an OutSystems-y way that makes any sense.

J.Ja