Basically I don't want to use an existing mongodb database site like the official mongocloud or whatever-- how can I do what they do, but myself? Do I just include the database folder, along with all of the mongodb executable, in my nodejs folder and call require("child_process").spawn("mongodb.exe", /insert params here/), or is there some kind of way to do this in the mongo module?
And also do I need my own virtual machine to be able to do this or can the following work on a standard heroku nodejs application for example?
Anyone?
Heroku's hosting solution has only ephemeral volumes, so you can't use it for a database. Any files you create are temporary and will be purged on a regular basis.
For example, when your application is idle Heroku will de-provision that resource and clear out any data you've left there.
You can't use Heroku like this, you must use an external database service, or one of their many add-on offerings.
Related
Ive made a database from sqlite and i uploaded that with my github to Heroku but its only getting the data from the database and not changing it. No errors, just not working. When i am testing it on my pc it works fine.
I'm not sure why you're only able to get data and not change it. If you can share an example of how you're getting and setting, I might be able to help you get it going temporarily.
I learned, however, that SQLite only offers temporary storage on Heroku:
Why is SQLite a bad fit for running on Heroku?
Disk backed storage
SQLite runs in memory, and backs up its data store in files on disk. While this strategy works well for development, Heroku’s Cedar stack has an ephemeral filesystem. You can write to it, and you can read from it, but the contents will be cleared periodically. If you were to use SQLite on Heroku, you would lose your entire database at least once every 24 hours.
Even if Heroku’s disks were persistent running SQLite would still not be a good fit. Since SQLite does not run as a service, each dyno would run a separate running copy. Each of these copies need their own disk backed store. This would mean that each dyno powering your app would have a different set of data since the disks are not synchronized.
Instead of using SQLite on Heroku you can configure your app to run on Postgres.
I then followed their instructions for setting up Postgre. It's worth reading through the instructions, but the gist of it to use the Heroku CLI:
From the section Provisioning Heroku Postgres:
"Use the heroku addons command to determine whether your app already has Heroku Postgres provisioned"
If heroku-postgresql doesn’t appear in your app’s list of add-ons, you can provision it with the following CLI command: heroku addons:create heroku-postgresql:hobby-dev
As of writing, the hobby tier is free. Read about plans here.
This command adds an environment variable to your project named DATABASE_URL.
I'm using keyv by Luke Childs. I installed its companion #keyv/postgres. (I also uninstalled my sqlite stuff.)
I used the newly added DATABASE_URL environment variable to wire into the keyv steps linked above:
const Keyv = require('keyv');
const keyv =
process.env.NODE_ENV !== "production"
? new Keyv()
: new Keyv(process.env.DATABASE_URL);
I haven't found the best solution yet for developing/testing Postgre locally. Heroku Postgre requires SSL for connecting remotely (when your app is running locally). In the code block above, you'll see that I'm initializing Keyv without a database while developing locally (new Keyv()).
From here, if I need to verify the DB storage, I can set up a PostgreDB for developing locally, but I also imagine that it's possible to connect to the Heroku Postgre using SSL. If you or anyone has a solution they like for this step, please let me know.
#T. Rotzooi, I'm three months late to your question, but perhaps this explanation could help future people. I haven't found any other resources discussing this issue that you and I both encountered.
I have a server deployed on Heroku through Heroku auto deployment method from GitHub. On that server I have a file named subscription.json which contains user data whenever user is registered. I want to see that file.
How can I access that file?
If that file is in your repository you should be able to read it like any regular file.
However, this isn't going to work on Heroku:
which contains user data whenever user is registered
Heroku's filesystem is dyno-local and ephemeral. Any changes you make to it will be lost the next time your dyno restarts. This happens frequently (at least once per day).
For saving things like user uploads, Heroku recommends using a third-party service like Amazon S3. But in this case I think a database would be a much more appropriate solution.
Heroku has its own PostgreSQL service that is very well supported and available out of the box. If you prefer to use another database there are plenty of options.
I understand that node-mysql can be used for a database with Electron. However, if I build my app, the user will still need MySQL installed on their computer correct? I need a database solution that multiple users of my app can use without having any other dependancies installed. Just my standalone app. Are there any solutions for this?
You can use PouchDB inside your Electron application and set up a remote CouchDB.
PouchDB can work offline inside your application and can synchronize with CouchDB. If you use sync, every time the remote database changes, all connected applications will pull the latest changes to their local database.
Sync will be in two directions (if you want this, otherwise you can use replicate), so when an application makes a database change inside their local PouchDB, it will synchronize this to the remote CouchDB, and all the other applications will also pull this change.
Well, Correct would be to connect your electron app to a remote DB and setup an auth and set up DB behind that. You can also use DB's auth.
or if you can have individual DB per user. You can use Sqlite.
Why there are single web service just for mongodb? Unlike LAMP, I will just install everything on my ec2. So now I'm deploying MEAN stack, should I seperate mongodb and my node server? I'm confused. I don't see any limitation mixing node with mongod under one single instance, I can use tools like mongolab as well.
Ultimately it depends how much load you expect your application to have and whether or not you care about redundancy.
With mongo and node you can install everything on one instance. When you start scaling the first separation is to separate the application from the database. Often its easier to set everything up that way especially if you know you will have the load to require it.
I know that Ruby on Rails has this feature, and in the railstutorial it specifically encourages it. However, I have not found such a thing in nodejs. If I want to run Sqlite3 on my machine so I can have easy to use database access, but postgres in production on Heroku, how would I do this in Nodejs? I can't see to find any tutorials on it.
Thank you!
EDIT: I meant to include Node.JS + Express.
It's possible of course, but be aware that this is probably a bad idea: http://12factor.net/dev-prod-parity
If you don't want to go through the hassle of setting up postgres locally, you could instead use a free postgres plan on Heroku and connect to it from your local machine:
DATABASE_URL=url node server.j
A .env file can make this easier:
https://devcenter.heroku.com/articles/heroku-local#copy-heroku-config-vars-to-your-local-env-file
To switch between production and development Db you use different ports for running you application locally and on Heroku.
As Heroku by default runs the application to port 80 you have a some other port while running your app locally.
This will help you to figure out in run time if your application is running locally or in production and you can switch the Databases accordingly.
You could use something like jugglingdb to do this:
JugglingDB(3) is cross-db ORM for nodejs, providing common interface to access most popular database formats. Currently supported are: mysql, sqlite3, postgres, couchdb, mongodb, redis, neo4j and js-memory-storage (yep, self-written engine for test-usage only). You can add your favorite database adapter, checkout one of the existing adapters to learn how, it's super-easy, I guarantee.
Jugglingdb also works on client-side (using WebService and Memory adapters), which allows to write rich client-side apps talking to server using JSON API.
I personally haven't used it, but having a common API to access all your database instances would make it super simple to use one locally and one in production - you could wire up some location detection without too much trouble as well and have it automatically select the target db depending on the environment it's in.