Hey Nicholas,
Sorry for the delay in getting back to you. This is great feedback and touches on a range of common challenges being felt by developers. There’s not a lot of quick wins there, but there’s a lot of work going on that should address many of those problems over the coming quarters.
Challenges with the Forge tunnel
To paint a bit of context, the Forge CLI uses a Docker container in an effort to reduce the complexity for developers who would otherwise need to install a list of dependencies to support the underlying Forge runtime. At the time, this solved one of the largest points of friction in Forge developer onboarding.
As you’ve pointed out, using a docker image comes with trade-offs. It’s also a rather large contributor to the performance aspects that you point out. This is mostly due to the filesystem I/O and limited resource allocated to the container.
There is good news, though! As Forge has evolved, so have the needs of our developers. We’re currently in the middle of a multi-quarter initiative to build our next generation Javascript runtime environment. Our aim is to provide a more robust compute offering that helps with aspects of performance, developer experience, and general usability. This work should enable us to re-evaluate our usage of docker and potentially remove it / provide options for developers to go without.
User Permissions
We agree this is a clunky experience, and we’re actively addressing this. See We're removing the allow access prompt for Forge apps and follow the roadmap card on Trello.
It’s been a while between when we announced this work and now, it’s a bit of a knarly engineering problem for us to solve. We have a team working on a solution as we speak and we hope to be in a position to share more soon.
Database Storage
The short answer is yes - we have plans for supporting alternate storage options in Forge platform in future (including relational database support), however we are still exploring what this will look like and when it may be available. As we progress with these explorations, we will seek guidance and feedback from developer community to better understand the key requirements for the alternate storage solutions (including relational DB).
In the shorter-term, we are working on improving our key-value storage, including support for query-by-value, additional querying filters and support for structured schema/entities. More details of the proposed solution can be found on the developer community post. We would love to understand if these improvements address some of your concerns and pain-points in using the current Forge storage API.
Current Board
This one is probably is a quick win, it’s just one of many that the teams working on Jira are prioritising alongside extension points, REST APIs etc. I see Sam has raised this on the community before and we’re tracking demand on FRGE-485.
Migration
This quarter we’re exploring how we can better support remote compute from Forge with a plan to build out those capabilities in the first (calendar) quarter next year. Among other things, the scope will likely include remote access to Forge storage.
As some of our designs/plans around big initiatives like storage and remote access are clearer it would be awesome if we could run them by you and your team to get some early feedback. Would it be OK if we reach out in the not-too-distant future?
Thanks again, Adam