6 ms·

I felt your pain immediately and decided to write my own mini-framework to accomplish this. What I have now is a loosely coupled, serverless, frontend+backend

I felt your pain immediately and decided to write my own mini-framework to accomplish this. What I have now is a loosely coupled, serverless, frontend+backend monorepo that wraps AWS SAM and CloudFormation. At the end of the day it is just a handful of scripts and some foundational conventions. I just (this morning!) started to put together notes and docs for myself on how I can generalize and open source this to make it available for others. stack is vue/python/s3/lambda/dynamodb/stripe but the tooling I developed is generic enough to directly support any lambda runtime for any sub-namespace of your project so it would also support a react/rails application just as well.

dahfizz 6y ago
As a systems developer, comments like yours make me amazed at the state of web development. From the outside looking in, it seems like 10% code and 90% monkeying around with tooling and frameworks and stacks.
- deleted 6y ago
  [deleted]
- whalesalad 6y ago
  It’s still a very young ecosystem. Serverless hasn’t had its Rails moment (yet). I don’t think it’s as bad as people make it out to be.
  - x86_64Ubuntu 6y ago
    What's the Rails moment? It's already hit the part where people speak about it as if it will save the world.
    - Toutouxc 6y ago
      I believe it's the moment when there's a solution that just makes sense and works well for most people. A gold standard that other solutions will try to develop more and spice up, instead of reinventing it.
      - whalesalad 6y ago
        Precisely!
rektide 6y ago
A lot of these DX (developer experience) concerns are, imo, rooted in what the article describes as "Vendor Lock". Sure, you can write a bunch of tools to work around the crufty, terrible development environment's shortcomings. But ultimately, you are just locking yourself further & further & further in to the hostile, hard to work with environment, bending yourself into the bizarre abnormal geometry the serverless environment has demanded of you. To me, as a developer who values being able to understand & comprehend & try, I would prefer staying far far far away from any serverless environment that is vendor locked. I would be willing & interested to try serverless environments that give me, the developer, the traditional great & vast powers of running as root locally that I expect. Short of a local dev environment, one meets both vendor lock in, & faces ongoing difficulties trying to understand what is happening, with what performance profiles/costs. I'd rather not invest my creativity & effort in trying to eek more & more signals out of the vendor's black box. Especially if trouble is knocking, then I would very much like to be able to fall back on the amazing toolkits I know & love.
- TheOtherHobbes 6y ago
  AWS is shaping up to be Oracle 2.0. That isn't a compliment.
  - ethbr0 6y ago
    Given an opportunity to milk existing, locked-in customers in lieu of investing in R&D and new products, few leadership teams can resist. Time will tell.
    - mushbino 6y ago
      I'm predicting AWS will wait for a competitor to do the R&D work, see if it's successful, and then look for a way to beat them at their own game.
    - rektide 6y ago
      aws's whole pitch has been cutting out server huggers & engineers, relying on aws. since day 1. often to wonderful effect. with far far better software programmability than our old crufty ways. but lambda gets to the point where there is no local parity, where it's detached, is no longer an easier managed (remotely operated) parallel to what we know & do, but is a system entirely into itself, playing by different rules. one must trust the cloud-native experience it brings entirely, versus the historical past where the cloud offered native local parallels.
jsemrau 6y ago
I never got the hand of cloud formation. I suppose it is nice from a visual (drag and drop) point of view, but I couldn't use it in production and moved on to manage my architecture with terraform.
- whalesalad 6y ago
  I manage a handful of projects with Terraform and it works well in many situations. It has improved a lot recently but for a long time I really hated the syntax. I still do to some extent but have learned to cope with it most of the time. If you are working on a project where all of your infrastructure will live on AWS I would definitely urge you to give it a second look. The amount of infrastructure I manage right now with a single .yaml file is really killer.
- nullsense 6y ago
  CDK is a massive improvement over raw CloudFormation, and people are starting to move away from Terraform and to things like CDK or Pulumi.
  - demosito666 6y ago
    This is a really funny thing, since for the last ~10 years I've been hearing how we're deliberately doing IaC/CM tools "not a programming languages because reasons" (and thus have to do horrible hacks to support trivial things like loops and conditions), and now suddenly we're building libraries in programming languages that convert the code into non-programming-language description, which is then interpreted by a program into several other intermediate representations and finally emits trivial API commands. I guess the next step would be write a declarative language on top of CDK or Pulumi that will compile it into python which will generate CF/TF files.
    - robertlagrant 6y ago
      The magic is in knowing which trivial API commands to call to make the infrastructure match the desired state.
- 6y ago
fizixer 6y ago
> ... stack is vue/python/s3/lambda/dynamodb/stripe Did you chose python for backend dev? Any framework like flask or django? Also no preference of single-language for both backend and front-end, by using node.js backend? Just trying to get into web-dev.
- whalesalad 6y ago
  Yes, it (Python) was chosen because we could leverage existing internal code that was written in Python and it happens to be my strongest language. If I could do it all over, I would still choose Python. That being said, I have been working professionally (building apps like this) for almost 14 years so my willingness to bite off a homebrew Python framework endeavor as I did here is a lot different than someone just getting into the field. Django: avoid unless you have a highly compelling (read: $$$$) reason to learn and use this tool. I cannot think of one, honestly. Flask: fantastic, but be conscientious about your project structure early on and try to keep businees-logic out of your handler functions (the ones that you decorate with @app...) Sophisticated or more sugary Node.js backends are not something I have ever explored, aside from the tried-n-true express.js. I tend to leverage Python for all of my backend tasks because I haven't found a compelling reason not to.
  - darkteflon 6y ago
    Could you elaborate on why you dislike Django? Would be great to hear from someone with extensive Python experience.
    - empthought 6y ago
      Django gets you a lot if you have a traditional app with a traditional RDBMS and a traditional set of web servers. It’s too opinionated to easily map into AWS serverless.
    - StavrosK 6y ago
      On the flip side, not being able to use Django is one of the reasons against serverless for me. There's immense value in having a library for anything you might think of, installable and integratable in minutes. You have to roll your own way too often in Flask et al, so much so that I don't see any reason to use Flask for anything other than ad-hoc servers with only a few endpoints.

dahfizz 6y ago

As a systems developer, comments like yours make me amazed at the state of web development. From the outside looking in, it seems like 10% code and 90% monkeying around with tooling and frameworks and stacks.

deleted 6y ago
[deleted]
whalesalad 6y ago
It’s still a very young ecosystem. Serverless hasn’t had its Rails moment (yet). I don’t think it’s as bad as people make it out to be.
- x86_64Ubuntu 6y ago
  What's the Rails moment? It's already hit the part where people speak about it as if it will save the world.
  - Toutouxc 6y ago
    I believe it's the moment when there's a solution that just makes sense and works well for most people. A gold standard that other solutions will try to develop more and spice up, instead of reinventing it.
    - whalesalad 6y ago
      Precisely!

rektide 6y ago

A lot of these DX (developer experience) concerns are, imo, rooted in what the article describes as "Vendor Lock". Sure, you can write a bunch of tools to work around the crufty, terrible development environment's shortcomings. But ultimately, you are just locking yourself further & further & further in to the hostile, hard to work with environment, bending yourself into the bizarre abnormal geometry the serverless environment has demanded of you. To me, as a developer who values being able to understand & comprehend & try, I would prefer staying far far far away from any serverless environment that is vendor locked. I would be willing & interested to try serverless environments that give me, the developer, the traditional great & vast powers of running as root locally that I expect. Short of a local dev environment, one meets both vendor lock in, & faces ongoing difficulties trying to understand what is happening, with what performance profiles/costs. I'd rather not invest my creativity & effort in trying to eek more & more signals out of the vendor's black box. Especially if trouble is knocking, then I would very much like to be able to fall back on the amazing toolkits I know & love.

TheOtherHobbes 6y ago
AWS is shaping up to be Oracle 2.0. That isn't a compliment.
- ethbr0 6y ago
  Given an opportunity to milk existing, locked-in customers in lieu of investing in R&D and new products, few leadership teams can resist. Time will tell.
  - mushbino 6y ago
    I'm predicting AWS will wait for a competitor to do the R&D work, see if it's successful, and then look for a way to beat them at their own game.
  - rektide 6y ago
    aws's whole pitch has been cutting out server huggers & engineers, relying on aws. since day 1. often to wonderful effect. with far far better software programmability than our old crufty ways. but lambda gets to the point where there is no local parity, where it's detached, is no longer an easier managed (remotely operated) parallel to what we know & do, but is a system entirely into itself, playing by different rules. one must trust the cloud-native experience it brings entirely, versus the historical past where the cloud offered native local parallels.

jsemrau 6y ago

I never got the hand of cloud formation. I suppose it is nice from a visual (drag and drop) point of view, but I couldn't use it in production and moved on to manage my architecture with terraform.

whalesalad 6y ago
I manage a handful of projects with Terraform and it works well in many situations. It has improved a lot recently but for a long time I really hated the syntax. I still do to some extent but have learned to cope with it most of the time. If you are working on a project where all of your infrastructure will live on AWS I would definitely urge you to give it a second look. The amount of infrastructure I manage right now with a single .yaml file is really killer.
nullsense 6y ago
CDK is a massive improvement over raw CloudFormation, and people are starting to move away from Terraform and to things like CDK or Pulumi.
- demosito666 6y ago
  This is a really funny thing, since for the last ~10 years I've been hearing how we're deliberately doing IaC/CM tools "not a programming languages because reasons" (and thus have to do horrible hacks to support trivial things like loops and conditions), and now suddenly we're building libraries in programming languages that convert the code into non-programming-language description, which is then interpreted by a program into several other intermediate representations and finally emits trivial API commands. I guess the next step would be write a declarative language on top of CDK or Pulumi that will compile it into python which will generate CF/TF files.
  - robertlagrant 6y ago
    The magic is in knowing which trivial API commands to call to make the infrastructure match the desired state.
6y ago

fizixer 6y ago

> ... stack is vue/python/s3/lambda/dynamodb/stripe Did you chose python for backend dev? Any framework like flask or django? Also no preference of single-language for both backend and front-end, by using node.js backend? Just trying to get into web-dev.

whalesalad 6y ago
Yes, it (Python) was chosen because we could leverage existing internal code that was written in Python and it happens to be my strongest language. If I could do it all over, I would still choose Python. That being said, I have been working professionally (building apps like this) for almost 14 years so my willingness to bite off a homebrew Python framework endeavor as I did here is a lot different than someone just getting into the field. Django: avoid unless you have a highly compelling (read: $$$$) reason to learn and use this tool. I cannot think of one, honestly. Flask: fantastic, but be conscientious about your project structure early on and try to keep businees-logic out of your handler functions (the ones that you decorate with @app...) Sophisticated or more sugary Node.js backends are not something I have ever explored, aside from the tried-n-true express.js. I tend to leverage Python for all of my backend tasks because I haven't found a compelling reason not to.
- darkteflon 6y ago
  Could you elaborate on why you dislike Django? Would be great to hear from someone with extensive Python experience.
  - empthought 6y ago
    Django gets you a lot if you have a traditional app with a traditional RDBMS and a traditional set of web servers. It’s too opinionated to easily map into AWS serverless.
  - StavrosK 6y ago
    On the flip side, not being able to use Django is one of the reasons against serverless for me. There's immense value in having a library for anything you might think of, installable and integratable in minutes. You have to roll your own way too often in Flask et al, so much so that I don't see any reason to use Flask for anything other than ad-hoc servers with only a few endpoints.