This is a continuation of a series of articles on
crowdsourcing application and including the most recent article. The original problem statement is included
again for context.
Social engineering applications provide a wealth
of information to the end-user, but the questions and answers received on it
are always limited to just that – social circle. Advice solicited for personal
circumstances is never appropriate for forums which can remain in public view.
It is also difficult to find the right forums or audience where the responses
can be obtained in a short time. When we want more opinions in a discrete
manner without the knowledge of those who surround us, the options become fewer
and fewer. In addition, crowd-sourcing the opinions for a personal topic is not
easily available via applications. This document tries to envision an
application to meet this requirement.
The previous article continued the elaboration on
the usage of the public cloud services for provisioning queue, document store
and compute. It talked a bit about the messaging platform required to support
this social-engineering application. The problems encountered with social
engineering are well-defined and have precedence in various commercial
applications. They are primarily about the feed for each user and the
propagation of solicitations to the crowd. The previous article described
selective fan out. When the clients wake up, they can request their state to be
refreshed. This perfects the write update because the data does not need to be
sent out. If the queue sends messages back to the clients, it is a fan-out
process. The devices can choose to check-in at selective times and the server
can be selective about which clients to update. Both methods work well in
certain situations. The fan-out happens in both writing as well as loading. It
can be made selective as well. The fan-out can be limited during both pull and
push. Disabling the writes to all devices can significantly reduce the cost.
Other devices can load these updates only when reading. It is also helpful to
keep track of which clients are active over a period so that only those devices
get preference.
Any cloud service or application is not complete without
manageability and reporting. The service/application can choose to offer a set
of packaged queries available for the user to choose from a dropdown menu while
internalizing all query processing, their execution, and the return of the
results. One of the restrictions that comes with packaged queries exported via
REST APIs is their ability to scale since they consume significant resources on
the backend and continue to run for a long time. These restrictions cannot be
relaxed without some reduction on their resource usage. The API must provide a
way for consumers to launch several queries with trackers and they should be
completed reliably even if they are done one by one. This is facilitated with the help of a
reference to the query and a progress indicator. The reference is merely an
opaque identifier that only the system issues and uses to look up the status.
The indicator could be another api that takes the reference and returns the
status. It is relatively easy for the system to separate read-only status
information from read-write operations so the number of times the status
indicator is called has no degradation on the rest of the system. There is a
clean separation of the status information part of the system which is usually
periodically collected or pushed from the rest of the system. The separation of
read-write from read-only also helps with their treatment differently. For
example, it is possible to replace the technology for the read-only separately
from the technology for read-write. Even the technology for read-only can be
swapped from one to another for improvements on this side.
The design of all REST APIs generally follows a convention.
This practice gives well recognized uri qualifier patterns, query parameters
and methods. Exceptions, errors and logging are typically done with the best
usage of http protocol.
No comments:
Post a Comment