Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Virtualize dev environment #36

Open
scott-s-douglas opened this issue Jan 31, 2017 · 5 comments
Open

Virtualize dev environment #36

scott-s-douglas opened this issue Jan 31, 2017 · 5 comments
Assignees

Comments

@scott-s-douglas
Copy link
Contributor

Investigate using vagrant to virtualizeour dev environment for this repo—macOS, Windows, and Linux

@bradreardon
Copy link
Member

@scott-s-douglas these are the questions I have for you, not having made any production apps in Node before:

  1. What stack does a production Node app usually run on? For example, I usually use Django on Python 2.7 using Postgres for DB, and Gunicorn for a WSGI server for serving the application. I remember hearing things about Express but I'm not sure what it does. If you could clarify this, that would be excellent.

  2. Hand-in-hand with number 1, what DB does the SWAPR server run on?

  3. Ideally, in a production environment, how should the client be served? If just serving the application as static HTML is fine, I can do that with a web server like nginx, and we can just host the backend on a separate endpoint of some sort (maybe /api/ or something).

  4. What other prereqs can you think of that I'm not listing below? Anything helps. The system-wide prereqs will be hardcoded into the provisioning playbooks, whereas the application-local stuff will be automatically updated on each "deploy" or update, so for updating Node packages for example, I'll just make sure to run an npm install on each provision/deploy.

Known System-wide Prereqs:

  • Ruby
    • gem
    • sass
  • Node (v6)
    • npm

Known Application-local Prereqs:

  • Anything in the Node package.json
  • Anything from Bower

@stuartf
Copy link
Member

stuartf commented Jan 31, 2017

  1. Express is a web server written in node, so it gets installed by npm, we'll want to proxy requests to it using nginx as that will be better for serving the static assets and doing https
  2. It's currently using sqlite for dev purposes, we'll eventually want to be able to swap in something more scalable for production use
  3. Exactly, static assets served via nginx with a reverse proxy for the /api/ path

@scott-s-douglas
Copy link
Contributor Author

  1. You've listed all of the system-wide prereqs I can think of

@bradreardon
Copy link
Member

@scott-s-douglas

Here's the rest of what I need (I think) from the...

Client dev team:

  1. A way to build the production environment with Grunt where it automatically substitutes the API root for the production API root (currently defined as http://swapr.vip.gatech.edu/api/). In addition, we just need production grunt rules to build a production environment in the dist folder.

Backend dev team:

  1. If we use the above API root, the backend should expect everything to route to /api/something_here
  2. Backend should use production Postgres credentials when installed via production (talk to me about how to specify a different production config file), should be the following: host: 127.0.0.1 / port: 5432 / user: swapr / pass: change_me_and_reprovision_everyone_later / db: swapr_prod

This comment is a work in progress if I find anything else wrong. You can now see the mocked data live at http://swapr.vip.gatech.edu/

Also tasks for next semester, but we may want to contact OIT about getting SSL certificates to secure the SWAPR interface before we do anything live on it.

@stuartf
Copy link
Member

stuartf commented Apr 17, 2017

For the db connection you should be able to set an environment variable DATABASE_URL like postgres://swapr:change_me_and_reprovision_everyone_later@localhost:5432/swapr_prod

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants