11 ms·
Dawson – A Serverless Web Framework for Node.js on AWS
- social_quotient 10y agoHow is this differentiated from serverless.com ?
- Vekz 10y agoIf this works: # run your app locally $ dawson dev They have that as advantage over serverless.com which is missing a dedicated local workflow
- camhart 10y agohttps://github.com/dherault/serverless-offline https://github.com/dherault/serverless-offline
- scrollaway 10y agoIs there an equivalent for the Python runtime? When I started using Lambda there wasnt, but I haven't looked at whether that changed since.
- pmontra 10y agoZappa https://github.com/Miserlou/Zappa https://github.com/Miserlou/Zappa
- tomd 10y agoand Chalice: https://github.com/awslabs/chalice https://github.com/awslabs/chalice
- simonel 10y agoWe'll ship full first-class support for the python runtime (including the dev server) in dawson in a few weeks.
- throwaway2016a 10y agoAlso if you don't want to install serverless-offline there is "serverless invoke local" built-in.
- cyberferret 10y agoIt all looks interesting, but I still don't see the advantage over pure Lambda? I get that it is a one command deployment, but really at the end of the day, does it save much time over zipping up my Node working folder and uploading to Lambda via the console? (In terms of installing extra framework stuff on my dev PC)
- rpedela 10y agoWhat if you want to automate a build/deployment?
- cyberferret 10y agoOk, I see the logic if you want to set up some sort of continuous automation pipeline. From reading the documentation, it looks like this sets up a whole suite of services for a deployment, including CloudFront etc.? Anyone got a sample of a real world deployment using this framework? Any nasty hidden surprises in AWS billing that you've experienced by doing so? (Not snarky - asking out of actual interest)
- simonel 10y ago> Any nasty hidden surprises in AWS billing that you've experienced by doing so? - just a few cents of S3 Storage (if you're out of the free tier) to host versioned Lambda deployment packages - which will expire automatically anyway. - in production, by default, dawson creates an AWS WAF (Web Application Firewall) WebACL which cost ~5$/mo. You can opt out this behavior if you don't need one.
- simonel 10y ago- it should make easier to replicate Lambdas to different AWS Regions or to use different stages (development, testing, production, ...) - allows running of lambda functions locally, which significantly speeds up development - provides you with a full production-ready environment (CloudFront + S3 + API Gateway + Lambda + ...) out of the box
- pmontra 10y agoFrom what I saw in the documentation a difference seems to be > You should be able to start using dawson without creating any configuration file The configuration obviously exists. It is scattered around as * environment variables for AWS secrets * the api property of functions for defining path, params, etc [1] * a package.json for everything else, maybe not necessary for a minimal deployment without db [2] [1] https://dawson.sh/docs.html#4-function-configuration https://dawson.sh/docs.html#4-function-configuration [2] https://dawson.sh/docs.html#5-application-configuration https://dawson.sh/docs.html#5-application-configuration
- simonel 10y agoThanks. The main goal here is to cover a couple of use cases without needing a single configuration line (aside from the app name, which is always required).
- pyrophane 10y agoWhat is the use case for this type of setup?
- alexcasalboni 10y agoMostly serverless web applications in JS (and Python coming soon!), served with CloudFront (static S3 files) and API Gateway (dynamic APIs).
- nagarjun 10y agoLooks great! Wonder if we can port this to be used with Google Cloud Functions.
- nodesocket 10y agoWhat specific "sugar" and features would dawson add to Functions? Google Functions is already super easy to get up and running and integrates with git/GitHub. The only features I currently see as missing in Google Functions are: 1.) Ability to provide a custom domain for http triggers 2.) Scheduling/cron to trigger functions. E.G. trigger function foo() every 22 minutes. Trigger function bar() on April 10th 09:24:23.
- m1sta_ 10y agoI don't understand why custom domains wouldn't be an option straight out of the gate?
- fibo 10y agoI saw the first talk from its author in Milan, the feature I like most is that it emulates AWS Lambda locally with a Docker.
- nodesocket 10y agoGot a video link?
- pmontra 10y agoNone that I know and sadly I missed the event but the slides are at http://slides.com/lanzone31/dawson20170303#/ http://slides.com/lanzone31/dawson20170303#/
- alexcasalboni 10y agoHere's the meetup event link -> https://www.meetup.com/Serverless-Italy/events/237189798/ https://www.meetup.com/Serverless-Italy/events/237189798/ (no videos though)
- bharani_m 10y agoThis looks neat. I am new to the whole serverless concept, can someone explain how it works? Let's say I have to do some processing on the server (schedule some cron jobs, generate a PDF or send an email), how do I go about doing that? Do I use AWS Lambda for that?
- daliwali 10y agoSpoiler alert: serverless is made of servers. But seriously what they mean is that you rent an allotted amount of resources on a server farm to run your application for a short period of time, and then the resources are freed again. Not all applications will fit this environment, such as any embedded databases, persistent connections, and so on.
- Etheryte 10y agoI never understood the naming for this trend. It's misleading at best.
- mattzito 10y agoI think it's that people assumed (as I did) that everyone would say, "Well, of course, there's not "no servers", because that would be like saying "computerless" or "processorless", but it is practical to say serverless and mean that you don't have to provision, administer, scale, or retire servers, nor do you have to pay for persistent compute resources rather than simply execution" But that's a mouthful, so "serverless" seems to fit the bill outside of what feels a bit like pedantry.
- dualogy 10y ago> mean that you don't have to provision, administer, scale, or retire servers, nor do you have to pay for persistent compute resources rather than simply execution Given all the work this appears to save one, there's a curious explosion of "serverless" articles, frameworks, APIs, 'practices', crash-courses, workshops, talks .. ah well, par for the course with anything tech that gains a catchy moniker. (Perhaps that's why FP doesn't take off quite as much, "Monads" should have been called "Promises" 30 years ago, and Peano Numbers "numberless maths"!)
- daliwali 10y agoNot sure why one would decide on using a framework because it is integrated with a few vendors that are popular at the moment. There is significant lock-in, and just because it is open source does not make it free. Lots of companies right now release client libraries that work only with their own remote server under a liberal license, giving the illusion of freedom.
- peterbraden 10y agoAre there any unopinionated serverless frameworks that allow you to deploy to multiple clouds?
- thomasj 10y agoThe Serverless Framework now supports multiple serverless platforms (AWS Lambda, OpenWhisk, Azure Functions and Google Cloud Functions). Depends on what you consider "unopinionated"... It handles all the deployment lifecycle across all providers but won't abstract away all the implementation details. It is not possible to "lift & shift" from one provider to another without making some changes.
- peterbraden 10y agoBy unopinionated I simply meant that it allows you to deploy to multiple clouds. As someone that hasn't read up on this stuff, can you explain to me the implementation differences that would prevent you from 'lifting and shifting'?
- thomasj 10y agoIt can definitely do this, it supports AWS out of the box and has "provider plugins" for everyone else. The workflow for deploying and managing applications is the same across all providers. At the implementation level, the providers do differ. From small things (like the function interface) to bigger things (like event services). I did a talk on this a while ago: https://speakerdeck.com/jthomas/taming-serverless-dragons-multi-provider-serverless-apps https://speakerdeck.com/jthomas/taming-serverless-dragons-mu... https://serverless.london/meetup/feb2017/serverless-framework-multi-provider-support https://serverless.london/meetup/feb2017/serverless-framewor...
- ecthiender 10y agoCheck out Hasura[1]. Unopinionated: yes, serverless: not really. I think serverless essentially means you want to run code on the server but not really worry about server provisioning, maintenance etc. Hasura[1] is a PaaS (based on Docker+Kubernetes) + BaaS. There are some built-in backend components (like auth and a data service). You can also write any code and deploy (via docker images) to multiple clouds. Disclaimer: I work at Hasura. [1]: https://hasura.io https://hasura.io
- jeppz 10y agoI have no idea why you would want to use this instead of running it directly in aws yourself. Maybe the learning curve is less steep but you lock yourself in with a 3rd party framework and if you run into problems you probably will have to learn aws anyway.
- kayoone 10y agoI am a big fan of the "serverless" approach. If you structure your code in the right way, it is still easy to move away from it and use your own infrastructure if need be anyway. For getting off the ground for MVPs and such without having to deal with hosting and deployment too much and only pay by usage, it's pretty great!
- snadal 10y agoWhy so many of this frameworks insist in using an account with administrator privileges? From the docs: "search for a Policy named 'AdministratorAccess', click next and confirm". It would be much more convenient to request only the needed privileges while teaching the user what is the tool doing in the background.
- alexcasalboni 10y agoYes, I think you can do much better with IAM. Experienced AWS users will not follow such a suggestion, as I suppose that doc is meant to provide a quickstart for beginners.
- cyberferret 10y agoDelving into the intricacies of IAM policies can take up a LOT of room on a tutorial or blog post. Whenever I post an AWS tutorial, I usually say to pick the policy that gives '*' access to that particular service, but with a strong disclaimer that this is not for production usage, and to narrow down the permissions accordingly. EDIT: Not global admin privileges, just full read/write to whatever AWS service I am basing the tutorial on. There are a lot of good IAM policy setting tutorials out there that I usually point them to.
- bpicolo 10y agoWhy not just give a copy-pastable policy?
- cyberferret 10y agoWhere the policies are simple, I try and do that, but sometimes there can be complex ARNs etc. that will take too many words to try and explain, or might distract from the pace of the tutorial itself. It is actually quicker to point to one of the built in or pre-made AWS policies, which are usually fairly generic.
- zachrose 10y agoLinks to such tutorials would be greatly appreciated!
- CDokolas 10y agoDoes this reduce AWS charges in some way?
- deleted 10y ago[deleted]
- simonel 10y agoIt depends on which solution are you comparing to. Usually, based on my experience, the total cost will be significantly lower than a similar solution deployed to EC2+RDS.
- lorec0re 10y agoEven if I personally hate the word "serverless" because at the end everything is based on EC2 instances which are servers, it's made with love in Milan so.. Big up guys!
- alexcasalboni 10y agoWell, everything is still based on CPU registers, but I guess everybody here prefers the abstraction provided by C, Python, Java, Ruby, JavaScript, or Go.
- moron4hire 10y agoNobody calls JavaScript "computerless" or "codeless".
- tchaffee 10y agoBecause the abstraction already has a name: high level language.
- theprotocol 10y agoThat's not the reason why people don't call JavaScript "computerless" or "codeless" though. I think serverless is a bit sensationalistic and ultimately unhelpful of a name. I don't blame new projects for adopting the term since it's already in the public awareness, but I can't say I'm a fan.
- tchaffee 10y agoBecause the abstraction already has a name: high level language.
- _pmf_ 10y agoIt's a nice spin of cloud providers to use "serverless" as a euphemism for "runs only on our proprietary platform and is virtually impossible to migrate away from".
- alexcasalboni 10y agoIt really depends on how you use it. If you structure your code well and you mostly use it to build RESTful APIs (which is what dawson is meant for), you will be able to easily migrate it to any other system. Especially if you use Lambda + RDS, you won't need too much work to re-deploy the same database and functions elsewhere (either another serverless vendor or your own infrastructure).
- jlebrech 10y agowake me up when browserless is a thing
- 83457 10y agonative apps?
- franciscop 10y agoor maybe APIs since it's more related to the back-end?
- yev 10y agoQuestion, is "serverless" a thing nowadays? Also having framework for running basic api / static website on AWS, isn't it a bit too much? Website is cool though :)
- 83457 10y agoIt is a thing and I don't think this is for basic usage. Just google serverless
- abalone 10y agoJust for comparison, Amazon sees what is going on here -- explosion of 3rd party management frameworks for API Gateway & Lambda -- and wants to avoid fragmentation. They're working on a thing called SAM which is built on CloudFormation: https://github.com/awslabs/serverless-application-model https://github.com/awslabs/serverless-application-model More analysis here, which basically notes that SAM is more declarative in nature, and will likely push 3rd party frameworks to be more cross-platform and/or application-centric in focus: https://techbeacon.com/aws-open-sources-serverless-model-what-you-need-know https://techbeacon.com/aws-open-sources-serverless-model-wha...
- Prefinem 10y agoHaving started with Apex (http://apex.run/ http://apex.run/), used Serverless (https://serverless.com/ https://serverless.com/) and tried to work with SAM, I find the SAM is not nearly as easy to use or documented well enough (compared to Serverless) to be useful. On top of that, SAM feels more like a method of using CloudFormation to deploy Lambda Functions and setup API Gateway which means a lot steeper learning curve for people getting into Lambda. After reInvent, I was pretty excited about SAM because it seemed like a perfect system to integrate with the Code Build/Pipeline tools, but after spending a week on it and not getting anywhere, I couldn't really recommend it to anyone.
- lostcolony 10y agoI'd actually compare it more closely with Chalice. SAM is essentially an extension to Cloudformations, whereas Chalice is the equivalent to Serverless (but in Python, and not nearly as mature). https://github.com/awslabs/chalice https://github.com/awslabs/chalice
- tyingq 10y agoI wish "serverless" was instead called "daemonless" or "function as a service / faas". Too late, I know, but "serverless" is just not what's going on. It seems more appropriate as a term for apps that run locally (even in a browser) without backend dependencies.
- root_axis 10y agoAgreed. There is precedence for reclaiming abused terminology, like how 'isomorphic' javascript has become 'universal' javascript (though I'm not a big fan of that name either). Either way, it's a confusing term for the uninitiated and sort of presumes that only the web-dev world exists (because as you say, serverless already has a meaningful definition in the computing world)
- YCode 10y agoMuch like "literally", I think it's too late to save it.
- partycoder 10y agoPutting AWS credentials as plaintext in environment variables does not seem like the best security practice.
- fatbird 10y agoIt's fine because it's an ephemeral value in a docker container, put there during provisioning by ansible where it was pulled from a properly encrypted vault. Kubernetes can totally manage that for you so you can finally go serverless.
- throwaway2016a 10y agoThis looks interesting but if you like it I encourage you to check out https://serverless.com/ https://serverless.com/ It has a very active community, is extremely powerful (because for AWS it is built on AWS CloudFormation), and very robust. I wrote by own framework and eventually moved to Serverless. Not to mention in supports other languages (although the Python documentation is lacking... Java has good documentation though) and other providers (Azure & Google). Edit: For a quick comparison: Dawson - 4 contributors on Github, and almost 650 commits Serverless - Over 200, and almost 6000 commits I don't want to be the type of person that discourages innovation. Sometimes you need to innovate because the current state of affairs is broken. But in this case Serverless Framework is not broken... it is very very good. Footnote: I'm not a contributor but I am a long time user. I don't have any personal stake in the Serverless project.
- BrentOzar 10y ago> But in this case Serverless Framework is not broken... it is very very good. Just as a caveat, though, they've had a lot of breaking changes in the last few releases. Each release, it does feel broken for a while.
- throwaway2016a 10y agoRelease v.1.0 was a complete breaking change (even from release candidates... the RCs were nothing like the final product). But I haven't experience that issue with minor version updates. For the most part they have been pretty smooth. A few of them I had to go in and manually fix some things in the AWS console but it hasn't been too bad.
- simonel 10y agoWe're not comparing dawson's maturity to Serverless, nor we are financially backed as they are, so comparing those numbers is pointless. Anyway, if someone's interested in diving in deeper, instead of just counting our stars, this deck might be a good resource: http://slides.com/lanzone31/dawson20170303 http://slides.com/lanzone31/dawson20170303 A few corrections to your comment: >is extremely powerful (because for AWS it is built on AWS CloudFormation) dawson is also built entirely upon CloudFormation >Not to mention in supports other languages we'll merge python in master in a few weeks