[HectorRamos]

It's not too difficult to create a new column that new clients understand, and use beforeSave to propagate updates to this column back to the older columns that earlier clients depend on. I'm not sure I understand the purpose of the "afterRead" hook and how it would help with this use case.

- "If it is the case that afterSave does not block a save, then the documentation is pretty poor around this. My understanding is that afterSave and beforeSave are both required to complete before you'll get a return value from saving an object. If this is not the case, I suggest making this clearer in the docs."

I was wrong earlier. A client will not get a response until an afterSave completes execution. What I should have pointed out is that ongoing http requests to external endpoints will not block the afterSave from returning. As such, you can still use Mailchimp in this case without worrying that a client will be blocked. Of course, you will want to avoid blocking the afterSave on the third party network request (e.g. adding on to the promise chain), which should not be a problem if this is truly a fire-and-forget operation.

- "At the point where you are using Webhooks like this, the advantages of Parse disappear entirely."

I think you're not giving the client-side SDKs enough credit here. Server side business logic is only one part of the equation. With Parse, you also get a data browser, analytics, push notifications, and probably most important of all, a database.

- "It's not cloning a DB that's the problem -- it's programatically updating schema so that I can deploy schema changes to my staging environment and then deploy the matching set of schema changes to prod environment, automatically. This is not possible without a bunch of scripting. And, obviously, there is no easy way to mass-migrate parse objects to a new schema either."

This feedback seems contrary to your earlier ask for a way to script Config variable updates. :) There's the Data Browser for UI based manipulation, there's a Schema API for programmatic manipulation, and there's a dedicated schema migration setting. You can use any of these approaches as needed, and depending on how much scripting you wish to do.

- "This needs to be better documented. Google searches bring up results where people are constructing pointers via JSON and this was indicated to be "the right way to do things""

Adding Parse objects to pointer fields is documented in all of the guides. createWithoutData is an alternate constructor that can be useful when creating pointers explicitly, but it's not the only way of creating a pointer. The link I posted is straight from the API Reference docs.

- "If I want to mass-import data into my system, I'm at the mercy of system timestamps. There are no options to fix this."

These two fields, as well as the object id, can be set to arbitrary values as part of a JSON import. Otherwise, you would not be able to import data exported from another Parse app.

[mmastrac]

- "I was wrong earlier. A client will not get a response until an afterSave completes execution. What I should have pointed out is that ongoing http requests to external endpoints will not block the afterSave from returning. As such, you can still use Mailchimp in this case without worrying that a client will be blocked. Of course, you will want to avoid blocking the afterSave on the third party network request (e.g. adding on to the promise chain), which should not be a problem if this is truly a fire-and-forget operation."

Honestly, this is part of the problem with Parse. It's a big, black box where the documentation doesn't _actually_ dig into the cases that are really important. For a big, black box the documentation really doesn't step up to where it needs to be.

So some stuff blocks afterSave, and some stuff doesn't. Does saving another object from afterSave block a save? What about the nested triggers on that other object? Why isn't that documented anywhere?

- "Adding Parse objects to pointer fields is documented in all of the guides. createWithoutData is an alternate constructor that can be useful when creating pointers explicitly, but it's not the only way of creating a pointer. The link I posted is straight from the API Reference docs."

I've never seen a reference to this, despite repeated Googling.

Open the JS developer's guide. The doc for"createWithData" says that it creates a "reference" to to an object. OK, that's a synonym for a pointer, well... sort of. Let's look at the actual method example:

  Creates a reference to a subclass of Parse.Object with the given id. This does not exist on Parse.Object, only on subclasses.

  A shortcut for:

   var Foo = Parse.Object.extend("Foo");
   var pointerToFoo = new Foo();
   pointerToFoo.id = "myObjectId";

So, there's no example of how this actually can be used to set a pointer value as a field. I'm expected to guess that this "reference" can be set to a field of type "pointer". And apparently I can create a pointer just by creating a new object? What? Where's that documented?

Instead we Google for "parse set pointer" and this page comes up:

https://www.parse.com/questions/javascript-api-set-and-creat...

"That format, {"_type":"Pointer","className":"User","objectId":"asdadsasd"} is what is considered a Pointer object. That is the recommended method"

[HectorRamos]

- "So some stuff blocks afterSave, and some stuff doesn't. Does saving another object from afterSave block a save? What about the nested triggers on that other object? Why isn't that documented anywhere?"

This has long been documented here: https://parse.com/docs/js/guide#cloud-code-resource-limits

- "I've never seen a reference to this, despite repeated Googling." ... "Instead we Google for "parse set pointer" and this page comes up:"

It sounds like you're leaning a lot on Google searches bringing up two year old questions. There's a massive archive of questions from the last 3 years, around 10,000 on my last count. Going back through every single comment and answer to make sure they're still accurate would be a huge undertaking, and a year ago we stopped using those archived questions.

I highly recommend reading through the entire documentation for the platform you're working on, as well as the API Reference for your SDK. You can find both at https://parse.com/docs. I think now is a good time to point out we're also accepting pull requests against our Docs[1]. We welcome diffs that make the docs clearer for everyone.

[1]: https://github.com/ParsePlatform/Docs

[mmastrac]

We can continue to debate the flaws in the documentation back-and-forth for ages, but there's not much point in it and that doesn't help with the glaring fundamental problems that have caused a company a lot of grief.

I appreciate your responses, but I'm done here.