Anybody having major problems with deploying Node, docker, ssh, containers?

I have had issues with the deployment of projects since first using Wappler, years ago.
It just doesn't work properly or consistently.
Folders are moved, ssl certs become an issue, containers are not updated properly and config files incorrectly updated.
The whole process is an absolute nightmare.

Without the most incredible support from @Cheese Wappler would have been unusable for the last 4 months, he has spent probably weeks sorting issues for me only for a Wappler update or the addition of a project completely corrupts the whole process.

I am now at the point where I cannot continue with Wappler, the promise of the new almost fictional Wappler release does nothing for my total loss of confidence in this product.

As an Architect who has worked for decades on truly 'Professional' software (AutoCad) which would perform for years, without crashing or exhibiting major bugs. Wappler has been a huge frustration. With missed deadlines and lost credibility with clients I cannot rely on it anymore.

This product as it stands is only suitable for hobbyists working on php, constantly adding additional functionality whilst seemingly ignoring historic major issues has got it to where it is today, broken.

1 Like

James, sorry to hear you’re having such a bad time with Wappler.

I’ve just looked back through the issues you’ve reported over the years, and most of them were actually quite different things - Docker Desktop problems, Buildx, SSH host keys, cloned project/server settings, target/network config, old/copied project config .. etc.

Quite a few of those were specific to the environment and were resolved once we found the actual cause, so I don’t think it’s really fair to put all of them down as one recurring Wappler deployment problem.

And regarding Wappler 8, this is a huge and very serious development effort. We are rebuilding Wappler as a fully native Rust app, with a native GPUI interface, including Git, SSH/SFTP, Docker, database access and much more. There are countless tests, real projects and deployment scenarios being run while this is being developed, even at this specific moment. And that’s a fundamental rebuild of Wappler, not just a new UI or some side experiment.

If something is actually blocking you right now, post the current deployment output and exact steps and we’ll look at that specific issue, as we always have.

fix and repeat, fix and repeat....

Having been through Jim's Project I think a big part was the constant updates week in week out and changes like routing and Express updates, then several months of no fix for Docker/Traefik issues and so many hacks and workarounds being discussed (and all that mounted up to a complete mess that required untangling piece by piece but as it stands Jims code was all fine the issue was Node/Docker configurations/deployment profiles and database connectivity, why there are multiple database configuration areas I still don't understand but in some circumstances they conflict with each other and containers don't get updated when changes are made in resources and targets, example is if a db is added as a Docker container it is hard to remove it as it is embedded in configurations which then goes on to spawn a multitude of db problems with other db connections). Breakages often occurring when the Project was updated (if a User updates files in a Project they should not nerf the entire Project which is another thing that happened to Jim after applying updates) and no idea why working Projects all of a sudden broke for no reason (something PHP Projects rarely suffer from). Node/Docker Users kind of got left to just deal with it in their own ways and find their own solutions. Support was absent for a long time especially on the Docker side which for some reason took months to resolve (despite the fix/fixes being documented multiple times for months). Not everyone has the time or know-how to fix many of these issues (PRIOR TO AI BEING ABLE TO INTERVENE). It was a multitude of issues mostly bought about by updates. Yes we all like new toys and features but if it breaks everything the User has worked hard on and then does this several times, then like Jim, the frustration boils over (and to be frank sometimes it felt like some updates were never tested against real-world applications and were just pumped out). I've boiled over multiple times I understand the feeling (when you get told it is your environment just to come to the conclusion that no it was not the environment at all it was a bug, which has happened to me many times personally). There was a point when those paying for Wappler were left to fix it for themselves or wait for updates, which in some circumstances seemed to have been forgotten about in the rush to implement AI in to Wappler (was months of AI updates while fixes for app breaking bugs went unfixed, and there are still so many unfixed bugs just look at the Bug Report section). I've still got routing bugs I raised years ago that were assigned and are still not resolved. Either way, right or wrong, feelings aside. Weekly updates are not good for stability. Once a month at maximum is just about OK but now at this stage of the Wappler life cycle no way should we still have weekly updates. It just feels like it was rushed just to get a release out for Thursday and in that rushing about new bugs were introduced and old ones forgotten about, then AI was introduced, then AI was the focus and has been now for almost a year... Yes there have been a few minor updates recently but we want a stable product if we are going to be waiting for Wappler 8. Wappler 7 needs significant attention and not to be neglected just because Wappler 8 is being worked upon. It would also be nice if the User was not always held to account for their environment being the issue. I've had to argue about bugs before being a bug and not environmental. On a few occasions I was wrong but for the most part I was not, nor had I introduced them, untested updates were to blame (or at least not tested vigorously enough). What I don't understand is why not take advantage of us Users with huge Projects and ask us to test them before a general public release? Thus avoiding a lot of the problems people like Jim go through when dozens of files get updated in their Project and cause a cascade of issues (have offered my assistance multiple times to test updates). Just saying. I'm not being harsh here or being unrealistic or fabricating anything or putting Wappler down at all! But there are issues at hand here and they need to be considered and a resolution provided so they don't arise in the future and can be avoided in the first place.

Fair points cheese, and I do appreciate you taking the time to write all of that.

You’ve been around for a long time and you’ve worked on some pretty big and complicated projects, so that kind of feedback is really useful to us.

Once we’re further along with Wappler 8 and have finished the current development and internal testing stages, we definitely want to bring in advanced users like you to test it on real, larger projects before it goes out more widely.

That’s exactly where people with long-running Node/Docker setups, unusual deployment configs and bigger apps can help us catch the things that are hard to reproduce internally.

And yes, your offer to help with testing is remembered :slightly_smiling_face:

1 Like

I just don't want to sound like I am always being negative. Myself and Jim have had a fair few Zoom sessions to resolve the issues he was experiencing. I think the fact is there are many levels of User. From beginners to seasoned developers and those in the middle ground. All too easy to take it for granted that just because we know and understand a stack issue or idiosyncrasy the next User may not. So when a User clicks to update their project files they don't expect their applications to break. With Node/Docker obviously there is always a tighter line as you somewhat come to expect it (I hold my breath until I'm purple sometimes). The trouble is if a User has not updated for a while, maybe a few weeks, during weekly updates week in week out for instance, and they then update, this is where the potential issue lays. Hence my thoughts on weekly updates being too frequent as that is definitely a huge instigator in introducing multiple issues (User has not updated for a month or two etc). Obviously the User may not fully understand the consequence or have the knowledge/experience to foresee there may be issues. That is not a pop at Jim! I get on really well with him and we have become friends over the past couple of months (and he is very competent and created a great application). I feel if the updates were less frequent then weekly it would be a lot easier to pinpoint which of the updates caused an issue if any arise. Then on top of that there is the database side (which has been noted in suggestions for improvement in Wappler 8). One issue was a docker container db was spun up and even though it was removed its remnants remained in the docker file and were not updated in the container deployment. Add on top Express and routing updates etc, docker and traefik, you then can get a feel for where Jim was at. Was a cascade and everything felt broken.

Indeed. I think it could just help alleviate a lot of bug reports. Am happy to find the bugs and report them before a release. We have some massive and complicated applications we can run them against if the need be.

We appreciate you too, and your considered responses. It really does go a long way to restoring confidence.

Just trying to help Jim to explain some of the issues we found. I'd like to be around for a long time to come as well. Like I said I'm not trying to put Wappler down in any way at all.

Thank you Teodor!

Look at that not one em dash any where! HUMANS FOR THE WIN!!

:rofl:

2 Likes

Ok look I have had time to breath again, and I agree with you @Teodor support on the forum has been on the whole excellent, but when issues become so complex it is impossible to deal with, in the forum, it has to be via a one to one chat over many, many hours. (Big up @Cheese!!! )

It isn't the first time the inference has been that it's the end users code which is at fault, and when you don't possess the knowledge and experience of you guys that is quite a big barrier to break through.
When V8 does eventually get released I'm sure many users would agree that getting the bugs ironed out first is more important than adding yet another rushed new feature.

1 Like