express published to heroku but requires .env - express

A while back I set up a heroku app for my express.js API. I set this up so that when I push to GitHub it automatically deploys to heroku. All works fine except for one thing, my secrets. I store them I a .env file and all works fine. Only problem is because they are in my .gitignore they are not pushed to the repo which causes my heroku app to malfunction. This might be a duplicate but I can't find my answer. I would appreciate your help. Thanks in advance!

assuming you checked out this stackoverflow question i would make it a bit simpler by laying out the steps as so:
head on to your project dashboard
go to settings tab from the upper menu
scroll down to config vars and show them
you will find the config input where you can place all your dotenv secrets
and it would look like this

Related

Make nconf (or other) config available to getServerSideProps... should I eject from nextjs cli?

First of all, I know that nextjs has support for .env files... and this is great.
However, I do not wish to write secrets to disk, ever, becuase they might wind up in a docker image in an amazon ecr repo and someday get read by a hacker... so I won't write them to a yaml or a .env file. This is our company policy: we integrate with hashicorp vault.
Now, my idea was to get these secrets, and store them in nconf. Nconf is just a memory-based storage engine for organizing config... nothing special. I had planned to eject from nextjs cli and use a custom express server (with typescript). Fine... I can do that. But it's a little bit of a pain because it seems like people aren't doing that as much as they did 3 years ago when I used nextjs last.
That is probably because they don't want to miss out on the automatic static rendering, and neither do I.
But basically what I want to do is to make a global variable available server-side in nextjs on every page: my nconf config. I want to run things on the server and not in the browser (no secrets in the browser).
For instance... what about middleware? Can I run middleware without setting up a custom express server and ejecting? I feel like we're going to need middleware at some point, we're make an enterprise app. So I'm kind of using nconf as a litmus test. But hey, if there's a good way to handle secrets, LMK.
Am I missing something in the nextjs docs? Are there events or hooks I can tap into? Or is the whole thing kind of "nextjs way or the highway?" Because in that case I will need to eject. (I grew up in Drupal, where there were tons of hooks and you could do what you needed to with the right hook.)
Thanks for your help.

Problem when publishing Nuxt.js app on shared hosting

Okay, I'm trying to publish my Nuxt.js app on my web host but I've run into some issues. I do not want a static site.
After running "npm run build" locally, I transferred the files to my web host with FileZilla. Then I'm supposed to fill in the statements shown in the picture below.
And this is where my problems begin. The app does not want to start at all, and i am nor sure what to put as "Application startup file". And according to my web host, the overall problem is that there is no startup file for Nuxt applications. I am completely new to Nuxt and do not have that knowledge and therefore I now turn to you, is it the case that there is no starup file for Nuxt?
The web host also mentioned that it is more difficult to get a Nuxt application upp and running on shared hosting, is that correct? Will I not be able to get my app up and running in this place?
My web host had received this error message when they tried to start my app. Maybe there are some clues in there to find.
ERROR Request failed with status code 404 15:58:38
at createError ({{my-adress}}/14/lib/node_modules/axios/lib/core/createError.js:16:15)
at settle ({{my-adress}}/14/lib/node_modules/axios/lib/core/settle.js:17:12)
at Unzip.handleStreamEnd ({{my-adress}}/14/lib/node_modules/axios/lib/adapters/http.js:260:11)
at Unzip.emit (events.js:315:20)
at endReadableNT (internal/streams/readable.js:1327:12)
at processTicksAndRejections (internal/process/task_queues.js:80:21)
Hope someone can help!
Without some more context, I can't tell you exactly what your issue is but I suspect it is to do with how the web server on your shared hosting is configured to serve files. When you visit a route, it's not correctly finding that index.html page.
A Nuxt static application deploys with a structure where each page route has its own rendered index.html page inside a folder - if I'm not mistaken.
Your web path may look like example.com/hello but in reality it resolves as example.com/hello/index.html. Some web servers will struggle by default with this structure if not setup correctly.
Honestly, if I were you I'd deploy the project to either Vercel or Netlify.
Both have incredibly generous free tiers that will let you host your application for (if it's not making any money) for a very long time at a good scale.
They both run on automatically scaling infrastructure so you don't need to worry how much resources your site is consuming or how many users you get. It will maintain responsive and reliable without any detriment to load speed.
They'll also automatically handle building and deploying the application on your behalf. All you need to do is connect the service to a Github repository.
They also provide CDN's and other optimisations such as compression for you as well to make your site much faster.
Nuxt has a dedicated page on Netlify deployment. I recommend you give it a read:
https://nuxtjs.org/docs/2.x/deployment/netlify-deployment/
When you do npm run build (or npm run generate), your final content will be available in the /dist directory (the console should tell it to you at the end). It contains an index.html file, this is the one that serves as entry point.
Btw, before going any further double check that this is working locally:
npm run build
npm run start (URL and port will be given to you)
If it works locally, you can proceed.
.nuxt is essentially used for development purposes, caching and so on. And should not be tracked by Git, nor deployed.
I'd like to advice against using FTP for deploys (especially if not secured). Prefer a more modern way, like pushing your latest git commit and let the platform handle the hook or fetching your new code and bundling your app for you.
As recommended above, Netlify is one of the best place to easily host your Nuxt app: simple, fast and headache-free. Also, check #jordan's link about the various platform deployments, you may find yours (if it's good/well known).
I may come here a little late, but this is the way I configure the "Application startup file" when deploying a Nuxt app in shared hosting using the NodeJS Selector app (that commonly you find in CPanel)
Since basically the startup file in NodeSelector is executed as if you would run node startup_file.js, you can create an app.js at the root of the project, and add the following code:
require('#nuxt/cli').run(['start']);
This is basically the same as nuxt start, which is basically the start script in your package.json
Hope this can help others having the same issue. I leave here the same issue posted in git:
https://github.com/nuxt/nuxt.js/issues/7192

Is there a difference in page paths when on localhost verses deployed?

My app is created in next.js and works great in localhost. When I deployed it in heroku, only the front page shows up and all page paths do not work even though they are correctly inputted in the browser. The only page that is connected to the index.js file in my page paths is the front page. Do the other pages need to also be connected to the indec.js file? I am terribly lost with this issue since the site works perfectly in localhost. In heroku every page path besides / has a 404 error. I didn't add any code to this question since no one file seems relevant to the issue. I've been searching all over for an answer to this issue but can't seem to find any relevant information online since the app is deployed successfully it just won't render any file paths besides /.
Thank you in advance for any help you can offer. I really appreciate it!
Applications are ran differently on localhost and when deployed to the server. Since you added react tag on the post, I assume you are trying to deploy react native app on Heroku, there is lots of information on internet how to do it.
For example this post.
Anyway first you need to build your app correctly, so static files would be generated (you didn't mentioned how you are running that app).
To your question:
Relative paths are the same on both local and server, but absolute paths will be different.
But for your 404 error I see that no static content are found on the root path.

Error deploying vue app using any type of deployment

I have only deployed a couple small apps before and I am still newer to deploying apps in general.
I created this app by following a course and have recently finished the project. The course did not provide instructions on how to deploy the app. I have used Firebase hosting a couple times and am also somewhat familiar with Heroku. Regardless, it all seems pretty straight forward after following documentation.
I first tried Firebase hosting since that is what I am most familiar with. Spent some time with that with no luck, then tried heroku, then netlify, then NOW. Every single one of them had issues without any real information on them.
NOW says deployement failed with no logs.
Firebase hosting doesn't seem to be logging any errors, it builds a blank page.
Netlify says page not found after deployment and Heroku was something similar.
I am 100% open to getting this simple app deployed using any approach at all (preferably the easiest one).
Since I am following documentation and there doesn't seem to be any errors being logged, I'm completely stumped and am not sure what to do.
I realize I might not be providing the most helpful information to solve this issue, although I do have my full repo here:
https://github.com/SIeep/austin-pizza
Would anyone be kind enough to look over my repo and see what the issue might be? Or even point me in the right direction?
Please let me know if I need to provide any additional information.
Thanks!
missing entry file or file path problem ?
Try to find out which stage the problem is at first.
Compare this and last successful Firebase Configuration(dependency path),
Compare this and the last build dist file (not detail code,just File structure)
compare webpack.config.js
(app can run well locally,so i think it wouldn't because of the problem with the app's own code)

How to recognize programmatically that application is installed vs development mode?

I'm trying to get information about license info of my app and MSDN docs (http://msdn.microsoft.com/en-us/library/windows/apps/hh694065.aspx) advice to use Windows.ApplicationModel.Store.CurrentAppSimulator class for that purposes during development/testing and when submitting app to store replace that class with Windows.ApplicationModel.Store.CurrentApp.
I wonder if there is any way to check in code (javascript in my case) if app is already installed from store so my code should use proper class and I won't have to remember every time I submit update of app to store to replacing those classes properly.
As far as I know, I could not find such thing. In fact, LicenseInfo is what provides information about the store listing.
I use a config.js file to keep settings at place which change between development and production. For example - if your app talks to a service, service URL also will likely change between development and production; the service might be running at localhost for development and for production in azure environment. I keep a bool in here and change by hand.
I have not automated it fully. but it is likely possible. need to dig through the msbuild logs for the build created for the store. if there is configuration setting found, then project can have two config.dev.js and config.release.js and msbuild need to conditionally pick the right file. I haven't looked into this yet.
I think I found at solution as described here WinJS are there #DEBUG or #RELEASE directives? . Not ideal, but works for me.