<div dir="ltr">Note that you def can have S3/SQ3/whatever access in the dev env.<br><br>-Mark<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 4, 2014 at 4:09 PM, Sean McArthur <span dir="ltr"><<a href="mailto:smcarthur@mozilla.com" target="_blank">smcarthur@mozilla.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+dev-fxacct I realized there may be more people who want in on this.<br><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Mon, Aug 4, 2014 at 3:45 PM, Sean McArthur <span dir="ltr"><<a href="mailto:smcarthur@mozilla.com" target="_blank">smcarthur@mozilla.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div>Ok, so, the Profile service is going from a dumb proxy of emails to an image crunching and serving monster. Let's ready the monster cage!<br>


<br></div># Overview<br>

<br></div>1. FxA UI will POST some binary image data at an endpoint.<br></div>2. The webserver will generate a unique id, and pipe that payload straight into a private S3 bucket, with the name of the id. Once the upload to S3 is complete, the webserver will add the id to an SQS instance.<br>




</div>3. We will have an SQS instance.<br></div>4. A different worker server will pestering SQS for new images to crunch.<br></div>5. When it finds new messages in the queue, it will download them from the private S3 bucket, resize them if necessary, and reencode them to ensure they're plain images.<br>




</div>6. The worker will upload the crunched image to a public S3 bucket.<br></div>7. That image should now be reachable from <a href="https://firefoxusercontent.domain/a/id" target="_blank">https://firefoxusercontent.domain/a/id</a>.<br>




<div><div><div><div><div><div><div><div><br></div><div># Details<br><br></div><div>- S3 - I'm assuming we'll need 2 buckets, 1 private for dumping "unsafe" images, and a 2nd public that can server image files through a URL.<br>



<br></div><div>- SQS - Will need 1 so that webheads can alert workers when there are new images to crunch.<br><br></div><div>- Servers - 2 kinds of servers: the web server runs in `bin/server.js`, and the worker runs in `bin/images.js`. They don't need direct access to each other; they will communicate through SQS.<br>



<br></div><div>- Image Proxy - The thing to make the public S3 bucket have saneish URLs.<br><br></div><div>- Domains - The web servers should be accessible from <a href="http://profile.account.firefox.com" target="_blank">profile.account.firefox.com</a>. The images should be a different second-level domain. It may be that we already have a domain for this, since AMO and Marketplace have been serving user images for years.<br>



<br># ¯\_(ツ)_/¯<br><br></div><div>
- Building this in stage/dev?<br></div><div>I imagine stage would be like build in prod, but dev tends to use dannyboxes. I'm not sure we'll have access to S3 and SQS and whatnot, so I have been writing a `local` aws-driver, which just uses a child process and IPC to crunch images, and an additional route to server them from.<br>



<br></div><div>- Testing this in stage/dev?<br></div><div>With a dannybox using a `local` driver, testing on dev won't exercise the whole stack. I guess that's what testing in stage is for?<br></div></div></div></div>



</div></div></div></div></div>
</blockquote></div><br></div></div>
<br>_______________________________________________<br>
Dev-fxacct mailing list<br>
<a href="mailto:Dev-fxacct@mozilla.org">Dev-fxacct@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/dev-fxacct" target="_blank">https://mail.mozilla.org/listinfo/dev-fxacct</a><br>
<br></blockquote></div><br></div>