 |
| V! Message initial trade inquiry form for Trade To Travel |
The Client’s Need: Communication
One of our clients, Trade To Travel, had an urgent need to allow their members to communicate directly with each other: their staff were overloaded having to act as intermediaries, shuttling queries and clarifications between guests and hosts who were trying to organize trades. Unfortunately, they were not in a position to rewrite their legacy application to support this new feature.
We white-boarded out some ideas about communication flow, and figured we could write a new application using a modern framework and integrate with theirs via minimal read-only access to a few of their database tables. Their team wasn’t comfortable with this since their application was hosted by a private hosting company and ours would reside in the AWS cloud, possibly with no fixed IP they could whitelist.
Integration: Loose-Coupling Solution
We realized there was no point in designing a solution unless we could determine how we could integrate with their application to get the data we needed. At a minimum, we’d need the names and email addresses of the guest and host so we could alert them of trade opportunities and replies, and also some details about the property under discussion. How could we get that without database access? A link from their application to our messaging solution could include all the information we needed — as query parameters or form fields — but this would be sniffable and expose member email addresses; it would also allow spoofing and hijacking of conversations.
After some discussion with their development team, we came up with a loosely-coupled, easy-to-implement way to get the information we needed securely: it only required their developers to implement a single API endpoint, which they were able to do in a couple hours as just another ASP page.
With this resolved, it was fairly straight-forward to implement the application to create new conversations based on trade requests, each of which had any number of queries and replies until a resolution was reached: trade accepted, declined, or cancelled.
How it works
Here we describe how the application works, following the flow the user would experience: first a link on the application page to the V! Message application, integration via back-channel, then a discussion of the conversation flow and resolution.
 |
| V! Message dataflow diagram: click to expand in a new tab |
Integration
A Trade To Travel member authenticates to the application and searches the collection of properties as normal. When they select one, they click a link to “Submit trade request”. This connects to our application (instead of the old email form); it supplies in the URL request parameters only the ID of the member making the inquiry (the guest) and the ID of the property — neither of which is sensitive data.
The V! Message application receives the request and — before displaying anything to the guest — makes a back-channel request to the Trade To Travel application’s new ASP endpoint with the same guest and property ID, and also a shared secret to prevent outside access; this traffic is not sniffable by the guest, it’s server-to-server. The ASP replies with a JSON body which gives us the member’s and property host’s first and last name, and email address, as well as name, location and some other other details of the property. These are stored in V! Message’s own database, but only the member and guest first names are exposed, never their email addresses.
Conversation
V! Message first checks its database to see if there’s an in-progress conversation matching this guest and property ID, and if so, resumes it. It presents a page with the trade request details and conversation so far, and a form to continue the conversation.
If it’s a new query by the guest about this property, we generate a unique conversation ID and redirect the guest to a page for this trade inquiry. It presents a form requesting the desired trade dates, number of adults and children, and so on.
The guest submits the form and V! Message sends an email to the host on behalf of the guest, with a Trade To Travel “From:” address rather than the guest’s own address.
The host receives the email alerting them of a trade inquiry, and clicks the email link that takes them to the V! Message app, using the unique conversation ID and a checksum to prevent session hijacking or subversion by the guest. They review the request and can Accept or Decline the request, or reply with a message of their own — perhaps to request clarification or indicate the dates are inconvenient.
The host submits the reply, and as above, V! Message sends email to the guest’s address using a Trade To Travel “From:” address to preserve privacy. Again, the email link uses the unique conversation ID and a checksum to prevent tampering.
The guest has the opportunity to continue the discussion, or Cancel the request if they cannot work something out with the host.
This email-and-web conversation continues until the host Accepts or Declines, or the guest Cancels. When resolved as Accepted, V! Message sends an email about the trade with a link to Trade To Travel’s staff so they can finalize the deal.
Note that neither the guest nor the host has had to login to the V! Message application: the unique conversation IDs and checksums stand in for the security that authentication would otherwise provide.
Branding via Theme
In a previous engagement with Trade To Travel, we rebranded their legacy site with a modern, responsive theme, without touching any of their code or servers; we hope to write a blog post about that work in the future.
We used the same theme to brand the V! Message application so it felt seamless to the members engaging in trade conversations. Our theming solution also allowed us to nest this new application under the Trade To Travel URL so members wouldn’t be concerned about going off-site and SSL certificates would continue to work. This helps adoption by members.
Cloud-Based
Most of our work these days is done in the cloud, and we’ve focussed on
Amazon Web Services. We’re using a pair of inexpensive EC2 instances behind an Elastic Load Balancer to avoid single-point-of-failure, and a dual-Availability Zone RDS running PostgreSQL for our fault-tolerant database.
The application’s written in Python, using the excellent Pyramid framework and SQLAlchemy ORM.
It’s working well and we can save our client money by using small instances now, knowing we can easily scale up (or out) if the need arises.
Benefits
Since the roll-out, we’ve seen members self-service inquiries with rapid and fruitful exchanges. One of the benefits neither we nor our client anticipated is that guests can now take a shotgun approach to finding trades: since they can query multiple hosts on their own, they can engage several at once — something that would have been very time consuming for staff before.
Benefits for members and client:
- Guests can quickly explore more properties since conversations are easier to establish and more direct.
- Simple structure to inquiry/response forms keeps conversations focussed on a simple goal — accept, decline, or cancel.
- Mobile-friendly responsive website makes conversations and decisions easy when on-the-go.
- Member email addresses and full names remain private.
- No new passwords needed for members.
- Cryptography-based IDs and checksums prevent conversation snooping and hijacking.
- All communication stays within the application, discouraging side-deals.
- Trade to Travel staff are only required once a trade has been accepted.
- Staff have access to the full history of the conversation to finalize the trades and help resolve any questions.
- Easy to integrate, requiring minimal changes to the client’s application: a link from app’s page and back-channel query endpoint.
Other Use Cases
We expect there are other peer-to-peer or social-network applications that could benefit from this inter-member communications platform without requiring a major re-work to the code base and back-end. Contact us if you’d like to know more.
