The idea is to make hard of hearing peoples lives a little bit easier. You can turn speech to text, text to speech and in the future asl to speech or text.
To get started, clone this repo, then run
npm install
to install the project and its dependencies.
You will also want to install postgres locally, and provision postgres when you deploy remotely.
To seed the database, run
npm run seed
The source code comes with several scripts defined in package.json
.
The high level scripts are:
to start dev mode, serving up on localhost:8080 with webpack watching for changes:
npm run start-dev
To run tests while watching the code:
npm run test-watch
If you want to run the server and/or webpack
separately, you can also
npm run start-server
and npm run build-client
.
To manually deploy to Heroku, npm run deploy
. See below for more details on setting up the deploy script.
This project uses Node.js and Express for the server, Sequelize as an ORM to talk to a Postgres database, React for display components, and Redux for managing state on the front end.
This project uses the Twelve Factor App design principles. To quote the author, Adam Wiggins:
I'm the author of 12factor (although really it is an aggregation of the work and insights from many people at Heroku). It continues to surprise and please me that this piece continues to be relevant eight years later—a virtual eternity in software/internet time. Fun fact: I debated whether to call it "the Heroku way" or somesuch. Glad I went with a standalone name, feel like that allowed it to take on a life beyond that product. For example I doubt Google would have wanted a page about "Heroku Way app development on GCP" in their documentation. :-)
We deployed to Heroku, but the same DevOps principles would have allowed us to deploy to AWS, Google Cloud, Microsoft Azure, or another cloud computing service.
Here is how to bind configuration variables to the environment. In Heroku, or in Google OAuth, you will have to add the correct values, which are specific to that environment.
- Create a file called
secrets.js
in the project root - This file is listed in
.gitignore
, and will only be required in your development environment - Its purpose is to attach the secret environment variables that you will use while developing
- However, it's very important that you not push it to Github! Otherwise, prying eyes will find your secret API keys!
- It might look like this:
process.env.GOOGLE_CLIENT_ID = 'hush hush'
process.env.GOOGLE_CLIENT_SECRET = 'pretty secret'
process.env.GOOGLE_CALLBACK = '/auth/google/callback'
When you deploy your application to Heroku you need to set these values as configuration variables in your heroku app.
- To use OAuth with Google, complete the steps above with a real client ID and client secret supplied from Google
- You can get them from the Google APIs dashboard.
- Don’t forget to add your callback URI for both your development environment (localhost:...) and well as for your deployed environment (heroku....) as authorized URLs in the application dashboard for your google project
We used Prettier with reasonable defaults, and automated ESLint running on commit to git.
Users who browse be-my-ears have the option of creating an account, via email signup or Google OAuth.
Database interactions were handled via an ORM, Sequelize. The app used three models, Users, Images, and Videos, and the associations between them.
- Set up the Heroku command line tools
heroku login
- Add a git remote for heroku:
- If you are creating a new app...
heroku create
orheroku create your-app-name
if you have a name in mind.heroku addons:create heroku-postgresql:hobby-dev
to add ("provision") a postgres database to your heroku dyno
- If you already have a Heroku app...
heroku git:remote your-app-name
You'll need to be a collaborator on the app.
NOTE that this step assumes that Travis-CI is already testing your code.
Continuous Integration is not about testing per se – it's about continuously
integrating your changes into the live application, instead of periodically
releasing new versions. CI tools can not only test your code, but then
automatically deploy your app. This is known as Continuous Deployment.
Boilermaker comes with a .travis.yml
configuration almost ready for
continuous deployment; follow these steps to the job.
- Run the following commands to create a new branch:
git checkout master
git pull
git checkout -b f/travis-deploy
- Run the following script to finish configuring
travis.yml
:npm run heroku-token
This will use yourheroku
CLI (that you configured previously, if not then see above) to generate an authentication token. It will then useopenssl
to encrypt this token using a public key that Travis has generated for you. It will then update your.travis.yml
file with the encrypted value to be sent with thesecure
key under theapi_key
. - Run the following commands to commit these changes
git add .travis.yml
git commit -m 'travis: activate deployment'
git push -u origin f/travis-deploy
- Make a Pull Request for the new branch, get it approved, and merge it into the master branch.
NOTE that this script depends on your local origin
Git remote matching
your GitHub URL, and your local heroku
remote matching the name of your
Heroku app. This is only an issue if you rename your GitHub organization,
repository name or Heroku app name. You can update these values using
git remote
and its related commands.
There is a procedure to complete the above steps by installing the official Travis CLI tools. This requires a recent Ruby, but this step should not be, strictly speaking, necessary. Only explore this option when the above has failed.
That's it! From now on, whenever master
is updated on GitHub, Travis
will automatically push the app to Heroku for you.
Your local copy of the application can be pushed up to Heroku at will,
using the npm run deploy
script mentioned above.
- Make sure that all your work is fully committed and merged into your master branch on Github.
- If you currently have an existing branch called "deploy", delete
it now (
git branch -d deploy
). We will use a dummy branch with the namedeploy
(see below), so and the script below will error if a branch with that name already exists. npm run deploy
_ this will cause the following commands to happen in order: _git checkout -b deploy
: checks out a new branch calleddeploy
. Note that the namedeploy
here is not magical, but it needs to match the name of the branch we specify when we push to ourheroku
remote. _webpack -p
: webpack will run in "production mode" _git add -f public/bundle.js public/bundle.js.map
: "force" add these files which are listed in.gitignore
. _git commit --allow-empty -m 'Deploying'
: create a commit, even if nothing changed _git push --force heroku deploy:master
: push your localdeploy
branch to themaster
branch onheroku
_git checkout master
: return to your master branch _git branch -D deploy
: remove the deploy branch
Now, you should be deployed!
Why do all of these steps? The big reason is because we don't want our
production server to be cluttered up with dev dependencies like
webpack
, but at the same time we don't want our development
git-tracking to be cluttered with production build files like
bundle.js
! By doing these steps, we make sure our development and
production environments both stay nice and clean!
It is also possible to set up Continuous Deployment from updates to master on Github.