I've managed to make a file uploader to the local server, with Meteor.
-.meteor
-local
-build
-db
-static
Ive write the files to the static folder, and everything goes fine, but whenever I restart the server, end build a new app, the local folder gets deleted along with my static folder.
Is there a safe place for files, which does not bundle with the app?
I've tried to write outside the local folder, just next to it, but when I deploy that version, the app wont start at all on the meteor server.
So where am I suppose to create a "safe folder" neither being bundled on deploy, nor deleted on restart, and still accessible apps deployed to the meteor server?
thanks in advance!
That depends on where and how you deploy the application. If you're using a vps or similar solution that gives you access to the file system, you can:
Write outside of the project directory, in a completely unrelated place.
Write in a hidden directory inside the project dir. So, next to .meteor, but only inside another folder that begins with a . (like .uploads).
Whether or not this will work may depend on your platform.
Related
I want to ask on how can I host my react app. It is a 3d product configurator.
I tried to host it on AWS Amplify but the 3d models doesnt load
If you want to host an application on aws amplify you have to create a build version of your app (assuming that it works already without any start issues meaning that you have a functional react app created with the command npx create-react-app).
Usually your react app runs on local host and it's basically like a test/development version of your app. When you take it into aws it really wants a build version of your app. The build command will generate everything you need for this. Navigate to your react application folder and
Run the command
npm run build
This will create a folder that you can send to aws amplify.
When you go to the aws amplify site it'll ask you if you would like to build a website or host a website.
Select host and then it'll ask if you would like to push it from a repository like github. For now lets just skip it and keep the deployment as simple as possible. Deploy without git for now.
Next, we want to click on drag and drop so that you can manually select the file build folder that your npm run build command generated.
Look for the build folder that was generated and drag that folder into the aws area. You don't actually have to click the 'choose files button'. Sometimes the box glitches and won't let you drag anything outside of the box. So what you can do is just open up your directories and manually find that build file in your folders. Drag it from there to the aws zone at the bottom of the screen.
Give your AWS app a name and env name.
From there you can deploy. Once you deploy it'll give you a site address. Also before you make your build, be sure that all of the packages you need are installed. I had an issue where my axiom commands were not working because I had not installed it prior to pushing my build.
So if your project depends on a certain npm package to run your .gltf files make sure that it is installed on your application. You should see it inside the node modules folder (in your apps local directory not the aws one).
I think AWS uses the node modules folder to generate everything your project needs (But I am not 100% sure of this). But it didn't work prior to me installing the package and pushing the build folder again to aws via drag and drop.
There are better ways to do this but this is what worked for me! Hope this helps to at least get your site up and running. Also hope it helps with any package issues that might have been happening with your 3d models. This is about as far as I can take you. Good luck!
I have two webapps - "manager" and "viewer" - coded in separate VSCode projects. These are deployed to a common Firebase project where they share a common database. The "manager" webapp is used to maintain the database and the "viewer" provides public read-only access.
To create the "page" structure I have added a robocopy to React's build script for each VSCode project to produce a structured "mybuild" folder with the page subfolder within it. Firebase.json's "public": setting is then used to deploy from "mybuild".
Individually the two pages work fine, but each deployment overrides the functionality of the other. So, following the deployment of "manager", webapp/viewer returns a 404 (not found) error and vice versa.
To cut a long story short, the only way I've found around this is to manually copy the results of a deployment for one project into the "mybuild" folder of the other and then deploy from this. But this is no way to proceed.
I think I've taken a wrong turn somewhere here. Can anyone suggest the correct "firebase solution" for this requirement? In the longer term I'd like the viewer webapp to be available at the root of some user-friendly "appurl" while the manager is accessed via "appurl/manager", but other arrangements would be acceptable. The main issue right now is finding a simple way of maintaining the arrangement.
I needed to fix this fast, so here's my own answer to my question.
It seems that when you deploy a project, firebase replaces the current public folder for your URL with the content of whatever folder is specified in your firebase.json. So I decided that I had to accept that whenever either of my projects was deployed it must deploy from a "composite" folder that contains the build files for the other project as well as its own build.
That being the case, it seemed I was on the right lines with my "manual copy" approach and that what I now needed to do was simply to automate the arrangement.
Each of my projects now contains a script file with the following pattern:
npm run build
ROBOCOPY build ./composite/x /E
ROBOCOPY ../y/build ./composite/y /E
firebase deploy --only hosting
In each script, x is the owner project and y is the other. Additionally, firebase.json in each project is edited to deploy from composite.
When I run the script for a project it first builds a composite folder combining the latest build state for both that project and its partner, and then deploys the pair.
The final twist is to tell the react build process that the result is to be deployed from a relative folder and so that the build therefore also needs to use relative references. I do this by adding a
"homepage": "https://mywebapp/x",
to the package.json for each project. Here, x is the name of the project.
I'm not able to convince myself that there's not something wrong with my whole approach to this issue, but at least I have a fix for the immediate problem.
I'm working on an old react project, which I need to add functionality to, but when deploying the react build on the server, it fails, claiming it cannot find several css and js files, although I published all files within the build folder. I tried different things:
First, I kept the old service-worker.js in the production folder the IIS uses, but replaced everything else.
Then, I tried also deleting the service-worker.js, since I thought it was optional, and my npm run build didn't create a service-worker.js file.
Then, I tried copying the service-worker.js file that existed on production, and manually changing it to point to my css and js files in the /static/ folder of my build folder.
All of these solutions have yielded the same result. So I have a few questions:
Is the service worker necessary? If not, could this error relate to something entirely different other than the service worker?
If it is necessary, why could my npm run build command not create the service worker with the rest of the files in the build folder?
If I do need it, how can I manually add it to a project that already exists?
If the production folder already had a service worker, and my build is not building it, I can also assume maybe my react version is newer, but I find that odd, since the computer I use is one an older employee in my company used, and I didn't manually change anything about this project.
I'm developing an app locally using Go and React with a project structure that looks somewhat like this:
/reactApp
/main.go
/api
/reactUI
While I am developing locally I am using the gcloud cli tool to run the Go code, and I'm using Node to run the UI. I need to handle CORS of course, but otherwise this works fairly well. The problem is there are too many files in the /reactUI directory for the gcloud cli tool to monitor them all. This means I need to manually start and stop the server every time I make a change to the Go source code.
The reactUI directory was created using the 'npx create-react-app' command. Since I'm running the react part of this app locally using node (and that handles file monitoring and auto-updating just fine), how can I get the gcloud tool to ignore the reactUI directory?
Basically I just want the gcloud tool to monitor the API part of the app, and not the UI part. If I make a change to the API part of the app the gcloud local server should automatically recompile and restart.
With https://issuetracker.google.com/issues/35895450 fixed the development server is supposed to not monitor changes in the files/directories matching the patterns specified in the skip_files section of the app/service's .yaml file.
So you can try to add a skip_files section to the go app's .yaml file specifying the patterns for the files/directories you want ignored. Be careful to also add the default patterns (otherwise you'd lose them).
I have recently started with programming, and I've just purchased a reactJs template, and the content comes ordered within folders named src, public and build; can you explain to me the reason of those folders? How does a web app work with those folders?
I ask this because I believe those names for folders are a de facto standard in web app coding.
Here's a simplistic rundown:
public means the web accessible root of the site. Basically whatever is in that folder can be opened from browser address bar. Server won't provide user access to files outside public
build is where compiled version of assets are placed when you run npm build. This is what will get delivered to user
src (short for "source") contains your working files that will be used later to create the build