Thanks for sharing. I've just started work on a server-free AWS architecture, but instead of using the AWS API Gateway feeding into Lambda, I'm working on static pages with AWS SDK for Javascript (served from S3) talking directly to Cognito, RDS and S3 with lambda for async processing:<p><a href="https://aws.amazon.com/sdk-for-browser/" rel="nofollow">https://aws.amazon.com/sdk-for-browser/</a><p>I'm surprised I haven't seen more discussion of SDK for Javascript since it removes a lot of the server requirements. Have you considered using AWS SDK for Javascript, or do you explicitly want a REST API as an abstraction layer? The API certainly provides some advantages if you ever want to migrate off AWS. In my case, the lambda functions get invoked by particular events on RDS, S3, or manual/browser triggers instead of AWS API Gateway invocation.
First of all nice work!<p>Second there is already a product out there called jaws: <a href="http://www.freedomscientific.com/Products/Blindness/JAWS" rel="nofollow">http://www.freedomscientific.com/Products/Blindness/JAWS</a><p>The last time I checked (and my information is very dated, 5+ years) this was a fairly popular piece of software in the blind community. I also do not know the status of trademark around the term. If you were going to change names, its early days for you now would be the good time to do it.
Note that you should be wary of AWS Lambda limits. We blew through them on our first day directing traffic on a system we were testing with Lambda. They were able to increase our limits a few days later, but something to think about before you base your whole stack around it.<p><a href="http://docs.aws.amazon.com/lambda/latest/dg/limits.html" rel="nofollow">http://docs.aws.amazon.com/lambda/latest/dg/limits.html</a>
Great work - looks like a really useful piece to help you quickly get going using the AWS stack and Lambda/JS. The biggest issue I've always found is the extra steps between writing your code and getting it onto a server.<p>The "no server" movement definitely seems to be gathering steam, with Firebase and Parse on the data side and Lambda (augmented with JAWS and others) on the computation side. Am excited to see what this area will bring, in particular due to the combination of scalable hosting and containerisation.<p>(Plug - we're working on StackHut (<a href="http://www.stackhut.com" rel="nofollow">http://www.stackhut.com</a>) in the "no server" space that provides a language-agnostic Lambda-like platform (currently JS/ES6 and Python with Ruby soon) that's powered by Docker and is accessible via JSON-RPC over HTTP. Would love to hear your thoughts on this and the "no server" space in general.)
This seems very convenient...<p>Is there some blog/resource that provides an estimate of the pricing when we go this route, instead of a seperate server for the APIs.<p>I would like to know the rough pricing in an order of magnitude level?<p>Would it be twice as expensive as a django app for an application with light usage, etc?<p>TIA!
Just added a section in JAWS Optimization on the AWS Pop-Up Loft because it's a tremendous resource and I don't think many people know about it. Since this page is so popular, I'll paste the section in here:<p>AWS Pop-Up Loft<p>AWS has an office/loft in downtown San Francisco where you can meet with an AWS engineer for free to discuss your project and your use of AWS services. It's an incredibly valuable resource, but I don't think many people know about it.<p>All you have to do is schedule a meeting in advance. Meetings can last up to 1 hour and can be scheduled M-F during normal business hours.<p>Further, their office and loft is also a free co-working space, as long as you are using AWS services. They have some nice couches and desks and it's a great way to network with other developers who use AWS services.<p>Again, all of this costs nothing. If you're in SF, or traveling there, check it out!
This is jawsome. I feel like you're cheating on the "no server" bit with some AWS semantics but you're not the first so, whatever, nice job.
It's a bit what Couch Apps where supposed to be, without the vendor-locking part...<p>> no server<p>But you have to rely on AWS infrastructure. So what you meant is no server management.
I've been trying to find a core example of how Jaws works without having to download anything. Could you include an example in your readme of an example API using lambda? Even some pseudocode would help me understand.
I've been looking for something like this within a ClojureScript workflow. With the new JS compiler it seems not too far off.<p>This is very cool. I would love to see more aws resources exposed as well through JAWS like dynamo or RDS.
This is interesting, thanks for sharing. Was a bit confused about lambda.<p>So this would be cheaper than just having an EC2/DO instance running flask with a couple of endpoints?
Is there a way to use a file system-backed storage with this? For example, I would love to create a web frontend for ledger [1]. Ledger only reads text files but for a frontend to be useful it would need to write entries to files.<p>1. <a href="http://www.ledger-cli.org/" rel="nofollow">http://www.ledger-cli.org/</a>
Really cool... Now we just need longer Lambda execution times (current limit is 60s) and a proper crontab. For a complete auth flow you can also check:<p><a href="https://github.com/danilop/LambdAuth" rel="nofollow">https://github.com/danilop/LambdAuth</a><p>It would be nice to integrate some ideas from LambdAuth into JAWS.
Great experiment here. Lambda has been intriguing me for a while. More and more, as I scope out work for clients, I'm finding bits that could probably be run as Lambda processes instead of requiring an entire EC2 instance. This is kind of like taking a REST interface to a natural extreme.
I was looking into using lambda functions called in response to an S3 event. Specifically, I wanted to create a record in my SQL database after a file is uploaded to S3. Users are uploading directly to S3 using pre-signed requests, so I needed some way to step in and create a database record after they actually perform the upload to S3. S3 supports this via several methods, one of which is the lambda functions, but when looking into lambda functions there was no way to have the code access my SQL database internally, I would have had to make my SQL database open to the world. I didn't find any IAM rules etc to enable lambda functions to access my SQL database resources. I'd be curious to see how this is handled by this JAWS work flow.
You may want to reconsider the name since JAWS is widley known as the defacto application for accessibility screen readers.<p>As far as legal stuff goes the american federation of the blind has been known to litigate against technology companies.
Ha, been working on something similar. If you get a chance, take a look. Maybe we can collaborate.<p><a href="https://github.com/johntitus/hocus" rel="nofollow">https://github.com/johntitus/hocus</a>
I'm presently about three quarters done with writing one of these myself; Lamdba plus SQS plus arbitrary functions. I have a different take on deployment, going with CloudFormation. Version updates are something you have to think about quite hard with this sort of system.<p>The real challenge is how to manage within the 60 second, 1024 thread limits in a sane way, however. You have to approach application decomposition in a much more rigorous way.
Is it really true that Lambdas can take 5 minutes to start up? Doesn't that rule them out as useful for things like running a website (instead of just background jobs)? Or does the article mean 5 minutes from the first time you deploy a new one to the time it's available, but after that new lambdas can be spun up in milliseconds to server each request?
Great job, grabbed my attention, I really liked this, but I'm doing so great with gulp that if I used this I really would still need to use gulp because of the optimizations, I'm also using S3 and Lambda, but I like the idea of running aws lambda locally before uploading and the "run a server locally" before upload.
Nice work on the project! Big fan of the graphics also :)<p>Reminds me of Divshot [0], a heroku-like service for hosting static sites. It's great that you can roll your own site, and don't need a middleman to host for you.<p>[0] <a href="https://divshot.com/" rel="nofollow">https://divshot.com/</a>
this is really cutting edge stuff, great job. Would be event cool to include polymer webcomponents (on client side) , AWS Cognito for authentication along with this.
Jaws already exists as a software project, for the blind.<p>Perhaps I am exposing ignorance about the needs of the blind community, but it would seem to me that a primarily important piece of software for them could be more confusing to find and update and so on if another piece of software appears with the same name. Maybe you should consider changing the name of your software before it's too late? It's possible that your Jaws may, in the long run, cause considerable confusion for the users of the pre-existing Jaws software.<p>I'm making a case based on empathy rather than trademark law and so on.
Woohoo! It's the second coming of stored procedures and PL/SQL! Party like it's 1988!<p>Seriously though, these kinds of architectures come at a cost. The website's claims are either misleading, or the authors haven't understood the problem domain. E.g.:<p><i>Each of your API URLs points to one of these Lambda functions. This way, the code for each API Route is completely isolated, enabling you to develop/update/configure/deploy/maintain code for specific API urls at any time without affecting any other part of your application(!!!).</i><p>Even if you add more exclamation marks, you'll still end up with front end code depending on the interface exposed by your backend code, meaning you'll have to do versioned rollouts, except you no longer have a single deployable but a zoo of store proce^W^Wlambda functions, with unclear interdependencies and (usually) no proper versioning or tracking.<p>This might be the right architecture for certain apps, but it's not the easy win/win that's presented here.