I am very curious about the new resource manager. I can’t test it out because of the limited Cloud Hosts available. Very little other than the original documentation post by Teodor has been even mentioned in the forums yet.
1: What problems does Resource Manager solve?
2: Is it just a niche feature with limited use?
3: Who would use it and why?
3.5: IS it just for advanced users?
4: From what I can figure it’s just another place to enter all your project settings?
If this was truly a great feature (which it certainly might be) I would have expected more chat about it here. I want to know more about it and how it would help me, if it all.
P.S. The keyboard shortcut to open the Resource Manager conflicts with MAMP Pro.
At the moment I’m not fully understanding the feature entirely but I’m hoping that it will somehow make scaling deployments easier.
I started to have traction with my app now, so I have always in the back of my mind the question if I’ll be able to scale later on with my limited knowledge about that kind of stuff.
The resource manager will automate your hosting setup.
So instead of creating servers, databases and various services needed for your project and copy and paste different settings in Wappler, you can do this all in the resource manager and then just assign those resources per target.
So all the needed servers and services can be created directly in the resource manager and their settings will be auto distributed from there.
Thank you for these questions.
I actually see resource manager as a beginner’s tool for hosting management. However, I’m not sure how this contributes or will help wappler users. While the Wappler team is adding great innovations every week, I never understood why they added such a feature for wappler 5.0. It would be much better to add other feature requests that we’ve been waiting for months instead of this “Resource Manager”. I’m sorry to say that wappler’s full version transitions are always with surprises, but this time the surprise did not make me happy. Maybe it’s a feature I’ll never use. I wish pending feature requests were added.
However, if there will be different developments that require this feature, I cannot say anything about it … we will wait and see.
Thank you very much for your hard work and other improvements.
Doesn't this just cause confusion with all the other places we can enter information? There is already plenty of places to enter that information. I feel it's going to cause a lot of confusion to a process that really only needs to be done once per project. Once it's set up it's set up. Hopefully Heroku hosting will be added soon (hint, hint) so I can see how this helps. Right now I just don't get it. But I have been wrong before.
I agree, especially for a major release. I'd rather see focus on adding/fixing stuff we can't do than spending another few weeks of beta on something that we can already do. But I am sure the team has a plan. They usually do. Time will tell.
Thanks @brad for this discussion thread.
For the sake of this, I updated to beta 8.
To be honest, I didn’t understand what it was for, especially since the current cloud providers are not suitable for me (and not only for me).
I was hoping that in the resource manager it would be possible to add the resources I have, and apply them to a specific development environment for centralise resource managment.
For example:
Add available resources:
1.1. Redis on cloud
1.2. Redis on Docker Desktop
1.3. Redis on Docker hosting
1.4. Proxy server on cloud
1.5. Database on Cloud
1.6. Database on Docker Desktop
1.7. Database on serverN
… all resources what we use in wappler
We create a development environment and connect resources to it.
Dev env:
Redis on Docker hosting
Database on serverN
…
Test env:
Redis on Docker hosting
Database on serverN
…
I correctly understand the purpose of this innovation?
I know I sound like a broken record with extensibility but have you planned on adding custom providers and custom resources with UI support via hjson? It could be useful.
I can create an hjson file that contains the UI fields that need to be completed for setup and the docker command to run it on the target(or dockerfile) or the string for the bash script to run on server.
Or an yml file similar to caprover one-click-apps that contains the dockerfile content and other variables needed by Wappler UI.
Example:
Provider example: Cloud provider XYZ that has a rest API to manage servers.
The hjson would contain the fields for the UI and the REST API calls. Transformation and mapping of the response would be in order of course.
For complex provider and resource integrations based on CLIs or JS api it’s a bit more tricky due security and performance of the app but I’m pretty sure you could find a way.
The resource manager as a whole or my suggestion of adding extensibility features to it?
If it’s the former I guess users will have a centralised place with a UI they are already used to and comfortable with to manage their servers and the resources they need for their app to run.
If it’s the latter I just need things to be extensible. In fact if I look at what I use mostly of Wappler it’s basically AC and SC because I can extend it all that I need. Although SC is missing some extensibility and AC has no UI support for custom components.
Features that I don’t use that much are database, theme and git manager. And they have a thing in common: I can’t extend them. So maybe there is a correlation here for me.
So at the moment, I’m not getting much value from new features added in 5.0 and pretty much all 4.0.
I have this hope that the roadmap from 5.0 to 6.0 is making everything extensible. Even the UI for that matter It’s a road to growth and a bigger and better ecosystem.
It’s a road to growth and a bigger and better ecosystem.