Introducing the StreetCarts Project

One of the dirty little secrets about writing software docs is that we're usually working from tidy use cases, then writing about them as if they're never hobbled by complicating factors. "Here, just follow these 12 steps to configure your policy and Bob's your uncle."

Except that Bob often isn't. It's not that we don't know there are complications. It's that we don't usually have time to suss out the wrinkles and write about them.

So the doc team is making time to build a proxy app from scratch, as if we're a startup. We'll connect multiple products and solve a few of the problems that customers get to solve (in a smaller way, of course).

1320-elcubodecuba.jpg

We're building an app to pre-order food from food carts. Think of those little trailers offering Thai food, Cajun food, reindeer sausage -- you name it. The API will provide access to carts and menus and let users buy stuff (in simulation, anyway). Down the road, we want to add social features, push notifications, and the like.

Using Edge, API BaaS, and Node.js, we've already got a fair amount built. And we have a bucket of questions. What's the best way to chunk data consumed by a client? Where should we handle authentication? How should we structure the project for source control? @wwitman just created a team doc that captures lessons learned and yet-to-learn. So far, it's six pages long.

In the end, we expect to have a big satchel of material for fresh samples, posts, and docs. And we're having a great time so far.

We're looking forward to showing you what we come up with, and hoping you tell us what you think (no, really). Tune in here on Fridays for updates.

Comments
Not applicable

This is a fantastic idea. How are you [pretending/going] to handle payments? What client code are you using (HTML5, SWIFT, etc.)?

Will you be making the proxies open for use by customers? What about the code?

What are the commercial and legal implications of someone basically just taking what you've written, branding it and selling it?

straut
Staff

Great questions, @Paul. The team hasn't finished answering those yet, but I'll offer my thoughts.

On payments -- No idea. The payment processing part (if any) will likely be fake. But maybe we'll build a layer that can be connected to a payment piece of the developer's choice.

On client code -- We haven't built that yet because we're still making big changes to the API. But maybe it would be best to have non-platform-specific code that developers can easily download and run without many configuration or compilation steps. HTML5/JavaScript sounds most useful from that perspective. The core of the sample is the API and what's behind it.

On open proxies -- If you mean "Sample in a public github repo", then yes, that's our intention if it works out. If you mean "open, running, and publicly accessible -- say, on the cloud -- for customers to call", it seems like the value would have to be pretty high to justify taking on the burden of keeping it running reliably. But it might be cool to do it.

On commercial and legal implications -- We haven't looked hard at that yet. We intend to use fake data. If it's published as an open sample, then I suppose it could be "protected" by an agreement we specify. So unless the code represents competition for a customer, I don't see a problem.

birute
Staff

Love it!

davissean
Staff

"Except that Bob often isn't..." 😄

Version history
Last update:
‎10-09-2015 09:48 AM
Updated by: