Skip to content

Latest commit

 

History

History
73 lines (49 loc) · 3.77 KB

comparison.md

File metadata and controls

73 lines (49 loc) · 3.77 KB
Raw

Why Lift?

Why: Goals

Deploying to Lambda is easy. The rest is still hard. You won't build a web application using only lambdas.

Lift focuses on "the rest" (other AWS services, CloudFormation, IAM…) with 2 main goals:

  • make it simpler
  • help getting it right for production (good architecture)

Lift addresses both:

  • experienced web developers without serverless/AWS knowledge - it reduces the AWS onboarding lead time
  • experienced serverless web developers - it reduces the lead time to ship web application standard features

Addressing both those personas, we ease up our goal to maximize adoption.

How: Constraints & Vision

Make it simpler:

  • Simpler technically: replace lengthy CloudFormation stuff with a few lines of YAML
  • Simpler conceptually: use-case focused, developer vocabulary instead of AWS vocabulary.

Help getting it right for production (well architected):

  • By default, things deployed by Lift should be "production-ready" (production best practices). Services are provisioned in an opinionated way.
  • Covering all possible options/configuration is not a goal.
  • Provide a "dev" mode with appropriate configuration. (note: this goal isn't reached yet)

Maximize adoption:

  • Open-source
  • Low effort: I can install and deploy in 3 commands. Lift is familiar with existing tools and practices.
  • No lock-in: I can easily eject to native CloudFormation.
  • Not invasive: Minimal impact or constraint on the code or the project. 1 configuration file.

Comparison with existing solutions

In order to achieve our goals, we first drew a picture of the current AWS serverless ecosystem. We chose to focus on 3 main evaluation criterion to rate existing solutions.

Onboarding

  • Is it feature-oriented ? Being an AWS oriented framework requires the developer to have some existing knowledge of AWS services. It is not made for serverless beginners.
  • How many steps required to get started ? Solution with a complicated onboarding process are cumbersome

Lock-in

  • Can I eject easily ? In case the solution does not fit my requirements anymore, can I easily opt-out without loosing everything I implemented ?

Features

  • Which common web features can I easily implement with the solution ?

Comparison table

Criterion \ Solution Stackery Architect Laravel Vapor Amplify CDK SST SLS SLS Components
Underlying technology SAM SAM CDK CFN
Onboarding: Feature-oriented ✅ ✅ ✅ ✅ ❌ ✅ ❌ ✅
Onboarding: Steps quantity ❌ ✅ ❌ ❌ ✅ ✅ ✅ ✅
Lock-in: Ejectable ✅ ✅ ❌ ✅ ✅ ❌ ✅ ❌
Feature: File upload ❌ ❌ ✅ ✅ ❌ ❌ ❌ ❌
Feature: Authentication ❌ ❌ ❌ ✅ ❌ ✅ ❌ ❌
Feature: Asynchronous jobs ✅ ❌ ✅ ❌ ❌ ❌ ❌ ❌
Feature: Database ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌
Feature: Real-time feedback ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌
Feature: File storage ✅ ❌ ✅ ✅ ❌ ❌ ❌ ❌
Feature: Static website ✅ ❌ ✅ ✅ ❌ ✅ ❌ ✅
Feature: Server-side rendering ❌ ❌ ✅ ✅ ❌ ✅ ❌ ✅
Feature: HTTP API ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Feature: Webhook ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌