Set up functionality for posting messages to groups about ati-broadcastapp HOT 12 CLOSED

This should include how to handle error conditions per our conversation the other night. I can create a separate to-do if necessary for the wires/flows required.

from ati-broadcastapp.

At the current moment, I will set it up to just specify the result, i.e. success, failure + retry, failure for x number of groups + rety. But I think you/I/we should decide how it "should" work.

from ati-broadcastapp.

So regarding integration:
This doesn't need to be set in stone anytime soon.
First of all, as I noted in TECHNICAL.md, we should communicate via JSON, roughly using the Google JSON Style Guide.

My basic idea of how communication will work

New message request (ignoring any validation issues) as POST to /api/new-message:

{
  "state": STATE,
  "message": MESSAGE
}

New message response on success

{
  // response id. not sure if necessary
  "id": ID,
  // successful parts of message
  "data": {
    // number of successful posts
    "numGroups": NUMGROUPS,
    // message ID
    "id": MESSAGEID,
  },
}

New message response on some error

{
  "id": ID,
  // successful parts of message
  "data": {
    // number of successful posts
    "numGroups": NUMGROUPS,
    // message ID
    "id": MESSAGEID,
  },
  "error": {
    // http code for response. probably 401 or something.
    "code": CODE,
    "errors": [
      {
        // error as code name
        "reason": REASON,
        // human readable error message
        "message": MESSAGE
        // number of groups affected
        "numGroups": NUMGROUPS
        // only if server will retry message. estimated completion time
        "completionTime": COMPLETIONTIME
      },
      // additional errors here
    ]
  }
}

There is a question here of how much info to send back to the client

Thoughts?

from ati-broadcastapp.

My question would be if there is a message fail to 1, or more, groups would the only thing we send back be the numGroups affected and keep track of the failed messages from this user in Mongo so when they retry it just tries to resend those that are flagged as failed in the database?

from ati-broadcastapp.

Yeah, that's what I'm thinking at the moment. Do you think the group ID should be sent? We can do that too. Just add a "groups" element with a list of the group ID's. Is there something else that should be added?

There may need to be adjustments to this mechanism. E.g., I have to see how long it takes to post to many groups and if there are concerns about the client disconnecting in the meantime. I can come up with some other possible adjustments that might eventually be necessary! But let's see how this works.

from ati-broadcastapp.

I would think a group ID would need to be sent along with the response, that way if a post fails to a group we already know which group it was, we could just make a queue of the failed messages that get sent back to node to try again.

from ati-broadcastapp.

I tend to think the backend should keep track of which, if any, groups to retry, and that a request to retry should be mostly binary: retry or not. My thought is that, if we are sending the group ID's in the response, it should be mostly for informational purposes. But there's no harm in doing so.
If we want to send groups, perhaps, in my above spec, we replace "numgroups": NUMGROUPS with "groupIds": ["GROUPID1", ...]?

from ati-broadcastapp.

Hey guys,
Just to make sure - we are storing the group IDs with the specific messages correct? We want to be able to let folks know which groups were not successful (in that condition) and should also be mindful of logging/traceability of posts as well.
Thanks

from ati-broadcastapp.

Yes. This is only about what the backend will send to the requesting user. When I finish writing up the spec for the DB, you will see there that the DB will hold a pretty thorough record of all transactions.

from ati-broadcastapp.

I have outlined my proposed DB structure for storing posted message info in PR #26 . [I don't expect you to necessarily read them but it outlines my ideas]. I think it provides for pretty thorough logging.

from ati-broadcastapp.

I wanted to make a few small change to the earlier design.

1. The Google JSON style guide states that a document should contain either data or error. Thus, I've changed 'data' to 'successGroups', which has a list of all successfully updated groups, since that key will always be present (even if empty)
2. I've removed id from the response, replacing it with broadcastId, broadcastOperationId. These are taken from the way I am structuring the message backend.
   I've updated PR #26 with this documentation. It doesn't mean it's set in stone or anything, just that it's what I'm currently working off of.

from ati-broadcastapp.

This was resolved by 1b167ef

from ati-broadcastapp.