Add a Heroku Button

[mattcreager]

[gfosco]

Cool... but I think this should also accept some configuration options for appId, masterKey, etc.

[mattcreager]

@gfosco Should we just support all the config?

[mattcreager]

@gfosco I've added support for APP_ID, MASTER_KEY, and REST_API_KEY .. any others worth dropping in?

[gateway]

great news guys that you are on it. I would give an example after its all set up how to make a test call and see example data returned or some sample test scripts..

Another thing would be to run benchmarks on the various server sizes and maybe use Jmeter/Blazemeter to define a request per second sort of baseline. A lot of the people are used to how parse did their billing with the slider and would want to know if I have this server this is what I can expect the throughput to be since many people never had to build their own backend.

big missing link though is push notifications..

[gateway]

Oh, another thing is how are files stored, I believe parse saved their files in s3 buckets and linked them in the db.. Looking at their migration docs they have this in

fileKey: A key that specifies a prefix used for file storage. (only necessary for old files in s3 clarify this)

[gateway]

Sorry and lastly we prob need more keys to set up see their example listed here.

var api = new ParseServer({ databaseURI: 'mongodb://your.mongo.uri', cloud: './cloud/main.js', appId: 'myAppId', fileKey: 'myFileKey', masterKey: 'mySecretMasterKey', clientKey: 'myClientKey', restAPIKey: 'myRESTAPIKey', javascriptKey: 'myJavascriptKey', dotNetKey: 'myDotNetKey', });

• databaseURI: Connection string URI for your MongoDB.
• cloud: Path to your app’s Cloud Code.
• appId: A unique identifier for your app.
• fileKey: A key that specifies a prefix used for file storage. (only necessary for old files in s3 clarify this)
• masterKey: A key that overrides all permissions. Keep this secret.
• clientKey: The client key for your app.
• restAPIKey: The REST API key for your app.
• javascriptKey: The JavaScript key for your app.
• dotNetKey: The .NET key for your app.

so it would be good to be able to fill these out upon provisioning and be able to change them, esp the master key because if someone hacks an app they can do a lot of damage and you would want to be able to easily change this value.

[mattcreager]

@gateway Thanks for your feedback! I've added what I believe are the core config vars -- happy to add more. You make good points re. Push and S3, I could also use some clarity there, perhaps open an issue?

Also - The express-server-example does include a sample request, you'd just need to update the endpoint to reflect *.herokuapp.com.

[mattcreager]

@gateway oh and, updating any of the Config Vars would be trivial -- just visit your app on Heroku.. settings > config vars .. edit away -- the nice thing about that being that it will generate a new release for you application, so if you make a mistake you can quickly roll-back.

[gfosco]

restAPIKey shouldn't default to a value as it is optional and enforces keys on every request if set.

[mattcreager]

Gotcha, thanks -- change incoming.

[gateway]

Looks like they use gridstore for saving images to mongo.. I could of swore I saw aws links in our images but never the less here is the code

https://github.com/ParsePlatform/parse-server/blob/master/GridStoreAdapter.js

filesAdapter - The default behavior (GridStore) can be changed by creating an adapter class (see FilesAdapter.js)
databaseAdapter (unfinished) - The backing store can be changed by creating an adapter class (see DatabaseAdapter.js)

[gateway]

Oh, another point is which has become much more difficult now is to deal with class level permissions.

Parse server does not include a web-based dashboard, which is where class-level permissions have always been configured. If you migrate an app from Parse, you'll see the format for CLPs in the SCHEMA collection. There is also a setPermissions method on the Schema class, which you can see used in the unit-tests in Schema.spec.js You can also set up an app on Parse, providing the connection string for your mongo database, and continue to use the dashboard on Parse.com.

Here is how they have it in their interface. I'm not suggesting you guys build this out fully but a lot of questions will crop up on how to do this.

http://blog.parse.com/learn/secure-your-app-one-class-at-a-time/

This is pretty important because you dont want some roles/users to be able to change values and such..

[gateway]

As far as push notifications I think this company has been around the longest.. https://www.urbanairship.com/products/engage I personally never used it and we rolled our own on our last app.

Amazon has SNS but it just takes the device tokens that are imported into their system and then allows you to connect via an api to push our messages to users.. https://aws.amazon.com/sns/ this is the part to push whats missing is the server/service that triggers a push and builds custom or tokenized messages to users.

Here is an open source one running node.js I have never tested it.. https://aerogear.org/docs/specs/aerogear-unifiedpush-nodejs-client/

Also note at least for iOS in the Parse iOS SDK you can enable push and if the user accepts that, it saves the apple device token to the installation class in the mongo database. Ideally these could be migrated into SNS or some other service how ever triggering what types of pushes you want is more difficult. Its probably worth just logging into parse and seeing how they set up their system but I believe right now this is out of the scope of dev and would require quite a bit of code along with api endpoint and the service to connect to apple's or googles server to push out notifications.

[mattcreager]

@gfosco, @gateway I've dropped in lodash, and made all of the configuration (I think) available via. config vars.. but not via the Heroku Button deploy -- I've kept that simple, and quick.. It's so easy to add config vars after it's been deployed I don't think it's worth making the form a mile long.

[gateway]

The permission per class is pretty important, maybe someone will build a front end UI for this..

Any chance I could test it and provide feedback?

[gfosco]

@mattcreager I get the intent behind adding Lodash and using the defaults, but I think it really bloats the sample and makes it harder to understand at a glance... Can you remove that and continue the initialization method originally used?

[mattcreager]

@gfosco sorry, got carried away :)

[gateway]

Can we test deploy this yet?

[gfosco]

Woo! Thanks @mattcreager ! 👍

[gateway]

Just fyi, they pushed a lot of changes today, exp being able to save your pffiles to s3 bucket which I prefer to have over keeping them in a database.. Im gonna test out the latest version .. cheers

[gateway]

Hey Guys I did some simple benchmarking today with a Jmeter script , just does a POST and a GET of the object created and I also used apache benchmark... From the looks of the data I'm seeing pretty high response times from the results.. I'm not sure if its the connection between you guys and MongoLab or the small free dyno im running.. here are some of my findings.. Any thoughts? https://groups.google.com/forum/#!topic/parse-developers/puldzNyFEGs