“Behind-the-Atlassian-firewall-hosting” for our Apps, so we could address the customer trust issues with a third party (us Vendors Marketplace Partners) being able to access potentially sensitive information. This would be a killer feature that would let us gain more trust from the Enterprise customers.
Pretty please 
Since we’ve all gone beyond just one piece of feedback, here’s more of mine, from top of mind:
Problem: From the reliability angle, the whole experience with the rollout of the Fabric editor was a nightmare for our team, and others that I have observed. Poor to no communication, little testing with Connect macros before it was deployed to production, and an adherence to a vision that vendors tried to communicate would break existing Connect UX flows which seemed to land on deaf ears. Technically no APIs changed, but the change in UX both dropped details in the integration contract and otherwise broke previously legitimate ways to develop Connect macros. Now over a year after Fabric began rolling out to production there are still major defects or deficiencies in the integration of Connect macros with Fabric pages. To confuse things more the new editor has become only one of two, and yet the Connect experience for developing macros behaves as if there’s only one from the developer’s point of view. It’s been an awful, time consuming experience that still has no satisfying conclusion.
Asks: Please provide first class support for Connect macros in Fabric, and support for rendering macros appropriately in each type of editor now that Atlassian has committed to supporting both simultaneously.
Problem: Also, the Confluence REST APIs are not only some of the worst examples of HTTP-based APIs I’ve seen, they seem to get very little attention in terms of bug fixes or improvement. There’s something moderately-to-seriously wrong with every one of them I have used over the last few years. Poor error handling aside, the JSON-RPC APIs that they replaced were much more intuitive, clean, and functional (probably because they mapped to the Java APIs that Atlassian used to build the product, unlike the REST APIs which appear to be something that exist largely only for third party integrations). If you want to make life better for cloud developers, you need to prioritize the quality of the APIs they have at their disposal.
Asks: Commit more resources to the maintenance of your APIs. Build some commercial products on them in anger yourselves… or give us access to the APIs you do use (cough GraphQL cough).
Problem: Despite some light messaging to the contrary, in practice it feels like the Connect-based developer experience is now barely being supported while Atlassian piles on resources to Forge. Forge sure looks promising for a certain class of new app dev some day in the distant future, but doesn’t really do anything for us today beyond add stress – we know we should be trying to stay abreast of it and be ready to hit the ground running one day when you can build monetizable apps with it, yet in the meantime small teams like us struggle to keep the lights on with the existing cloud apps we require to stay in business.
Asks: Don’t forget about Connect while fervently racing to deliver Forge, even if Forge is internally being thought of as simply a new facet of Connect (or vice versa).
You’re about to have 3 third party integration platforms, yet the first two aren’t even getting the support they need to deliver a winning developer experience. I know and respect many members of the “incredible team that’s doing everything they can to make our cloud developer experience delightful,” but from this side of the fence the experience is anything but delightful.
Problem: We do interact with a few individuals on CDAC regularly that are extremely helpful. It’s unclear whether or not they are actually acting as support agents, or simply going out of their way to be helpful. Either way, we appreciate them tremendously! That said, it’s hard to know if we should lean on them when in need or not (out of respect for their generosity if they are simply volunteers).
Asks: It’d be amazing to have some kind of org chart and/or understanding of the Atlassian personalities we do get support from on CDAC so that we could know what to expect of them or what their organizational capabilities really are. It’s hard to know who to reach out to and when and whether we would be burning someone’s good will instead of leveraging an intended contact.
This is fundamentally part of the problem in using CDAC as a support system. We don’t really know whether someone is acting as a support agent or not, nor do we know if our posts raising non-critical issues are being read methodically (as they would in a support queue) or simply casually (if and when someone happens to have time to pay attention).
Also, to jump in on some other “threads”:
+1 To Roberto’s comments, that is a very accurate description of our experience as well.
+1 To the sub-discussion about ACE – there have been many requirements and recommendations that have come from the security team this year that have not been reflected in ACE (for example, secure handling of shared secrets, verification of installation requests, and others). In fact, ACE is actually quite old now and probably deserves a reformulation from the ground up as a set of libraries and patterns rather than a framework, ideally using state of the art technologies (e.g., TypeScript, inversion of control, etc). In any case (technical decisions aside), what the community needs is an actively maintained reference implementation of how to build a properly secured Connect app.
Of course, proper security goes beyond what can be built into libraries or frameworks. The stack on which an app is hosted is a critical piece of the puzzle. There are many solutions, but often what communities need is to be spoon fed best practices with a recommend stack, top to bottom – even if only to be used as a gold standard reference implementation. If Atlassian won’t or can’t offer or recommend any hosting option for Connect apps (not counting Forge, which cannot meet all the need of today’s Connect apps), then it should at least provide an example, full stack AWS configuration (maybe cloud formation templates?) that meets all of the requirements demanded of Connect app devs. I truly don’t understand how you expect to attract developers to the cloud platform given the current mountain of requirements that aren’t backed up by a clear reference implementation available in one place.
The overhead for any single developer today is absurd. Parsing all of the requirements and translating them into your own compliant solution is not something a new cloud app dev could reasonably be expected to do for an app that is generating no revenue, and may take years to do so profitably.
I know Atlassian wants Forge to be the answer to many of these concerns, and hopefully some day it will be. I am skeptical that Forge will be ready any time soon to solve most of the problems Connect apps tackle today, however, leaving this awkward gap between reality in the ecosystem and Atlassian’s vision and focus of resources for the future.
Wondering if Simon regrets calling Ecosystem.getFirehose().actuate(). 
Haha!
I hope Atlassian is able to resist the notion that ‘this feedback is just part of having an ecosystem’, because its really not.
I believe these two invocations will return very different result sets:
Ecosystem.getCloud().getFirehose().actuate()
Ecosystem.getServer().getFirehose().actuate()
The individuals holding up the Cloud ecosystem I believe are largely trying their best (with the exception of the Fabric editor rollout), but seem to be far too few.
Not at all, feedback is a gift 
Thanks all for your responses – I’ll be getting back to each of these (and any replies upcoming) over the coming days.
Simon,
It’s impossible to share the smallest bit of code. Even the customers are different! In the last 8 years, you’ve piled decisions upon decisions to stray away from making it possible to share features, code or customers:
I’m sorry to say it, but the products which were successful on Server won’t be the same as those successful on Cloud, and making it required to go cloud if we want to stay in business with Atlassian is really a tax on us.
If you could do something for me: Make it possible to have much, much, much, much richer macros/pages/webfragments/UI widgets on the pages of the cloud version, so at least, even if we can’t inject JS on the page, we might/cloud/eventually hope one day to reach feature parity with our Server version, assuming we spend double the time programming for Cloud than on Server. But that won’t change the fact that the cloud version is expected to be a business loss.
@SimonKubica I am sorry I am posting again but there is no other way to reach to Atlassian.
I found ticket that was created in August 2019 about dynamic macros in Confluence cloud: [CONFCLOUD-66858] Plain text macros on new editor make a BE call that returns 404 and don't render on editor - Create and track feature requests for Atlassian products.
This is very important ticket for dynamic macros in Confluence i.e users currently need to publish page to see how macro rendering looks like. Because of this, many users get confused and stop using macros. Can’t blame them because no other system forces this kind of publishing workflow in 2020.
However, for reasons unknown to us, Atlassian seems to have abandoned this ticket in ‘In Progress’ status. There is no transparency why this ticket was abandoned or what is way forward.
This is one of the big headaches with the Fabric rollout I mentioned in one my posts above – it’s an example of how technically no API was broken, but the change in UX disrupted previously functional macro implementations and made the Connect macro experience for plain-text macros much worse in Fabric.
By the looks of it, the assignee of that ticket is no longer even with Atlassian?
Hi @SimonKubica
One specific improvement that would be great for Confluence Cloud apps is new API to create/integrate with “bell” notifications. It would be especially useful for apps that use custom content and want to notify user about some changes related to it. I’d really appreciate having such API
We very much want this as well!
Hi @SimonKubica!
We need the following:
Thanks.
Sincerely, Vadim