skip to main |
skip to sidebar
Motivation:
- Vend is a pretty awesome point-of-sale (POS) that resides in the cloud and has an even awesome~er developer API.
-
You can easily create and query views in CouchDB (common hosts: Cloudant and IrisCouch).
-
This can be especially helpful if you want to build towards a Full Text Search capability on top of the Vend APIs.
Steps:
-
Get all the products from your Vend store and upload them to CouchDB.
-
Some standalone code be written to pull all the products and upload them. So many ways to do this, depending on what has the best utilities to cobble together something in a hurry: curl or Java or javascript (run via Node.JS) etc.
-
I'm partial to Node.JS because all of Vend's data is in JSON-format and there are some excellent libraries like Cradle which make it simpler to talk with CouchDB.
-
For the upload to CouchDB, it should be possible to leverage the bulk document API and finish it off in one shot.
-
Going forward, keep everything up to date in real-time by utilizing Vend's webhooks to call into CouchDB's update handlers.
-
Create a design document in CouchDB with update handlers that can parse the payload delivered by a Vend webhook like a product update.
-
When writing an update handler for receiving a product update, I mimicked the Stripe Kanso project.
-
I didn't really write the upload script yet. I simply tried to point Vend's product webhook at the URL for my update handler and I was able to get a document populated in CouchDB.
-
For an actual product update (not just a new one), I haven't quite figured out the code, it fails right now. Just need to spend more time reading up on update handlers, I suppose.
-
Because the Vend API sends the update via a payload that is form urlencoded, I was left wondering where to look for the data and how to grab it inside CouchDB's update handler .. but those questions were easily tackled when I found documentation on handling form-style-submission of data with CouchDB.
- I did send an email to the CouchDB mailing-list to ask for some advice on actual updates:
1) I have a 3rd-party-webhook API calling into my update handler and there's nothing I can do to make it pass the document ID in the URL.
2) That means the CouchDB server cannot provide the update function with the most recent version of that document.
3) But the request does provide a payload from which I can pull out the document ID ... but by this time I'm inside the update handler function.
4) So my question is: If CouchDB did not provide a doc, is there still a way for me to:
a) either, fetch the latest version of the doc myself?
b) or, override the existing document with another document formed with my request payload ... without running into a revision conflict?
I know that I can probably route the request through a proxy that parses the payload, sets the document ID onto the request URL and sends it own its way ... but I'd rather leave that as a last resort.
Thoughts?
-
One more challenge to keep in mind is authentication. If anyone figures out the URL endpoint for the CouchDB and the respective update handler, they could make false additions and updates.
-
It would be worth looking into any username/password BASIC authn provided by CouchDB to secure the update handler endpoint.
-
A quick fix would be to provide a unique token (?token=ABCDEF123) as part of the endpoint URL you specify for the webhook (product.update: https://couchdb.com/myDB/_design/doc/_update/productHandler?token=ABCDEF123) and since the query params are also encrypted in a request, your token would travel over a secure channel and then be validated on the CouchDB side to see if it matches what you expected.
-
Can we spread out our configuration in a .env file for Foreman across multiple lines?
-
At first I thought that this fix to Foreman allowed me break long confugrations across multiple lines the way that I wanted:
JAVA_OPTS=-Xmx384m -Xss512k \
-XX:+UseCompressedOops
MAVEN_OPTS=-Xmx384m -Xss512k -XX:+UseCompressedOops
-
But that's not the case as I found out via trial & error. Now I think its simply not supported.
-
Can we spread out our configuration in a Procfile file for Foreman across multiple lines?
-
Nope, trial & error resulted in the same deal as above.
-
BUT ... I found a nifty clue here, which allowed me to setup a workaround like this:
# contents of Procfile
web: ./webapp-runner.sh
# contents of webapp-runner.sh
java $JAVA_OPTS \
-Djavax.net.ssl.trustStore="cacerts.jks" \
-jar target/dependency/webapp-runner.jar --port $PORT target/*.war