New Appgyver has completely broken the hosting behavior for firebase hosting

Does anyone know what ordeal we have to go through now that Appgyber team has broken the hosting behavior on firebase hosting?

This concerns me since I use firebase but please explain more what’s wrong.

I usually put all appgyver files in a public folder and deploy it as is, with public listed as the public folder in the firebase.json. Now when I do that (the entire structure of the files has changed in the new runtime), nothing I do can get the app to open with the base url. Only if I put the path /public/index.html. I have tried both with the rewrites as single page app and without. In addition, I cannot pass any variable or enter any inner page directly, like I could before. It will always return a 404 error. They have changed the entire routing and structure of the files when it was perfect.

I just built and downloaded the zip file. I unzipped it in the ‘public’ folder, deployed it to Firebase and it works fine. It doesnt require me to specify index.html … did you change anything on your Firebase hosting settings? I know there was somewhere where you can specify what the default index file can be.

I’ve been having this issue too, but I deploy through Digital Ocean. Build service 4.5.7 seems to be the culprit. My app works fine, but when I try to refresh the page, I get a 404 error, where in the past I have never had this issue. Hopefully a new build service is released soon, because this is preventing me from making updates to my production app.

Side note: I have a hunch that it may have to do with the file structure of the ZIP folder. I have seen files that include “Page1” “m-Page1” and “Page1.html” , what is the purpose of these different files? It seems it changes slightly every time a new build service is released

1 Like

Yes, I believe that is the problem. Each page file is no longer nested within it’s own folders so the paths are not routing correctly. I have been studying up on next, and have discovered many other fundamental flaws in the web app build. In a next app, there are not actual pages corresponding to url paths. The page stays the same and everything on the page as well as scripts and variable are preloaded before the browser actually renders the content. It is the initial props which manipulate what appears in the page, therefore even novice next developers learn that they need to handle refreshes differently. Who would ever build an app, let alone an app builder, which would leave this unmentioned and intentionally implement code to return a 404 error screen rather than using the event to pass all the same props it did the first time it was rendered??? After a little more research, I discovered the team is well aware of this and have implomented server-side code which handles this when the web apps are hosted on the appgyver subdomain. The same rewrites and rules can be accomplished to address this with a combination of firebase function and hosting rewrites and redirects, but this is a very illogical method of doing this when next has created a built in method for allowing dynamic urls, which would not only fix the issue we are having here, but it would also get rid of the horrible practice of the ugly m-Page1.Page1 to 3 and all that nonsense, which would cause any visitor to sincerely doubt the abilities if the developor or entity behind such a bad user experience of trying to share a link and seeing 404 after 404. The urls can very easy be dynamically defined according to the data being queried and rendered. For example, say you have a blog. The page for the blog should be mysite/blog, and the method next has created would allow the developer to define which field in the data should be used as the final segment of the url, obviously the title of the post. Or even the users handle followed by the title. Next has provided for this. It is a fundamental concept in developing web apps with next.

So it looks like the appgyver team does not plan on providing a web app builder. The amount of developer frustration around this issue does not make any sense.

Read the next docs and you will learn how to rebuild the web app with the proper next developer practices and solve this very simple issue.

So there is a way to manipulate the static Next files to make it actually work?

I would have to look closer at Appgyver’s copyrights and policies before I could answer that question here. But this is a good place to start to learn about next dynamic links:

This may work in some cases using firebase hosting configs described here, or the firebase server side functions which can be written to handle all requests not directed to the home page. You would have to write logic in your app to receive the params and paths passe by the functions, such as a server.js express app. But this should all be made simpler by appgyer team. I really hope they address this stuff and bring their product to the point where it is a viable solution.

1 Like

Hey y’all. I’m coming back to this thread to let you know about a fix I found to this solution. I switched my app from being hosted on Digital Ocean to now Firebase, and Firebase has a config file that allows a setting called “cleanUrls”. If this is set to true, the refreshes work properly. Without it, they are broken. Digital Ocean used to work fine for us, so I imagine it is an AppGyver build service issue that is causing it, but hosting on Firebase seems to be a fix for now. Good luck

2 Likes