CODEWITHSUNDEEP
javascriptjqueryparse-platform
goodson
goodson

Reputation: 757

Parse.com cloud app with client javascript production and development keys

I'm really enjoying learning about web development with Parse.com. I have a cloud app that serves jade templates and a few cloud functions that I'd like to call from .js in the browser.

I'm trying to setup for development and production using the parse docs here, but I've become confused. It's my understanding that I'll have one source tree on my development machine, but two parse applications that I'll deploy to alternatively as development and production.

It seems using the command line parse add <alias> will add credentials to my config/global.json file, but what about my statically served .js files that need to make cloud calls? They start out:

Parse.$ = jQuery;
Parse.initialize("my app id", "my app js key");

If I have only one code repository, I'll have to touch these keys before I deploy to production. That can't be right, can it? If I forget, I'll deploy a broken app. Am I mixed up, or is this just something I must deal with?

Upvotes: 2

Views: 750

Answers (3)

yuvilio
yuvilio

Reputation: 4185

Similarly, to separate our environments we deployed a Parse app for each one needed (say dev, qa, prod) and used the different resulting urls (the subdomain, but really any different part can do) to tell them apart and discover our environment in the code. We then stored the environment in an attribute.

var APP_ID, JS_KEY;
switch(location.host.split(".")[0]){  //Figure out environment off of the url (subdomain here)
    case 'myappprod': //ex: myappprod.parseapp.com
        MyApp.env = 'prod'
        APP_ID = 'theprodappid';
        JS_KEY = 'theprodjskey';
        break;
    case 'myappqa':
        MyApp.env = 'qa'
        APP_ID = 'theqaappid';
        JS_KEY = 'theqajskey';
        break;
    default: //otherwise dev
        MyApp.env = 'dev'
        APP_ID = 'thedevappid';
        JS_KEY = 'thedevjskey';
        break;
}

You can also hint at the environment (app) you want to use in your local setup using this same technique. Just have the virtual host you use with your web server match all three local urls. For example, with nginx:

server_name myappdev.parseapp.dev myappqa.parseapp.dev myappprod.parseapp.dev;

Upvotes: 0

goodson
goodson

Reputation: 757

In case anyone else has this problem, here's what I did (thanks to @Kenneth for suggesting). The script first checks to see if git has any un-staged changes. It refuses to run unless I've checked in all the changes.

Then it replaces all my dev ids/keys in .js files with production versions, deploys to my parse production app and finally restores .js files to contain their development keys...

#!/bin/bash

if git diff-index --quiet HEAD --; then
    echo 'Replacing app id and js keys with production keys'
    sed -i '' 's/my-development-app-id/my-production-app-id/g' ./public/*.js
    sed -i '' 's/my-development-js-key/my-production-js-key/g' ./public/*.js

    parse deploy production
    echo 'Changing back to development keys'
    git checkout *.js
else
    echo 'Must commit all changes before deploying to production'
fi

Upvotes: 0

Kenneth
Kenneth

Reputation: 28737

For a given session you only need to initialize Parse once. This means that you can do this when the browser loads from a single location.

You could create some sort of build script that modifies the keys.

Alternatively, on load, make a call to a seperate service which holds your keys and which returns the correct key depending on your environment.

Upvotes: 1

Related Questions