From b482994728049650a205a0dc8b174eee0188c867 Mon Sep 17 00:00:00 2001 From: Jay V Date: Thu, 15 Aug 2024 14:39:39 -0400 Subject: [PATCH 1/3] Move to guide only design --- README.md | 18 +- _chapters/es/who-is-this-guide-for.md | 2 +- _chapters/fr/who-is-this-guide-for.md | 2 +- _chapters/ko/who-is-this-guide-for.md | 2 +- _chapters/pl/who-is-this-guide-for.md | 2 +- _chapters/pt/who-is-this-guide-for.md | 4 +- _chapters/si/who-is-this-guide-for.md | 2 +- _chapters/who-is-this-guide-for.md | 2 +- _chapters/zh/who-is-this-guide-for.md | 2 +- _config.yml | 12 +- _includes/blog-posts.html | 25 - _includes/footer.html | 42 +- _includes/head.html | 3 - _includes/header.html | 10 +- _includes/newsletter-form-sidebar.html | 2 +- _includes/post-footer.html | 2 +- _includes/post-sidebar.html | 2 +- _includes/search-field.html | 3 +- _layouts/example.html | 51 +- _layouts/post.html | 2 +- ...o-make-it-easy-to-build-serverless-apps.md | 17 - ...g-sst-to-simplify-real-estate-investing.md | 57 -- ...orm-for-the-construction-trade-with-sst.md | 51 -- ...rming-field-service-operations-with-sst.md | 72 --- ...t-software-company-is-building-with-sst.md | 63 -- _posts/2022-05-05-announcing-sst-1-0-conf.md | 27 - _posts/2022-05-16-sst-v1.md | 90 --- _posts/2022-05-23-wrapping-up-sst-1-0-conf.md | 35 - _posts/2022-06-23-moving-to-discord.md | 17 - _posts/2022-06-25-sst-dev.md | 11 - _posts/2022-06-28-create-sst.md | 54 -- _posts/2022-07-19-remixsite-construct.md | 65 -- _posts/2022-08-22-config.md | 104 --- _posts/2022-08-29-testing-in-sst.md | 83 --- _posts/2022-09-01-auth.md | 61 -- _posts/2022-09-12-learn-to-build-with-sst.md | 32 - _posts/2022-09-23-long-running-jobs.md | 89 --- ...022-12-05-is-serverless-ready-episode-1.md | 16 - _posts/2022-12-06-sst-v2-preview.md | 28 - _posts/2023-02-27-sst-v2.md | 113 ---- _posts/2023-04-17-open-next-v1.md | 47 -- _posts/2023-09-22-new-sst-console.md | 52 -- _posts/2024-01-29-moving-away-from-cdk.md | 597 ------------------ _sass/theme/_layout.scss | 106 ++-- about/culture.md | 221 ------- about/index.html | 214 ------- assets/lander/logo/sst-guide.svg | 12 + blog/index.md | 7 - careers.html | 42 -- guide.md | 107 ---- index.md | 391 ++---------- 51 files changed, 189 insertions(+), 2882 deletions(-) delete mode 100644 _includes/blog-posts.html delete mode 100644 _posts/2021-07-23-serverless-stack-raises-1m-to-make-it-easy-to-build-serverless-apps.md delete mode 100644 _posts/2021-10-27-doorvest-is-using-sst-to-simplify-real-estate-investing.md delete mode 100644 _posts/2021-10-28-buildforce-is-creating-the-first-ever-career-platform-for-the-construction-trade-with-sst.md delete mode 100644 _posts/2021-11-11-leadent-digital-is-transforming-field-service-operations-with-sst.md delete mode 100644 _posts/2021-11-16-henry-schein-one-the-worlds-largest-dental-practice-management-software-company-is-building-with-sst.md delete mode 100644 _posts/2022-05-05-announcing-sst-1-0-conf.md delete mode 100644 _posts/2022-05-16-sst-v1.md delete mode 100644 _posts/2022-05-23-wrapping-up-sst-1-0-conf.md delete mode 100644 _posts/2022-06-23-moving-to-discord.md delete mode 100644 _posts/2022-06-25-sst-dev.md delete mode 100644 _posts/2022-06-28-create-sst.md delete mode 100644 _posts/2022-07-19-remixsite-construct.md delete mode 100644 _posts/2022-08-22-config.md delete mode 100644 _posts/2022-08-29-testing-in-sst.md delete mode 100644 _posts/2022-09-01-auth.md delete mode 100644 _posts/2022-09-12-learn-to-build-with-sst.md delete mode 100644 _posts/2022-09-23-long-running-jobs.md delete mode 100644 _posts/2022-12-05-is-serverless-ready-episode-1.md delete mode 100644 _posts/2022-12-06-sst-v2-preview.md delete mode 100644 _posts/2023-02-27-sst-v2.md delete mode 100644 _posts/2023-04-17-open-next-v1.md delete mode 100644 _posts/2023-09-22-new-sst-console.md delete mode 100644 _posts/2024-01-29-moving-away-from-cdk.md delete mode 100644 about/culture.md delete mode 100644 about/index.html create mode 100644 assets/lander/logo/sst-guide.svg delete mode 100644 blog/index.md delete mode 100644 careers.html delete mode 100644 guide.md diff --git a/README.md b/README.md index c3120624a..c7f009306 100644 --- a/README.md +++ b/README.md @@ -7,19 +7,19 @@

Discord - Twitter + Twitter Seed Status

--- -## About SST.dev +## SST Guide -This repo for [**SST.dev**](https://sst.dev) and the [SST Guide](https://sst.dev/guide.html). If you are looking for the SST repo, [head over here](https://github.com/sst/sst). +This repo for [**guide.sst.dev**](https://guide.sst.dev), the SST Guide. If you are looking for the SST repo, [head over here](https://github.com/sst/sst). SST.dev is built with [SST](https://sst.dev) and deployed with [Seed](https://seed.run). -## SST Guide +## About the Guide The guide is a comprehensive open source tutorial for building and deploying full-stack apps using Serverless and React on AWS. @@ -38,7 +38,7 @@ It is a single-page React app powered by a serverless CRUD API. We also cover ho ### Getting Help -- If you are running into issues with a specific chapter, join us on [Discord][discord] and post in `#help`. +- If you are running into issues with a specific chapter, join us on [Discord][discord]. - Open a [new issue](../../issues/new) if you've found a bug - If you've found a typo, edit the chapter and submit a [pull request][pr]. @@ -118,13 +118,13 @@ Thanks to these folks for their contributions to the content of SST. - [Vieko Franetovic](https://github.com/vieko): Translating chapters to Spanish - [Christian Kaindl](https://github.com/christiankaindl): Translating chapters to German - [Jae Chul Kim](https://github.com/bsg-bob): Translating chapters to Korean -- [Ben Force](https://twitter.com/theBenForce): Extra credit chapters -- [Eze Sunday](https://twitter.com/ezesundayeze): Extra credit chapters -- [Maniteja Pratha](https://twitter.com/PrataManitej): Vue.js example +- [Ben Force](https://x.com/theBenForce): Extra credit chapters +- [Eze Sunday](https://x.com/ezesundayeze): Extra credit chapters +- [Maniteja Pratha](https://x.com/PrataManitej): Vue.js example --- -**Join our community** [Discord][discord] | [YouTube](https://www.youtube.com/c/sst-dev) | [Twitter](https://twitter.com/SST_dev) | [Contribute][contributing] +**Join our community** [Discord][discord] | [YouTube](https://www.youtube.com/c/sst-dev) | [X.com](https://x.com/SST_dev) | [Contribute][contributing] [discourse]: https://discourse.sst.dev [discord]: https://sst.dev/discord diff --git a/_chapters/es/who-is-this-guide-for.md b/_chapters/es/who-is-this-guide-for.md index c1a7e81aa..82a213465 100644 --- a/_chapters/es/who-is-this-guide-for.md +++ b/_chapters/es/who-is-this-guide-for.md @@ -14,6 +14,6 @@ Por lo tanto, podrías ser un desarrollador de backend que le gustaría aprender También estamos, por ahora, enfocando esto únicamente a los desarrolladores de JavaScript. Podríamos apuntar a otros idiomas y entornos en el futuro. Pero creemos que este es un buen punto de partida porque puede ser realmente beneficioso para un desarrollador fullstack usar un solo lenguaje (JavaScript) y un entorno (Node.js) para crear toda la aplicación. -Como nota personal, el enfoque sin servidor ha sido una revelación gigante para nosotros y queríamos crear un recurso donde pudiéramos compartir lo que hemos aprendido. Puedes leer más sobre nosotros [**aquí**]({% link about/index.html %}). Y [echar un vistazo a una muestra de lo que la gente ha creado con SST]({% link showcase.md %}). +Como nota personal, el enfoque sin servidor ha sido una revelación gigante para nosotros y queríamos crear un recurso donde pudiéramos compartir lo que hemos aprendido. Puedes leer más sobre nosotros [**aquí**]({{ site.sst_url }}). Y [echar un vistazo a una muestra de lo que la gente ha creado con SST]({% link showcase.md %}). Comencemos mirando lo que estaremos cubriendo. diff --git a/_chapters/fr/who-is-this-guide-for.md b/_chapters/fr/who-is-this-guide-for.md index 2f773e25d..190cbe21c 100644 --- a/_chapters/fr/who-is-this-guide-for.md +++ b/_chapters/fr/who-is-this-guide-for.md @@ -14,6 +14,6 @@ En tant que développeur backend qui souhaite en apprendre plus sur la partie fr Nous couvrons uniquement les besoins des développeurs JavaScript pour le moment. Nous ciblerons peut-être d'autres langages et environnements dans le future. Mais nous pensons que c'est un bon point de départ, car cela peut être réellement bénéfique d'utiiser un seul langage (JavaScript) et environnement (Node.js) pour construire votre application complète. -D'un point de vue personnel, l'approche serverless a été un énorme révélation pour nous et nous souhaitions créer une ressource pour partager ce que nous avons appris. Vous pouvez en lire plus sur nous [**ici**]({% link about/index.html %}). Et [voir un échantillon de ce qui nous avons fait avec SST]({% link showcase.md %}). +D'un point de vue personnel, l'approche serverless a été un énorme révélation pour nous et nous souhaitions créer une ressource pour partager ce que nous avons appris. Vous pouvez en lire plus sur nous [**ici**]({{ site.sst_url }}). Et [voir un échantillon de ce qui nous avons fait avec SST]({% link showcase.md %}). Commençons par regarder les aspects que nous aborderons. diff --git a/_chapters/ko/who-is-this-guide-for.md b/_chapters/ko/who-is-this-guide-for.md index 915672702..032dc2746 100644 --- a/_chapters/ko/who-is-this-guide-for.md +++ b/_chapters/ko/who-is-this-guide-for.md @@ -14,6 +14,6 @@ comments_id: who-is-this-guide-for/96 우리는 현재 자바 스크립트 개발자만을 대상으로 이 문제를 해결하고 있습니다. 앞으로 다른 언어와 환경을 목표로 삼을 수 있습니다. 그러나 풀스택 개발자가 단일 언어 (JavaScript) 및 환경 (Node.js)을 사용하여 전체 응용 프로그램을 빌드하는 것이 실제로 도움이 될 수 있기 때문에 이것이 좋은 출발점이라고 생각합니다. -개인적으로 서버리스 방식은 우리에게 커다란 일종의 계시였으며 우리가 배운 것을 공유 할 수있는 리소스를 만들고 싶었습니다. 우리에 대한 자세한 내용은 [**여기**]({% link about/index.html %})를 참조하십시오. 그리고 [SST으로 구축 한 사람들의 샘플을 확인하십시오.]({% link showcase.md %}). +개인적으로 서버리스 방식은 우리에게 커다란 일종의 계시였으며 우리가 배운 것을 공유 할 수있는 리소스를 만들고 싶었습니다. 우리에 대한 자세한 내용은 [**여기**]({{ site.sst_url }})를 참조하십시오. 그리고 [SST으로 구축 한 사람들의 샘플을 확인하십시오.]({% link showcase.md %}). 이제 우리가 무엇을 다루는지 살펴 보겠습니다. diff --git a/_chapters/pl/who-is-this-guide-for.md b/_chapters/pl/who-is-this-guide-for.md index cab2a444b..e8a90f2a3 100644 --- a/_chapters/pl/who-is-this-guide-for.md +++ b/_chapters/pl/who-is-this-guide-for.md @@ -13,6 +13,6 @@ Możliwe, że jesteś deweloperem backendowym, który chciałby dowiedzieć się Na tą chwilę kierujemy się wyłączenie do deweloperów używających języka JavaScript, ale w przyszłości być może skupimy się na innych językach i środowiskach. Mimo wszystko uważamy, że jest to dobry punkt wyjścia, ponieważ używanie jednego języka (JavaScript) i środowiska (Node.js) do budowania całej aplikacji może okazać się korzystne dla full-stack dewelopera. -W ramach uwagi osobistej, podejście bezserwerowe jest dla nas wielką rewelacją, dlatego też chcieliśmy stworzyć i udostępnić materiał, w którym zawarlibyśmy, to czego się nauczyliśmy. Więcej o nas przeczytasz [**tutaj**]({% link about/index.html %}). [Zobacz też próbkę tego, co inni stworzyli za pomocą SST]({% link showcase.md %}). +W ramach uwagi osobistej, podejście bezserwerowe jest dla nas wielką rewelacją, dlatego też chcieliśmy stworzyć i udostępnić materiał, w którym zawarlibyśmy, to czego się nauczyliśmy. Więcej o nas przeczytasz [**tutaj**]({{ site.sst_url }}). [Zobacz też próbkę tego, co inni stworzyli za pomocą SST]({% link showcase.md %}). Zacznijmy od przyjrzenia się temu, co będziemy omawiać. diff --git a/_chapters/pt/who-is-this-guide-for.md b/_chapters/pt/who-is-this-guide-for.md index 80435657c..0a88266f9 100644 --- a/_chapters/pt/who-is-this-guide-for.md +++ b/_chapters/pt/who-is-this-guide-for.md @@ -12,7 +12,7 @@ Esse guia foi feito para desenvolvedores full-stack ou desenvolvedores que desej Talvez você seja um desenvolvedor backend querendo aprender mais sobre a parte frontend de aplicações Serverless, ou um desenvolvedor frontend que gostaria de aprender mais sobre backend. Esse guia servirá para ambos os casos. -Pessoalmente, a ideia do Serverless foi uma enorme revelação para nós e isso nos fez criar um guia com qual poderíamos compartilhar o que aprendemos. Você pode saber mais sobre nós [**aqui**]({% link about/index.html %}). E [veja alguns exemplos de pessoas que construíram aplicações com SST clicando aqui]({% link showcase.md %}) +Pessoalmente, a ideia do Serverless foi uma enorme revelação para nós e isso nos fez criar um guia com qual poderíamos compartilhar o que aprendemos. Você pode saber mais sobre nós [**aqui**]({{ site.sst_url }}). E [veja alguns exemplos de pessoas que construíram aplicações com SST clicando aqui]({% link showcase.md %}) Por hora, apenas vamos abordar o desenvolvimento com JavaScript/TypeScript. Futuramente talvez abordemos outras linguagens e ambientes. Porém, para começar, nós achamos muito benéfico para um desenvolvedor full-stack utilizar apenas uma linguagem (TypeScript) e ambiente (Node.js) para a construção de uma aplicação completa. @@ -34,4 +34,4 @@ Essas preocupações são válidas. Mas acontece que, se as bibliotecas que voc Além disso, o TypeScript pode ser adotado gradativamente. Isso significa que você pode usar o nosso projeto base de TypeScript e adicionar JavaScript a ele. Fazer isso não é recomendável, porém isso pode ser uma opção. -Vamos começar dando uma olhada sobre o que vamos contemplar nesse guia a seguir. \ No newline at end of file +Vamos começar dando uma olhada sobre o que vamos contemplar nesse guia a seguir. diff --git a/_chapters/si/who-is-this-guide-for.md b/_chapters/si/who-is-this-guide-for.md index 6f1401dd1..a3bb5386c 100644 --- a/_chapters/si/who-is-this-guide-for.md +++ b/_chapters/si/who-is-this-guide-for.md @@ -13,6 +13,6 @@ comments_id: who-is-this-guide-for/96 දැනට මේ නිබන්ධනය සම්පූර්ණයෙන්ම නිර්මාණය කරලා තියෙන්නේ JavaScript සංවර්ධකයන් වෙනුවෙන්. අපි ඉස්සරහට වෙනත් පරිගණක භාෂා ගැනත් අවධානය යොමු කරාවි. නමුත් JavaScript යොදා ගැනීම හොද ආරම්භයක් කියලා අපි හිතනවා, මොකද JavaScript භාවිත කරලා සම්පුර්ණයෙන්ම වෙබ් අඩවියක ඉදිරි අන්තය (frontend) සහ පසු අන්තය (backend) යන දෙකම සංවර්ධනය කරන්න පුළුවන් නිසා. -පුද්ගලිකව, serverless විදිහට වෙබ් යෙදුම් නිර්මාණය කිරීම අපි කළ දැවැන්ත අනාවරණයක්. ඒ නිසා අපි ඉගෙනගත් දේ බෙදාගත හැකි යමක් නිර්මාණය කරන්න අපිට අවශ්‍ය වුණා. ඔබට අපි ගැන [**මෙතනින්**]({% link about/index.html %}) වැඩිදුර දැනගන්න පුළුවන් සහ මේ තාක්ෂණය භාවිත කරලා හදපු ආකෘති යෙදුම් ගැන [මෙතනින්]({% link showcase.md %}) ගිහින් බලන්නත් පුළුවන්. +පුද්ගලිකව, serverless විදිහට වෙබ් යෙදුම් නිර්මාණය කිරීම අපි කළ දැවැන්ත අනාවරණයක්. ඒ නිසා අපි ඉගෙනගත් දේ බෙදාගත හැකි යමක් නිර්මාණය කරන්න අපිට අවශ්‍ය වුණා. ඔබට අපි ගැන [**මෙතනින්**]({{ site.sst_url }}) වැඩිදුර දැනගන්න පුළුවන් සහ මේ තාක්ෂණය භාවිත කරලා හදපු ආකෘති යෙදුම් ගැන [මෙතනින්]({% link showcase.md %}) ගිහින් බලන්නත් පුළුවන්. ඉතින්, මේ නිබන්ධනයෙන් ආවරණය වෙන්නේ මොනවද කියලා දැනගෙන ම අපි ඉගෙනීම ආරම්භ කරමු. diff --git a/_chapters/who-is-this-guide-for.md b/_chapters/who-is-this-guide-for.md index 88e938a8d..95a12f2d7 100644 --- a/_chapters/who-is-this-guide-for.md +++ b/_chapters/who-is-this-guide-for.md @@ -11,7 +11,7 @@ This guide is meant for full-stack developers or developers that would like to b So you might be a backend developer who would like to learn more about the frontend portion of building serverless apps or a frontend developer that would like to learn more about the backend; this guide should have you covered. -On a personal note, the serverless approach has been a giant revelation for us and we wanted to create a resource where we could share what we've learned. You can read more about us [**here**](/about/index.html). And [check out a sample of what folks have built with SST]({% link showcase.md %}). +On a personal note, the serverless approach has been a giant revelation for us and we wanted to create a resource where we could share what we've learned. You can read more about us [**here**]({{ site.sst_url }}). And [check out a sample of what folks have built with SST]({% link showcase.md %}). We are also catering this solely towards JavaScript/TypeScript developers for now. We might target other languages and environments in the future. But we think this is a good starting point because it can be really beneficial as a full-stack developer to use a single language (TypeScript) and environment (Node.js) to build your entire application. diff --git a/_chapters/zh/who-is-this-guide-for.md b/_chapters/zh/who-is-this-guide-for.md index 22996d800..8f823036a 100644 --- a/_chapters/zh/who-is-this-guide-for.md +++ b/_chapters/zh/who-is-this-guide-for.md @@ -14,7 +14,7 @@ comments_id: who-is-this-guide-for/96 目前，我们仅将其提供给 JavaScript 开发人员。我们将来可能会针对其他的语言和环境。但我们认为这是一个很好的起点，因为对于使用单一语言（JavaScript）和环境（Node.js）来构建整个应用程序的全栈开发人员而言，它确实是有益的 。 -就个人而言，无服务器方法对我们来说是一个巨大的启示，并且，我们希望创建一种资源，我们能够在这里分享我们所学到的知识。你可以阅读更多关于[**我们**]({% link about/index.html %})的信息。此外，查看[一个用 SST 构建的示例]({% link showcase.md %})。 +就个人而言，无服务器方法对我们来说是一个巨大的启示，并且，我们希望创建一种资源，我们能够在这里分享我们所学到的知识。你可以阅读更多关于[**我们**]({{ site.sst_url }})的信息。此外，查看[一个用 SST 构建的示例]({% link showcase.md %})。 让我们先来看一下我们要介绍的内容。 diff --git a/_config.yml b/_config.yml index 4a7749ec3..4a2c3e375 100644 --- a/_config.yml +++ b/_config.yml @@ -13,16 +13,18 @@ # you will see them accessed via {{ site.title }}, {{ site.email }}, and so on. # You can create any custom variable you would like, and they will be accessible # in the templates via {{ site.myvariable }}. -title: SST +title: SST Guide email: hello@sst.dev jobs_email: jobs@sst.dev description: > # this means to ignore newlines until "baseurl:" - Build modern full-stack applications on AWS. + Learn how to build modern full-stack apps on AWS. description_full: > - An open source framework for building modern full-stack applications on AWS. + The most widely read resource for building full-stack serverless apps on AWS. baseurl: "" # the subpath of your site, e.g. /blog url: "https://sst.dev" # the base hostname & protocol for your site, e.g. http://example.com +sst_url: "https://sst.dev" + exclude: - .idea - LICENSE @@ -73,12 +75,10 @@ youtube_url: "https://www.youtube.com/c/sst-dev" social_cards_url: "https://social-cards.sst.dev" -permalink: /blog/:title:output_ext - stats: newsletter: "90,000" newsletter_short: "90k" - discord: "10k" + discord: "11k" github: "21000" github_short: "21k" diff --git a/_includes/blog-posts.html b/_includes/blog-posts.html deleted file mode 100644 index c2af44498..000000000 --- a/_includes/blog-posts.html +++ /dev/null @@ -1,25 +0,0 @@ - diff --git a/_includes/footer.html b/_includes/footer.html index 80cfc8ba2..9ae09045d 100644 --- a/_includes/footer.html +++ b/_includes/footer.html @@ -4,44 +4,13 @@
- + {{ site.title | escape }}
-
- - - -
-
+
-

© 2024 Anomaly Innovations

-
diff --git a/_includes/head.html b/_includes/head.html index 5646a3d96..25f86649b 100644 --- a/_includes/head.html +++ b/_includes/head.html @@ -53,9 +53,6 @@ {% elsif page.collection == "examples" and page.ref != "examples-index" %} - {% elsif page.path contains "_posts" %} - - {% elsif page.url == "/" %} {% assign default_title=site.description | url_encode | base64_encode | url_encode %} diff --git a/_includes/header.html b/_includes/header.html index e0f319d8c..88cc17e88 100644 --- a/_includes/header.html +++ b/_includes/header.html @@ -10,7 +10,7 @@
- {{ site.title | escape }} + {{ site.title | escape }} -
diff --git a/_layouts/post.html b/_layouts/post.html index bb3c07eab..39899e436 100644 --- a/_layouts/post.html +++ b/_layouts/post.html @@ -37,7 +37,7 @@

{{ page.title | escape }}

{% if page.collection == "archives" %}
- This chapter has been archived and is no longer updated. View the current version of the guide. + This chapter has been archived and is no longer updated. View the current version of the guide.
{% endif %} diff --git a/_posts/2021-07-23-serverless-stack-raises-1m-to-make-it-easy-to-build-serverless-apps.md b/_posts/2021-07-23-serverless-stack-raises-1m-to-make-it-easy-to-build-serverless-apps.md deleted file mode 100644 index 03062406e..000000000 --- a/_posts/2021-07-23-serverless-stack-raises-1m-to-make-it-easy-to-build-serverless-apps.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -layout: blog -title: SST raises $1M to make it easy to build serverless apps -author: jay ---- - -Today we are announcing our $1M seed round. The new funding helps us in our mission to make it easy for developers to build full-stack serverless applications. You can [read more about this announcement over on TechCrunch](https://techcrunch.com/2021/07/23/serverless-stack-raises-1m-for-open-source-application-framework/) as well. - -Our [SST]({{ site.sst_github_repo }}) allows developers to test and make changes to their applications by directly connecting their local machines to the cloud. The biggest issue that developers face while adopting serverless is the ability to debug their applications locally. With SST, developers are able to [set breakpoints and inspect their code](https://youtu.be/2w4A06IsBlU), just as they would with any other type of application. Since its public launch 5 months ago, SST has grown to over 2K stars on GitHub and has been downloaded over 60K times. - -We would like to take this opportunity to thank SST community for being involved right from day one. We couldn't have built SST without you. Your continued feedback has pushed us to improve every part of the framework. It has also allowed us to truly understand the problems developers face while trying to adopt serverless. Also thanks to you, [our Slack community]({{ site.slack_invite_url }}) has grown to nearly 500 members and is a welcoming space for anybody that's looking to use serverless. - -As more and more developers discover and adopt SST's [live local development environment]({{ site.docs_url }}/live-lambda-development); our team is committed to adding features to support their workflow. This commitment shows clearly in [our rapid release history](https://github.com/sst/sst/releases). - -We are also incredibly proud of what we've built with the [SST Guide]({% link guide.md %}), it is the most widely read resource for serverless. And [Seed](https://seed.run); the best way for teams to deploy and manage their serverless applications. - -The new funding allows us to expand the team to better serve the community and ensure that you have everything you need to build serverless applications. So if you are excited about where we are heading and would like to help our cause, [**we would like you to join our team**]({% link careers.html %})! diff --git a/_posts/2021-10-27-doorvest-is-using-sst-to-simplify-real-estate-investing.md b/_posts/2021-10-27-doorvest-is-using-sst-to-simplify-real-estate-investing.md deleted file mode 100644 index b830cb87f..000000000 --- a/_posts/2021-10-27-doorvest-is-using-sst-to-simplify-real-estate-investing.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -layout: blog -title: Doorvest is using SST to simplify real estate investing -description: In this post we are talking to Orlando Hui from Doorvest about how they are using SST and Seed to simplify real estate investing. -author: jay -image: assets/social-cards/case-study-doorvest.png ---- - -In this post we are talking to Orlando Hui from [Doorvest](https://doorvest.com) about how they are using [SST](/) and [Seed](https://seed.run) to simplify real estate investing. - - -### About Doorvest - -[Doorvest](https://doorvest.com) creates a modern way for people to own high-yield rental homes completely online. Doorvest gets to know a customer and their investment goals before identifying and buying a home on their behalf. It handles renovations and places a resident in it, then sells the home to the customer. - -Doorvest is a VC backed company with 30 plus employees. Orlando Hui is the lead engineer on the team and was responsible for implementing SST across their stack. - -### The Challenge - -While the original version of the Doorvest client was built using Serverless Framework, the dev workflow was really painful. _"Deployments took 7 minutes"_, says Orlando. For most cases they had to deploy to test their changes. So the commit, deploy, feedback loop was something that they couldn't continue to use. - -The original application also connected to resources that were not created in YAML and were created through the AWS Console. This was partly because it seemed easier to create them through the console, as opposed to working with the CloudFormation YAML that Serverless Framework uses. - -### Using SST - -The Doorvest team had been following [SST](/) since it's Hacker News launch back in February, 2021. But they were unable to find an excuse to use it internally. Then a couple of months ago they needed to build an application for the general contractors on Doorvest. This allowed them to try out SST in production. - -The team built everything from scratch, used the [constructs in SST]({{ site.docs_url }}/packages/resources) and CDK to define all their infrastructure as code. They also followed the best practices of separating their environments by AWS accounts. So each developer has their own AWS account, the staging and production environments are also in separate accounts. Their SST apps are deployed through [Seed](https://seed.run), and the combination of the two worked perfectly for them. - -_"SST doesn't have anything that's missing for us. We have everything we need."_, says Orlando. _"We don't have to do YAML anymore. The Live Lambda Dev is incredible."_ - -> "The Live Lambda Dev is incredible." - -Comparing their workflow from before, Orlando thinks, _"it's improved our productivity by at least 3 times"_. - -> "It's improved our productivity by at least 3 times." -> - -He also found the [SST Slack community]({{ site.slack_invite_url }}) while working on it. _"The Slack group has been super incredible"_, says Orlando. - -> "The Slack group has been super incredible." - -Recently, he was looking for WebSocket authorizer support and _"it got built almost instantly after I brought it up"_. - -### Looking Ahead - -_"Now everybody on the team just wants to migrate away from Serverless Framework"_, says Orlando. As a part of their current sprint they are figuring out how to move over to SST completely. - -The Doorvest engineering team is looking to grow 4x in 2022 and are actively seeking new engineers. They added 3 new folks recently and _"having everybody use SST has been great, especially the new engineers"_. - -### Learn More - -Learn more about the [job opportunities at Doorvest](https://www.builtinsf.com/company/doorvest) and help them in their cause to simplify real eastate investing. - ---- - -[Read more about SST](/) and [get started]({{ site.docs_url }}{{ site.docs_get_started }}) today. diff --git a/_posts/2021-10-28-buildforce-is-creating-the-first-ever-career-platform-for-the-construction-trade-with-sst.md b/_posts/2021-10-28-buildforce-is-creating-the-first-ever-career-platform-for-the-construction-trade-with-sst.md deleted file mode 100644 index 93854b62b..000000000 --- a/_posts/2021-10-28-buildforce-is-creating-the-first-ever-career-platform-for-the-construction-trade-with-sst.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -layout: blog -title: Buildforce is creating the first ever career platform for the construction trade with SST -description: We are talking to Michael Orcutt, the founder of Buildforce about their experience building with SST and Seed. -author: jay -image: assets/social-cards/case-study-buildforce.png ---- - -We are talking to Michael Orcutt, a co-founder of [Buildforce](https://buildforce.com) about their experience building with [SST](/) and [Seed](https://seed.run). - -### About Buildforce - -[Buildforce](https://buildforce.com) is building the first ever career platform for people in the construction trades, starting with those in the electrical trade. Its end-to-end platform enables people in the construction trades to maintain consistent work at fair pay and with employee benefits with our construction partners, an arrangement that is out of reach for many in the construction industry today. - -Since their launch in 2020, Buildforce has become the go-to partner helping dozens of the largest contractors across its focus geographies connect with this workforce. - -Buildforce currently operates in the state of Texas, has raised $5.5M to date, and is growing 10% week over week in 2021. Michael Orcutt is one of the founders of the company and is leading the engineering efforts. He is also highly involved in product and design as they build their web apps, mobile apps, and marketing site. - -### The Challenge - -The Buildforce team knew they wanted to build their applications using serverless due to the inherent benefits. They originally started out with Serverless Framework. But over time Serverless Framework became a headache. Everything from the deployment process to testing was cumbersome. _"We felt we were slow, velocity was down as the speed of development wasn't great"_, says Michael. _"We also found creating infrastructure in YAML challenging"_. They realized this just wouldn't work as they scaled the team. - -### Enter SST - -Around 2 months ago the team came together and decided they needed to make a change. They had heard about [SST](/) and the [SST Guide]({% link guide.md %}). They decided they needed to take a deeper look. - -As they tried out SST, _"We were blown away by the local development environment"_, says Michael. The entire team decided to move to SST. - -> "We were blown away by the local development environment." - -They decided to start a new SST app from scratch. They spent some time testing SST and within a month they had moved over completely. The new setup Michael says is _"Such a great experience. We are at least 1.5 to 2 times faster than before"_. - -> "We are at least 1.5 to 2 times faster than before." - -They also use [Seed](https://seed.run) for their deployment workflow. They typically branch from main, work locally, push to a feature branch. The feature branches get deployed through [Seed](https://seed.run) and connects to dev resources. Finally they rebase with master and that deploys to production. The dev and prod environments are on separate AWS accounts. - -### Looking Ahead - -Michael says they really need to grow the team. As more and more electricians are onboarded, they need to make sure every construction worker has a great experience and our operations team has the right tools to manage our workforce. - -From an architecture perspective, their single web application will most likely be split into multiple SST apps; one for their electricians, one for the contractors, and one for the ops team. They will also be introducing ElasticSearch for better search functionality. - -Thanks to SST their entire development setup works seamlessly, allowing them to focus on the needs of a fast growing business. - -### Learn More - -[Learn more about the job opportunities at Buildforce](https://joinbuildforce.recruitee.com). - ---- - -[Read more about SST](/) and [get started]({{ site.docs_url }}{{ site.docs_get_started }}) today. diff --git a/_posts/2021-11-11-leadent-digital-is-transforming-field-service-operations-with-sst.md b/_posts/2021-11-11-leadent-digital-is-transforming-field-service-operations-with-sst.md deleted file mode 100644 index 2642b2f70..000000000 --- a/_posts/2021-11-11-leadent-digital-is-transforming-field-service-operations-with-sst.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -layout: blog -title: Leadent Digital is transforming field service operations with SST -description: In this post we are talking to Ross Coundon, CTO of Leadent Digital about how they are using SST to transform field service operations. -author: jay -image: assets/social-cards/case-study-leadent.png ---- - -In this post we are talking to Ross Coundon, CTO of [Leadent Digital](https://leadent.digital) about how they are using [SST](/) and [Seed](https://seed.run) to transform field service operations. - -### About Leadent Digital - -[Leadent Digital](https://leadent.digital) provides the full spectrum of services from consulting advice to software development for field service operations. Their flagship product, the On My Way app provides real-time updates to customers on appointment visits, including expected time of arrival, appointment details and much more. Leadent's customers include Foxtel and Bosch Thermotechnology, and many others through a partnership with IFS. - -Ross Coundon, is the CTO at Leadent Digital and leads their software development -efforts. Ross has been building software for over 20 years, and after years of building -on-premise software was looking for a way to focus on solving business problems and not have to manage any servers. - -## The Challenge - -In their quest for reducing the operational overhead of building large applications, Ross -and his team experimented with AWS Elastic Beanstalk and Docker briefly before realizing that Lambda allowed them to build their MVPs far more easily and in a more cost effective -way. - -Some of the very early serverless applications at Leadent were built using Claudia.js -and it was fine for a handful of Lambda functions. But it was hard to test in a real-world context. - -This led them to Serverless Framework and serverless-offline. But there was _"no -confidence in going from an emulated offline environment to production"_, says Ross. It -wasn't testing the permissions or any of the connections within the app. _"You had to punt it over to AWS to find what was broken"_. - -He also didn't think YAML was the right way to define infrastructure. He was looking for -type support and looked at using `serverless.ts` with Serverless Framework. But felt the -documentation was lacking, and for anything that was not directly supported by Serverless -Framework, he needed to rely on a combination of guesswork and the AWS docs to piece the two together. - -This painful process of developing and testing led them to look at SST. - -## Enter SST - - -The constructs in SST made a lot of sense to Ross and his team. It allowed them to define all the infrastructure in one place and not have to use any YAML configuration. Better still, with full type support and IDE intellisense. - -They were also impressed with the Live Lambda Development environment. _"Knowing -that when I run an SST application I'm using real AWS infrastructure and my computer -is a part of the pipe was incredible"_, says Ross. - -SST allowed them to set breakpoints in their code and debug in real-time, which meant that _"you can iterate faster and build so much faster"_, says Ross. - -> "You can iterate faster and build so much faster." - -The entire SST local development process was a revelation for the team. _"I hadn't found anything like SST and haven't seen anything like it since"_, says Ross. - -> "I hadn't found anything like SST and haven't seen anything like it since." - -They also use [Seed](https://seed.run) to deploy their SST apps. All their major customers have separate deployments of their application. These are also deployed to separate AWS accounts. They use a PR based workflow in Seed and once their changes are merged to master, it gets deployed to all their customer accounts. - -They just recently completed migrating their flagship product completely to SST. And -next week one of their larger customers will be using the new version of their -application. - -## The Future - -The next 6 to 12 months is an exciting time for Ross and Leadent. They are looking to grow the team. They are also looking to expand the capabilities of their flagship product by adding live chat, so customers will be able to interact with the field service reps in real-time and they’ll be relying on SST for building this out. - -## Learn More - -Learn more about [Leadent Digital and their work here](https://leadent.digital). - ---- - -[Read more about SST](/) and [get started]({{ site.docs_url }}{{ site.docs_get_started }}) today. diff --git a/_posts/2021-11-16-henry-schein-one-the-worlds-largest-dental-practice-management-software-company-is-building-with-sst.md b/_posts/2021-11-16-henry-schein-one-the-worlds-largest-dental-practice-management-software-company-is-building-with-sst.md deleted file mode 100644 index 827e8a983..000000000 --- a/_posts/2021-11-16-henry-schein-one-the-worlds-largest-dental-practice-management-software-company-is-building-with-sst.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -layout: blog -title: Henry Schein One, the world's largest dental practice management software company is building with SST -description: In this post we are talking to Jack Fraser, a Software Engineering Manager at Henry Schein One; the world's largest dental practice management software company. They are using SST to power the patient booking experience and the management software used by thousands of dental practices globally. -author: jay -image: assets/social-cards/case-study-henry-schein-one.png ---- - -In this post we are talking to Jack Fraser, a Software Engineering Manager at [Henry Schein One](https://henryscheinone.com). They are using [SST](/) and [Seed](https://seed.run) to power the patient booking experience and the management software used by thousands of dental practices globally. - -## About Henry Schein One - -[Henry Schein One](https://henryscheinone.com) is the world’s largest dental practice management software company. Founded in 2018, Henry Schein One launched a new era of integrated dental technology by merging the market-leading practice management, patient communication and marketing systems of Henry Schein and Internet Brands into one company. - -Henry Schein, Inc. (Nasdaq: HSIC), Henry Schein One's parent company, is the largest wholesaler of dental and medical products to office-based practitioners. The company has been established for approximately 90 years, with a presence in 32 countries to offer hundreds of thousands of products to customers globally. The company is a Fortune World's Most Admired Company and is ranked number one in its industry for social responsibility by Fortune magazine. - -Jack Fraser is a Software Engineering Manager at Henry Schein One. His team is building out applications that'll power the patient booking experience and the management software for thousands of dental practices globally. - -## The Challenge - -As more dental practices around the world start to rely on digital services to manage their practices and patient booking; the challenge is then to _"build applications that are snappy and easy to use for patients"_, says Jack Fraser. Each practice brings in roughly 3000 patients and so they need to be able to scale rapidly as these will be rolled out globally. - -They felt AWS made sense and serverless would help them with their scaling needs. So a year ago, Jack's team built out a serverless application in Serverless Framework. It had around 14 separate services. - -However the experience wasn't great. The local development workflow was painful and using YAML to define the infrastructure didn't make as much sense. - -In addition, their frontend applications were deployed as static sites to AWS through the AWS CLI. As Serverless Framework didn't have great support for this. - -## Switching to SST - -This is around when they found SST and it made perfect sense for them. _"It was based on CDK, and while CDK is great it is really verbose"_, says Jack. - -> "CDK is great but it is really verbose" - -The other aspect that they found really appealing was the Live Lambda Development environment. _"We loved the Live Lambda debugging in SST"_. - -> "We loved the Live Lambda debugging in SST" - -Now they have 15 stacks in their SST app. With over 200 endpoints in their API. It also includes 4 Angular apps that use SST's [StaticSite construct]({{ site.docs_url }}/constructs/StaticSite). - -They also decided to move to GraphQL to manage their APIs. _"We are already using SST's [ApolloApi construct]({{ site.docs_url }}/constructs/ApolloApi)"_, says Phil Astle, a Senior Software Engineer on the team. - -It's also all deployed through [Seed](https://seed.run). _"We want to have a consistent release process"_, says Jack. Each developer on the team has 2 stages, a local one and a deployed one. There's also a sandbox environment and a production environment. - -The PR workflow in Seed allows them to do code reviews and usability testing. It also allows them to spin up new environments to show changes to customers and get direct feedback. - -Thanks to what SST and Seed offers, they decided to _"make a big bet on SST"_, says Jack. And they've gone all in on SST. - -> "We have gone all-in on SST" - -## Looking Ahead - -Jack's team is going to be creating multiple prod environments, one for a section of the practices for early rollouts and the second for the rest of their customers. They also need to setup multi-region deployments as they'll be entering new markets soon. - -They are looking to double the team over the next couple of months. So Jack thinks that they need a dev environment thats _"easy and intuitive"_. And a deployment workflow that just works. _"We are a talent dense team, so it's important to have great tooling to be as productive as possible"_, says Jack. - -## Learn More - -Learn about the [job opportunities at Henry Schein One](https://dentr.co.uk/jobs) and join the world's largest dental practice management software company. - ---- - -[Read more about SST](/) and [get started]({{ site.docs_url }}{{ site.docs_get_started }}) today. diff --git a/_posts/2022-05-05-announcing-sst-1-0-conf.md b/_posts/2022-05-05-announcing-sst-1-0-conf.md deleted file mode 100644 index 79201b96c..000000000 --- a/_posts/2022-05-05-announcing-sst-1-0-conf.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -layout: blog -title: Announcing SST 1.0 Conf -description: The first-ever SST conference! -author: jay -image: assets/social-cards/sst-1-0-conf.png ---- - -You might’ve [heard about our v1 release](https://github.com/sst/sst/releases/tag/v1.0.0-beta.26). As SST enters into a new phase, we wanted to do something special for our community. We are putting together a virtual community event to commemorate the launch! - -[**SST 1.0 Conf**]({{ site.v1_conf_url }}) is a free virtual event happening on May 17th, 2022 at 9am PDT. [Register for the conference now]({{ site.v1_conf_url }}). - -It’ll feature talks from the SST community about how they are using SST and serverless in their projects. Including folks from **Comcast**, **The LEGO Group**, **Analog Devices**, and **Shell**. We’ll also have a couple of live demos and workshops from the SST team. - -We know you are all very busy and we don’t want to take up your entire day. So we decided to make the talks really short, around 10 minutes each. We hope you’ll be able to join us. - -While most of the schedule has been finalized, we are looking for a couple more speakers. If you’d like to share something with the community, [fill out this short form](https://forms.gle/KTdbCLUy5oNwos2m7) and we’ll get in touch with you! - -We want to use this event as a way to bring our community together. To share what we’ve all learnt over the last year of using SST. - -## Next Steps - -- Head over to the [SST 1.0 Conf]({{ site.v1_conf_url }}) site and register. -- Join the [SST Slack]({{ site.slack_invite_url }}) (if you haven’t done so already). -- Share on [Twitter]({{ site.twitter_url }}) or [LinkedIn]({{ site.linkedin_url }}) that you’ll be joining [SST 1.0 Conf]({{ site.v1_conf_url }}). - -_Psst!_ Check out the domain [the conference website]({{ site.v1_conf_url }}) is hosted on. It might be a sign of things to come! diff --git a/_posts/2022-05-16-sst-v1.md b/_posts/2022-05-16-sst-v1.md deleted file mode 100644 index c4b0fc33b..000000000 --- a/_posts/2022-05-16-sst-v1.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -layout: blog -title: SST v1 -description: SST hits v1. -author: jay ---- - -SST has now officially hit v1. Join us at the [SST 1.0 Conf]({{ site.v1_conf_url }}) as we celebrate its launch! - -
- -
- -A huge thanks to everybody that helped test out the v1 beta versions! - -## Background - -SST was released a little over a year ago. Since then we’ve added [a web based dashboard]({{ site.docs_url }}/console) and [dozens of constructs]({{ site.docs_url }}/constructs)! - -While SST has been remarkably stable since its early releases, we learnt that there were some inconsistencies and confusing bits in the API. We also felt like we could do a better job of providing inline documentation. - -## Goals - -SST v1 addresses this by: - -- Making it easy to connect stacks -- Adding consistent interfaces for: - - Underlying AWS resources - - Underlying AWS resource names and ARNs -- Reducing the need for CDK imports -- Supporting inline TS Docs -- Laying the foundation for full typesafety - -You can [read more about SST v1’s goals over on the docs]({{ site.docs_url }}/constructs/v0/migration#goals). - -## Migrating - -Migrating to v1 should be very straightforward. Most of the changes are reorganizing and renaming construct properties, attributes, and adding TS Docs. The underlying resources (ie. the CloudFormation template) are mostly not impacted. There should be zero downtime during the upgrade. - -You can [follow the steps in the migration guide]({{ site.docs_url }}/constructs/v0/migration#upgrade-steps) to update. - -## SST v1 - -With the v1 release of SST, we’ve put together the key building blocks you need to create full-stack serverless applications. Let’s take a quick look at what SST v1 can do for you. - -### Easy to use Constructs - -At the heart of SST are its easy to use constructs. These allow you to define the infrastructure that your application needs. - -These constructs also come with great editor support. So you can both auto-complete on fields and read the docs inline. - -
- -
- -### Functional Stacks - -In native CDK, stacks are defined as classes. This requires a great deal of boilerplate code and makes it confusing to reference resources across stacks. To simplify this, SST v1 introduces the concept of Functional Stacks. - -
- -
- -### SST Console - -SST also comes with a web based dashboard to manage your apps. - -
- -
- -### Live Lambda Dev - -When you run `sst start`, it’ll start up the [Live Lambda Development]({{ site.docs_url }}/live-lambda-development) environment. This allows you to set breakpoints and test your Lambda functions locally. - -
- -
- -## SST 1.0 Conf - -To commemorate SST hitting v1 we are holding the [**SST 1.0 Conf**]({{ site.v1_conf_url }}). It’s a free virtual event filled with talks from the community including folks from Comcast, LEGO, Analog Devices, and Shell. - -It's streaming live on May 17th at 9am PDT. We hope to see you there! - -## Looking ahead - -It’s been an amazing year for SST. When I think about everything we’ve accomplished, I can’t help but wonder that it wouldn’t have happened without our community! A huge thanks to all of you for your support. - -We have some really exciting updates in store for you as we step into this new phase of development for SST. We’ll be sharing more about our direction in the coming weeks and we are giving a sneak peek at the [SST 1.0 Conf]({{ site.v1_conf_url }}). So stay tuned! diff --git a/_posts/2022-05-23-wrapping-up-sst-1-0-conf.md b/_posts/2022-05-23-wrapping-up-sst-1-0-conf.md deleted file mode 100644 index 9b362af6d..000000000 --- a/_posts/2022-05-23-wrapping-up-sst-1-0-conf.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -layout: blog -title: Wrapping up SST 1.0 Conf -description: Watch the recording of SST 1.0 Conf, our first-ever conference. -author: jay -image: assets/social-cards/sst-1-0-conf-replay.png ---- - -Hopefully everybody enjoyed [SST 1.0 Conf]({{ site.v1_conf_url }}) as much as we enjoyed putting it together. It allowed the community to come together and celebrate SST's v1 release. - -It's been a little over a year since SST launched and it's incredible to see how far it has come in this short time. SST now has over [6500 stars on GitHub]({{ site.sst_github_repo }}), [1900 developers in Slack]({{ site.slack_invite_url }}), and nearly [80000 folks have subscribed to our newsletter]({% link newsletter.md %}). Thousands of teams from companies like Comcast, Shell, Analog Devices, and The LEGO Group are using SST. - -### Watch the recording - -If you missed SST 1.0 Conf, don't worry you can [**watch the recording on YouTube**](https://youtu.be/6FzLjpMYcu8). - -
- -
- -All the talks are timestamped. So if you want to watch a specific talk, or rewatch one, you can do that right from YouTube. - -A huge thanks to the speakers for taking the time from their busy schedules to make this event a success. - -### Looking ahead - -Now that SST has hit v1, you might be wondering what we are doing next. We are going to be spending more time on the application code portion of your SST apps. To get an early preview of it, [check out Dax's talk from the conference](https://youtu.be/6FzLjpMYcu8?t=5182). - -SST 1.0 Conf also allowed us as a team to do a couple of things that we don't usually do. It allowed us to share a side of us that's hard to do on Slack. So moving forward we'll be sharing more about how we work. We'll be doing more livestreams and creating screencasts. You can [**subscribe to our channel on YouTube**]({{ site.youtube_url }}). - -### Give us your feedback - -We are already looking forward to the next SST conference. We've got a ton of ideas on what we'd like to do. But we'd appreciate if you took a second to [**give us some of your feedback on SST 1.0 Conf**](https://forms.gle/HwkDsMnsPEhzxbaPA). - -Once again, thanks to you all for attending SST 1.0 Conf and being a part of this amazing community! diff --git a/_posts/2022-06-23-moving-to-discord.md b/_posts/2022-06-23-moving-to-discord.md deleted file mode 100644 index 3a3083868..000000000 --- a/_posts/2022-06-23-moving-to-discord.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -layout: blog -title: Moving to Discord -author: jay ---- - -We are moving our Slack community to [Discord](https://discord.gg/sst)! While our Slack community has grown to over 2000 members, we feel that Discord is better aligned with supporting open source communities. - -To join our Discord server, head over to: [**discord.gg/sst**](https://discord.gg/sst) - -If you are curious about why we are moving to Discord, I shared some thoughts on this on Twitter. - -

We recently hit a big milestone for the SST community Slack.

2000+ members in a little over a year!

But we've been considering a move to Discord.

Let me share what's been going on because I'd like to hear what people think. https://t.co/pjtRx5UVBF

— Jay (@jayair) June 10, 2022
- -We hope to see you in [Discord](https://discord.gg/sst) soon! - -PS: The Slack community will be around while we transition. diff --git a/_posts/2022-06-25-sst-dev.md b/_posts/2022-06-25-sst-dev.md deleted file mode 100644 index ad0e11fe8..000000000 --- a/_posts/2022-06-25-sst-dev.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -layout: blog -title: SST.dev -author: jay ---- - -We are now officially changing our name from Serverless Stack to SST. We are also moving our domain from [serverless-stack.com](https://serverless-stack.com) to [sst.dev](https://sst.dev). - -We were previously called Serverless Stack and we were hosted at serverless-stack.com. Aside from being really long, it was also easy to confuse us with the Serverless Framework folks. We've been informally using SST but now with the new domain, we can make the change official! - -You can call us **SST** and visit us at [**sst.dev**](https://sst.dev)! diff --git a/_posts/2022-06-28-create-sst.md b/_posts/2022-06-28-create-sst.md deleted file mode 100644 index 36bad0cb8..000000000 --- a/_posts/2022-06-28-create-sst.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -layout: blog -title: "`create sst`" -author: jay ---- - -Today we are launching [`create sst`](https://github.com/sst/sst/tree/master/packages/create-sst) — a CLI that helps you get started with SST. It creates a full-stack starter that you can use to build your serverless applications. - -While serverless has been around for a few years, there isn't a [Twelve-Factor App](https://12factor.net) setup for it. - -With `create sst`, we are trying to bake a lot of these principles into a starter that you can use right away. Simply run: - -```bash -$ npm init sst -``` - -This will bootstrap a full-stack serverless application with end to end type-safety: - -- RDS as the database (with an option to use DynamoDB) - - [Kysely](https://github.com/koskimas/kysely) for SQL - - [ElectroDB](https://github.com/tywalch/electrodb) for DynamoDB -- GraphQL as the API - - [Pothos](https://pothos-graphql.dev) for building GraphQL schemas -- React as the frontend - -It also does a few other things that you can step through using a new tutorial we added in our docs: [docs.sst.dev/learn](https://docs.sst.dev/learn/) - -## Launch event - -We livestreamed the `create sst` launch event. You can [check it out on YouTube](https://www.youtube.com/watch?v=wBTDkLIyMhw). - -
- -
- -Here's roughly what we covered during the launch: - -- Backstory -- Demo of `create sst` -- [Tyler W. Walch](https://twitter.com/tinkertamper) from [ElectroDB](https://github.com/tywalch/electrodb) -- [Michael Hayes](https://twitter.com/yavascript) from [Pothos](https://pothos-graphql.dev) -- Looking ahead -- Q&A - -The video is timestamped, so you can jump ahead. - - -## Looking ahead - -With `create sst` we are planning to address most of the common concerns of application development; including handling authentication, managing secrets, writing tests, and more. As a team we are able to spend a lot more time on little details to get this setup in a place that makes your team as productive as possible. We'll also be open sourcing a codebase that we are working on internally that uses `create sst`. We'd like it to serve as an example of a real world production application. - -While `create sst` helps you get started with SST easily, it's better thought of as an opinionated way to assemble the primitives that SST provides. You might want to tweak this setup or use a different one entirely. - -We've got a lot more in store and we can't wait to share it with you all! diff --git a/_posts/2022-07-19-remixsite-construct.md b/_posts/2022-07-19-remixsite-construct.md deleted file mode 100644 index fcd77064c..000000000 --- a/_posts/2022-07-19-remixsite-construct.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -layout: blog -title: "`RemixSite` construct" -author: jay -image: assets/social-cards/remixsite-construct.png ---- - -The new [`RemixSite`]({{ site.docs_url }}/constructs/RemixSite) construct makes it easy to deploy [Remix](https://remix.run) apps to AWS. - -Remix is a frontend focused framework that delivers modern web experiences but by relying on web standards. The SST community has been looking for a way to deploy a Remix app with SST. - -Recently, [Sean Matheson](https://twitter.com/controlplusb) put together [a very comprehensive PR]({{ site.sst_github_repo }}/pull/1800) implementing an SST construct that would deploy a Remix app. - -[Frank](https://twitter.com/fanjiewang) made a couple of changes and merged the PR to officially add the `RemixSite` construct to the SST family of constructs. - -It allows you to: - -- Access other AWS resources in your Remix loaders and actions. -- Reference environment variables from your backend. -- Easily set custom domains. -- Host your Remix apps in single-region or on the Edge. - -## Launch event - -We hosted a [launch livestream on YouTube](https://www.youtube.com/watch?v=ZBbRZTTCwvU) where we did a deep dive of the construct and its features. - -
- -
- -We also, took a look at the internal architecture and the construct code. Here's roughly what we covered. - -- Intro -- Architecture -- Environment variables -- Access AWS services -- Custom domains -- Deploy to Edge -- How to get started -- Deep dive into the code -- How does it work with `sst start`? -- Why is the non-Edge setup the default? -- Should we be talk to the DB directly? -- Does the app size impact deploy time? -- What about the cache policy limit? -- Which Remix deployment target to use? -- Q&A - -The video is timestamped, so you can jump ahead. - -## Get started - -You can get started with the `RemixSite` construct by taking our example for a spin: - -``` bash -$ npx create-sst@latest --template=examples/remix-app my-sst-app -$ cd my-sst-app -$ npm install -$ npx sst start - -# Deploy to prod -$ npx sst deploy --stage prod -``` - -Also make sure to [check out the docs]({{ site.docs_url }}/constructs/RemixSite). diff --git a/_posts/2022-08-22-config.md b/_posts/2022-08-22-config.md deleted file mode 100644 index 00ef6a323..000000000 --- a/_posts/2022-08-22-config.md +++ /dev/null @@ -1,104 +0,0 @@ ---- -layout: blog -title: Config -author: jay -image: assets/social-cards/sst-config.png ---- - -We are launching a set of tools to securely manage secrets and environment variables in your SST apps, called `Config`. - -You can [**read more about it in detail over on our docs**]({{ site.docs_url }}/environment-variables). The `Config` libraries include: - -1. Constructs to define them - 1. [`Config.Secret`]({{ site.docs_url}}/constructs/Secret) - 2. [`Config.Parameter`]({{ site.docs_url }}/constructs/Parameter) -2. CLI to set secrets [`sst secrets [action]`]({{ site.docs_url }}/packages/cli#secrets-action) -3. Lambda helpers to fetch them [`@serverless-stack/node/config`]({{ site.docs_url }}/packages/node#config) - - Throws an error if they are not defined - - Fetches them automatically at runtime - - Provides typesafety and autocomplete - -Behind the scenes, Secrets and Parameters are stored as [AWS SSM](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) Parameters in your AWS account. They are stored with the _Standard Parameter type_ and _Standard Throughput_. - -This makes Config [**free to use**](https://aws.amazon.com/systems-manager/pricing/) in your SST apps. - -## Launch event - -We hosted a [launch livestream on YouTube](https://www.youtube.com/watch?v=6sMTfoeshLo) where we did a deep dive of the Config and its internals. - -
- -
- -The video is timestamped and here's roughly what we covered. - -1. Intro -2. Demo -3. Deep Dive - 1. Deep dive into the Parameters code - 1. Parameter vs Lambda environment variables - 1. Deep dive into the Secrets code - 1. IAM permission for fetching secrets - 1. CLI command `sst secrets` - 1. Secrets fallback -4. Q&A - 1. Q: What is the AWS cost of using Config? - 1. Q: What does the SSM path look like? - 1. Q: Managing secrets in my CI pipeline - 1. Q: Managing secrets across AWS accounts - 1. Q: Accessing Config inside or outside the handler - 1. Q: Would changing a secret require redeployment? - 1. Q: Using Config for tests - 1. Q: SSM vs Secret Manager - 1. Q: Export secrets to a .env file - 1. Q: Reference Config across multiple SST apps - -## Get started - -To get started, define a secret in your stacks. - -```typescript -import { Config, StackContext } from "@serverless-stack/resources"; - -export default function SecretsStack({ stack }: StackContext) { - const STRIPE_KEY = new Config.Secret(stack, "STRIPE_KEY"); - - return { STRIPE_KEY }; -} -``` - -Use the config option to pass the secret into the function. - -```typescript -import { use, Function, StackContext } as sst from "@serverless-stack/resources"; -import SecretsStack from "./SecretsStack"; - -export default function MyStack({ stack }: StackContext) { - const { STRIPE_KEY } = use(SecretsStack); - - new Function(stack, "MyFunction", { - handler: "lambda.handler", - config: [STRIPE_KEY], - } -}; -``` - -In your terminal, run the `sst secrets` command to set a value for the secret: - -```bash -$ npx sst secrets set STRIPE_KEY sk_test_abc123 -``` - -Finally in your function code, use the `@serverless-stack/node/config` library to reference the secret value: - -```typescript -import { Config } from "@serverless-stack/node/config"; - -export const handler = async () => { - console.log(Config.STRIPE_KEY); - - // ... -}; -``` - -To learn more [**check out our docs**]({{ site.docs_url }}/environment-variables). diff --git a/_posts/2022-08-29-testing-in-sst.md b/_posts/2022-08-29-testing-in-sst.md deleted file mode 100644 index 8390ebffd..000000000 --- a/_posts/2022-08-29-testing-in-sst.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -layout: blog -title: Testing in SST -author: jay -image: assets/social-cards/sst-testing.png ---- - -You can write tests for your SST apps using the new [`sst load-config`]({{ site.docs_url }}/packages/cli#load-config) CLI. It auto-loads secrets and config for your tests. - -Meaning that it'll load the [`Config`]({% link _posts/2022-08-22-config.md %}) of your app, but for your tests. - -So for example, this command loads your `Config` and runs your tests using [Vitest](https://vitest.dev). - -```bash -$ sst load-config -- vitest run -``` - -Also, make sure to [check out our launch announcement for `Config`]({% link _posts/2022-08-22-config.md %}) in case you missed it. - -We updated the [`create sst`]({{ site.docs_url }}/packages/create-sst) GraphQL starter to include the updated `npm test` script. - -```js -"test": "sst load-config -- vitest run" -``` - -We also have a [new chapter in our docs dedicated to testing]({{ site.docs_url }}/advanced/testing). It includes how to write tests for the different parts of your app: - -- Tests for your domain code. Recall that we recommend [Domain Driven Design]({{ site.docs_url }}/learn/domain-driven-design). -- Tests for your APIs, the endpoints handling requests. -- Tests for your stacks, the code that creates your infrastructure. - -## Launch event - -We hosted a [launch livestream on YouTube](https://www.youtube.com/watch?v=YtaxDURRjHA) where we talked about how to write tests for your SST apps. - -
- -
- -The video is timestamped and here's roughly what we covered. - -1. Intro -2. Setting up a new app -3. Testing domain code -4. Testing APIs -5. Testing stacks -6. Deep dive into `sst load-config` -7. Q&A - 1. How to test asynchronous workflow? - 2. How to run tests in parallel? - -## Get started - -To get started, create a new SST app with our GraphQL starter. - -```bash -$ npx create-sst@latest -``` - -Make sure to select the `graphql` and `DynamoDB` option. - -Next, install the dependencies. - -```bash -$ cd my-sst-app -$ npm install -``` - -Let's deploy the app once. This'll create all the infrastructure for your app and the `Config`. Recall that we use AWS SSM to store our secrets and parameters. - -```bash -$ npm run deploy -``` - -And you can run your tests by running: - -```bash -npm test -``` - -Make sure to check out the sample test included with the starter to get a sense of how it all works! - -To learn more [**check out our docs**]({{ site.docs_url }}/advanced/testing). diff --git a/_posts/2022-09-01-auth.md b/_posts/2022-09-01-auth.md deleted file mode 100644 index 0ce80f653..000000000 --- a/_posts/2022-09-01-auth.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -layout: blog -title: Auth -author: jay -image: assets/social-cards/sst-auth.png ---- - -Today we are launching `Auth` — a modern lightweight authentication library for your SST apps. - -With a simple set of configuration, it'll create a function that'll handle various authentication flows. You can then attach this function to your API and SST will help you manage the session tokens. - -`Auth` is completely stateless, standards based, and free to use. - -You can [read more about it over on our docs]({{ site.docs_url }}/auth). - -## Overview - -`Auth` is made up of the following pieces: - -1. [`Auth`]({{ site.docs_url }}/constructs/Auth) — a construct that creates the necessary infrastructure. - - - The API routes to handle the authentication flows. - - Securely generates a RSA public/private keypair to sign sessions. - - Stores the RSA keypair as secrets in the app's [`Config`]({{ site.docs_url }}/environment-variables). - -2. [`AuthHandler`]({{ site.docs_url }}/packages/node#authhandler) — a Lambda handler function that can handle authentication flows for various providers. - - - High level adapters for common providers like Google, GitHub, Twitch, etc. - - OIDC and OAuth adapters that work with any compatible service. - - A `LinkAdapter` to generate login links that can be sent over email or SMS. - - Can be extended with custom adapters to support more complex workflows, like multi-tenant SSO. - -3. Session — a library for issuing and validating authentication sessions in your Lambda function code. - - - Implemented with stateless JWT tokens that are signed with the RSA keypairs mentioned above. - - Support for passing tokens to the frontend via a cookie or the query string. - - Full typesafety for issuing and validating sessions with the [`useSession`]({{ site.docs_url }}/packages/node#usesession) hook. - -## Launch event - -We hosted a [launch livestream on YouTube](https://www.youtube.com/watch?v=cO9Chk6sUW4) where we did a demo and a deep dive into the internals. - -
- -
- -The video is timestamped and here's roughly what we covered. - -1. Intro -2. What is Auth? -3. Setting up the construct -4. Configuring the AuthHandler function -5. Magic link adapter -6. Issuing a session -7. Validating a session -8. Behind the scenes -9. Outro - -## Get started - -[Follow the **Setup** section]({{ site.docs_url }}/auth#setup) in our docs to get started. diff --git a/_posts/2022-09-12-learn-to-build-with-sst.md b/_posts/2022-09-12-learn-to-build-with-sst.md deleted file mode 100644 index 349e9e24d..000000000 --- a/_posts/2022-09-12-learn-to-build-with-sst.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -layout: blog -title: Learn to build with SST -author: jay -image: assets/social-cards/learn-sst.png ---- - -We have a brand new tutorial that teaches you the basics of SST. And you can watch it as a video as well! - -### New Tutorial - -You can check out the new tutorial here — [**docs.sst.dev/learn**]({{ site.docs_url }}/learn/) - -This new tutorial uses a [GraphQL starter]({%link _posts/2022-06-28-create-sst.md %}), to build a simple Reddit clone. We go through the workflow of adding a new feature. - -In addition to covering the basics of SST, this tutorial sets you up with all the other tools and packages you need to build a full-stack serverless application. - -So if you are just getting started with SST, or serverless, or you want to learn how to build full-stack applications; this tutorial is for you! - -### Video Tutorial - -We hosted a [livestream on YouTube](https://www.youtube.com/watch?v=i7xEKHWTKNk) where we worked through the tutorial and talked about it in detail. - -This will help if you want to follow along with the tutorial as a video. - -
- -
- ---- - -We'll be putting out more _"101"_ style videos to help you get started with SST. Make sure to [**subscribe to our YouTube channel**]({{ site.youtube_url }}) to get notified! diff --git a/_posts/2022-09-23-long-running-jobs.md b/_posts/2022-09-23-long-running-jobs.md deleted file mode 100644 index 9cbd65a64..000000000 --- a/_posts/2022-09-23-long-running-jobs.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -layout: blog -title: Long running jobs -author: jay -image: assets/social-cards/sst-job.png ---- - -We launched a new construct that makes it easy to run functions longer than 15 minutes — [`Job`]({{ site.docs_url }}/long-running-jobs) - -These are useful for cases where you are running async tasks like video processing, ETL, and ML. A `Job` can run for up to 8 hours. - -`Job` is made up of: - -1. [`Job`]({{ site.docs_url }}/constructs/Job) — a construct that creates the necessary infrastructure. -2. [`JobHandler`]({{ site.docs_url }}/packages/node#jobhandler) — a handler function that wraps around your function code in a typesafe way. -3. [`Job.run`]({{ site.docs_url }}/packages/node#jobrun) — a helper function to invoke the job. - -## Launch event - -We hosted a [launch livestream](https://www.youtube.com/watch?v=7sYdSbmi-ik) where we demoed the new construct, did a deep dive, and answered some questions. - -
- -
- -The video is timestamped and here's roughly what we covered. - -1. Intro -2. Demo -3. Deep Dive - - Deep dive into the construct - - Granting permissions for running the job - - Typesafety - - Defining the job handler - - Running the job - - Live debugging the job -4. Q&A - - Q: When should I use `Job` vs `Function`? - - Q: Is `Job` a good fit for batch jobs? - - Q: Why CodeBuild instead of Fargate? - -## Get started - -Here's how you use the new `Job` construct. Start by creating a new job. - -```typescript -import { Job } from "@serverless-stack/resources"; - -const job = new Job(stack, "MyJob", { - srcPath: "services", - handler: "functions/myJob.handler", -}); -``` - -Add the job handler. - -```typescript -import { JobHandler } from "@serverless-stack/node/job"; - -declare module "@serverless-stack/node/job" { - export interface JobTypes { - MyJob: { - foo: string; - }; - } -} - -export const handler = JobHandler("MyJob", async (payload) => { - // Do the job -}); -``` - -Finally invoke the job. - -```typescript -import { Job } from "@serverless-stack/node/job"; - -function someFunction() { - await Job.run("MyJob", { - payload: { - foo: "Hello World", - }, - }); -} -``` - -Note that the `payload` and job name `MyJob` here are typesafe. - -For a full tutorial check out the [**Quick Start**]({{ site.docs_url }}/long-running-jobs#quick-start) in the docs. diff --git a/_posts/2022-12-05-is-serverless-ready-episode-1.md b/_posts/2022-12-05-is-serverless-ready-episode-1.md deleted file mode 100644 index 24a1cceb9..000000000 --- a/_posts/2022-12-05-is-serverless-ready-episode-1.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -layout: blog -title: "Is serverless ready?" -image: assets/social-cards/is-serverless-ready.png -author: jay ---- - -Today we are launching a new livestream series called — _"Is serverless ready?"_, where we'll be showcasing the next generation of serverless tools and creators. - -[![Is serverless ready?](/assets/social-cards/is-serverless-ready.png)](https://isserverlessready.com) - -Over the next few weeks, we'll have speakers from Astro, Solid, Bun, PlanetScale, Mongo, SST, and more. - -It's a chance for these tools and services to show off what they are working on and how they are making _serverless ready_. - -So head over to [**isserverlessready.com**](https://isserverlessready.com) and register. We'll send you an email when the next episode is coming out! diff --git a/_posts/2022-12-06-sst-v2-preview.md b/_posts/2022-12-06-sst-v2-preview.md deleted file mode 100644 index f48cd499f..000000000 --- a/_posts/2022-12-06-sst-v2-preview.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: blog -title: "SST v2 Preview" -author: jay ---- - -As the first episode of the [Is serverless ready?](https://isserverlessready.com) series, we are showing off a preview of SST's upcoming v2 release. - -You can check it out on YouTube here. - -
- -
- -The video is timestamped and here's roughly what's going to be released as a part of SST v2: - -1. **Monopackage** — SST is now going to use a monopackage. Moving from `@serverless-stack` to simply `sst`. -1. **New config** — There's a new config file. A `.js` file instead of the `.json`. Similar to what Vite has. -1. **New functions API** — We've refactored the props in the SST Functions construct. -1. **Improved codegen** — We've reworked how SST codegens your types. -1. **pnpm support** — We've made SST compatible with [pnpm](https://pnpm.io). We've internally migrated to pnpm as well! -1. **New CLI UI** — There's an all new CLI UI, that makes it easier to figure out what the CLI is doing. -1. **Faster CLI** — We've refactored the entire CLI codebase and optimized for speed. It's a lot faster than before. -1. **Faster Live Lambda Dev** — We've also adopted a new debug stack infrastructure, so [Live Lambda Dev](https://docs.sst.dev/live-lambda-development) is now way faster than before! -1. **Building modern frontends** — We are also going to be introducing new constructs for [Astro](https://astro.build) and [Solid](https://www.solidjs.com). -1. **OpenNext** — We also launched a new open source initiative called [OpenNext](https://open-next.js.org) to allow Next.js apps to work on AWS, exactly like they do on Vercel. - -SST v2 is now in beta and we need your help testing it. So [**make sure to join us on Discord and take it for a spin**]({{ site.discord_invite_url }}). diff --git a/_posts/2023-02-27-sst-v2.md b/_posts/2023-02-27-sst-v2.md deleted file mode 100644 index 2eae18534..000000000 --- a/_posts/2023-02-27-sst-v2.md +++ /dev/null @@ -1,113 +0,0 @@ ---- -layout: blog -title: "SST v2" -author: jay -image: assets/social-cards/sst-v2.png ---- - -SST v2 is ready. Here's what's new and how you can learn more about it. - -## What is SST v2 - -We completely rewrote SST to be simpler, faster, and easier to work with. [Check out this video](https://youtu.be/v97-SJY1Mb0) to get a quick sense of what SST v2 is all about. - -
- -
- -Adam and Dax also did a whole [podcast episode on SST v2](https://tomorrow.fm/8) and the rewrite process. - - - -We also did a [launch livestream](https://www.youtube.com/watch?v=v6oqlnY6-Vc) where we talked about what's new in v2, how to upgrade, and deep dive into the new codebase. We also answered some questions from the community. - -
- -
- ---- - -## Upgrade to v2 - -In general most of the changes are ergonomic and it should be a pretty simple upgrade process. Check out our docs for the [**upgrade guide**]({{ site.docs_url }}/upgrade-guide#upgrade-to-v20). - ---- - -## Features - -Here's a quick rundown of the major changes. - -- **Monopackage** - - The first major change is that we are moving to a new npm package — [**`sst`**](https://www.npmjs.com/package/sst) - - We are also moving to a monopackage architecture. So instead of installing `@serverless-stack/cli` or `@serverless-stack/resources`; you simply need to install `sst`. - - All the constructs can be imported from `sst/constructs`. And the Node client is under `sst/node`. - -- **New CLI** - - This new package also powers a brand new CLI. It's faster and has a cleaner UI to go with it. - - ```bash - SST v2.0.38 ready! - - → App: my-sst-app - Stage: Jay - Console: https://console.sst.dev/my-sst-app/Jay - - ✓ Deployed: - Database - Api - API: https://4f574d6lqc.execute-api.us-east-1.amazonaws.com - Web - SITE: https://localhost:3000 - ``` - -- **Faster Live Lambda** - - We've reworked how [Live Lambda]({{ site.docs_url }}/live-lambda-development) works! It's a lot faster than before and it does not need to deploy any new infrastructure for it. So no more _Debug Stack_! - - You can [read more about the changes here]({{ site.docs_url }}/live-lambda-development#how-it-works). - -- **`sst.config.ts`** - - We've also changed how you configure your SST apps. We've replaced the old `sst.json` with a `sst.config.ts`. - - ```typescript - export default { - config(_input) { - return { - name: "my-sst-app", - region: "us-east-1", - }; - }, - stacks(app) { - app.stack(Database).stack(Api).stack(Web); - }, - } satisfies SSTConfig; - ``` - - You can [read more about the new config here]({{ site.docs_url }}/configuring-sst). - -- **New frontends** - - With SST v2, we've upgraded support for all the modern frontends out there. Our [`NextjsSite`]({{ site.docs_url }}/constructs/NextjsSite) construct supports Next.js 13, thanks to our new [OpenNext](https://open-next.js.org) project. - - We also added a [`AstroSite`]({{ site.docs_url }}/constructs/AstroSite) construct for [Astro](https://astro.build) and the [`SolidStartSite`]({{ site.docs_url }}/constructs/SolidStartSite) construct for [Solid](https://www.solidjs.com). - -- **pnpm support** - - SST now natively supports [pnpm](https://pnpm.io)! Our new monorepo templates are now built to work with pnpm as well. - -- _**And more...**_ - - There's also a new cleaned up functions API, a better way to generate types, and more. For all the details check out this preview of SST v2 we did recently. - -
- -
- ---- - -[**Seed**](https://seed.run) also [supports SST v2](https://seed.run/blog/sst-v2-support). So go ahead and upgrade your apps and [**join us on Discord**]({{ site.discord_invite_url }}) if you have any questions! diff --git a/_posts/2023-04-17-open-next-v1.md b/_posts/2023-04-17-open-next-v1.md deleted file mode 100644 index 2c88d3876..000000000 --- a/_posts/2023-04-17-open-next-v1.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -layout: blog -title: "OpenNext 1.0" -author: jay ---- - -OpenNext 1.0 is out. You can try it now with the `NextjsSite` construct. - -## What is OpenNext - -[OpenNext](https://open-next.js.org) is an open-source Next.js serverless adapter created by the SST team. It allows you to self-host Next.js _serverlessly_. - -To celebrate the 1.0 release, we created a fun video. - -
- -
- -## Background - -Next.js does not support self-hosting your app using serverless. There have been several projects to try and fix this. However, this is not easy to do, as it requires reverse engineering how Vercel deploys Next.js internally. As a result most of these attempts have failed or have ended up as closed source paid implementations. - -The goal of OpenNext is to create a free open source, framework agnostic, serverless adapter for Next.js. - -## OpenNext 1.0 - -OpenNext was created back in December, 2022. Since then the repo has grown to over 1000 stars on GitHub. The community has really come together to ensure that OpenNext supports all of Next.js 13's features. The OpenNext channel is also one of the most active channels on our [Discord]({{ site.discord_invite_url }}). - -While OpenNext is already being used in production, the [1.0 release](https://github.com/sst/open-next/releases/tag/v1.0.0) marks a significant milestone in terms of stability and performance. - -We'd love for you to take it for a spin. - -## Get started - -Here's how you can use OpenNext to deploy your Next.js app to AWS with SST. - -```bash -$ npx create-next-app -$ npx create-sst -$ npx sst deploy -``` - -[**Check out the full tutorial**]({{ site.docs_url }}/start/nextjs). If you are using a different framework, check out the [other deployment options](https://github.com/sst/open-next/blob/main/README.md#deployment). - ---- - -We could use your support in maintaining OpenNext, make sure to [join `#open-next` on Discord]({{ site.discord_invite_url }}) and [star us on GitHub](https://github.com/sst/open-next). diff --git a/_posts/2023-09-22-new-sst-console.md b/_posts/2023-09-22-new-sst-console.md deleted file mode 100644 index 277bc637c..000000000 --- a/_posts/2023-09-22-new-sst-console.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -layout: blog -title: "New SST Console" -author: jay ---- - -The new SST Console is out. You can [learn more]({{ site.docs_url }}/console) about it over on our docs. - -### What is the SST Console - -The SST Console is a web based dashboard to manage your SST apps. With it you can invoke functions, debug issues, view logs, and manage all your apps with your team — [**console.sst.dev**]({{ site.console_url }}) - -### Features - -#### Logs - -With the SST Console, you don't need to go to CloudWatch to look at the logs for your functions. It also supports a couple of modes; _recent_, _live_, and _time intervals_. - -#### Issues - -The SST Console will automatically show you any errors in your Lambda functions in real-time. There is: - - **Nothing to setup**, no code to instrument - - **Source maps** are supported **automatically**, no need to upload - - **No impact on performance** or cold starts, since the functions aren't modified - -#### Local logs - -When the Console starts up, it checks if you are running `sst dev` locally. If so, then it'll show you real-time logs from your local terminal. - -### Open source - -The Console is built with SST, deployed with [Seed](https://seed.run), and you can [view the source on GitHub](https://github.com/sst/console). - -The codebase is also a good example of what a production SST app looks like. - -### Your team and AWS accounts - -You can create a workspace in the Console, invite your team, and connect all your AWS accounts. It'll automatically discover your SST apps. - -### Pricing - -The SST Console pricing is based on the number of times the Lambda functions in your SST apps are invoked per month. It comes with a free tier of 1M invocations. - -You can [read more about it over on the docs]({{ site.docs_url }}/console#pricing). - -### Old Console - -The old SST Console is still accessible at [old.console.sst.dev](https://old.console.sst.dev). But we'll be moving away from it in the future. - -### Learn more - -[Learn more about the new SST Console]({{ site.docs_url }}/console). And if you have any questions, [join us over on Discord]({{ site.discord_invite_url }}). diff --git a/_posts/2024-01-29-moving-away-from-cdk.md b/_posts/2024-01-29-moving-away-from-cdk.md deleted file mode 100644 index fe5c3db39..000000000 --- a/_posts/2024-01-29-moving-away-from-cdk.md +++ /dev/null @@ -1,597 +0,0 @@ ---- -layout: blog -title: "Moving away from CDK" -author: jay ---- - -You might've heard that we are working on a new version of SST (called [Ion](https://github.com/sst/ion)), that's not based on CDK. In this post we'll talk about why we are moving away from CDK and what's going to change. - -You might've also seen the demo AI app we built with it — [movies.sst.dev](https://movies.sst.dev) - -[![SST Ion Movies demo AI app](/assets/blog/sst-ion-movies-demo-ai-app.png)](https://movies.sst.dev) - -This is going to be a fairly long post, so here's an outline of what we'll be covering. - -1. [What is Ion](#what-is-ion) -2. [What’s Wrong With CDK & CFN?](#whats-wrong-with-cdk--cfn) - - [Design Flaws](#design-flaws) - 1. [CFN Is a Black Box](#1-cfn-is-a-black-box) - 2. [CDK Is Not IaC, It’s a CFN Hack](#2-cdk-is-not-iac-its-a-cfn-hack) - - [Practical Problems](#practical-problems) - 1. [Linking Resources](#1-linking-resources) - 2. [Cyclical Dependencies](#2-cyclical-dependencies) - 3. [Export in Use](#3-export-in-use) - 4. [Swallowing Errors](#4-swallowing-errors) - 5. [Custom Resource Hacks](#5-custom-resource-hacks) - 6. [Rollback Hell](#6-rollback-hell) - 7. [Double Builds](#7-double-builds) - 8. [Stack Resource Limits](#8-stack-resource-limits) - 9. [Orphan Stacks](#9-orphan-stacks) - 10. [Importing Resources](#10-importing-resources) - 11. [Slowness](#11-slowness) -3. [Why The Change](#why-the-change) - - [Background](#background) - - [Supporting Non-AWS Providers](#supporting-non-aws-providers) - - [What Changed](#what-changed) - - [Working With Pulumi](#working-with-pulumi) -4. [How Does Ion Work](#how-does-ion-work) -5. [Roadmap](#roadmap) - - [Step 0: Ion Prototype Demo](#step-0-ion-prototype-demo) - - [Step 1: Ion General Release](#step-1-ion-general-release) - - [Step 2: Ion → SST v3](#step-2-ion--sst-v3) -6. [What About SST v2](#what-about-sst-v2) -7. [What About Migrating](#what-about-migrating) - - [Is Ion Right For Me](#is-ion-right-for-me) - - [What Ion Is Not](#what-ion-is-not) -8. [What’s Our Goal](#whats-our-goal) -9. [FAQ](#faq) - -We also covered this post on a livestream. - -
- -
- ---- - -# What Is Ion? - -Ion is a code name for a new engine for deploying SST applications. The constructs (or components) are defined using [Terraform](https://www.terraform.io) providers and deployed using [Pulumi](https://www.pulumi.com); as opposed to CDK and CloudFormation (CFN). - -The components look roughly the same as they do today and it'll still be completely open source. But there are some differences. The biggest one being that you cannot use a CDK construct in Ion. You'll need to migrate it over. - -Once Ion is stable, it'll be released as SST v3. This is a huge change, so let's look at why we are doing this. - ---- - -# What's Wrong With CDK & CFN? - -If you've spent time in the SST community or if you've talked to other SST users, you've probably heard complaints about CDK or CloudFormation being slow. Or you've run into deployment failures and rollbacks. While these are annoying, is it enough to switch? - -In the following sections I'll outline some of the underlying design flaws with the CDK & CFN model. I'll also talk about the practical implications of these problems and how some of these have turned into deal-breakers for us. - -## Design Flaws - -Most of the problems with CDK & CFN stem from two specific design flaws. Let's start with the basics. This is what deploying a CDK (and SST) app roughly looks like. - -```txt -CDK Constructs > CloudFormation Templates > CloudFormation Deployment -``` - -Your CDK constructs generate a CloudFormation template (JSON), that is then sent to CloudFormation (the service) and it deploys your infrastructure. It's important to understand that this is a two step process. - -The CloudFormation template defines *what* infrastructure you want to create. It does not describe *how* to create it. That is determined completely by AWS CloudFormation, the service. - -### 1. CFN Is a Black Box - -You give AWS CloudFormation a list of resources to create. It'll internally call the AWS SDK to create a resource. Then poll it until it's complete. It'll also maintain state of the resources it's managing. - -Both the process it runs and the state it maintains are completely opaque and handled on the AWS side. CloudFormation does not run locally. You cannot customize it as a user and as we'll see later, neither can CDK. - -> CloudFormation is a black box that does not run locally. - -As a framework author that's trying to build a better developer experience on AWS, this limits what we can do. And this turns out to be a deal-breaker. We'll look at why below. We'll also look at the alternative from the Terraform world. - -### 2. CDK Is Not IaC, It's a CFN Hack - -On the CDK side, we write TypeScript code that defines our infrastructure. But CDK doesn't *create* the infrastructure you define. It generates a CloudFormation template (JSON) that CloudFormation will use to create your infrastructure. - -> CDK doesn't create the infrastructure you define. - -The distinction might seem subtle but it's a big reason for a lot of problems people run into. Let's look at an example with some *CDK like* code. - -```ts -const fn = new Function(); - -const dist = new CloudFront(); - -fn.addEnvironment({ - key: "endpoint", - value: dist.url, -}); -``` - -Here, CDK converts your function and CloudFront distribution definition into a CloudFormation JSON block for each resource, it fills in the unknown values (distribution URL that the function environment needs) with *tokens* that'll be resolved once the resources are deployed. It also uses this to figure out the order in which your resources need to be created. - -This has two key implications: - -1. The order you write your code in, is not the order in which it'll be deployed. Here the distribution will be created first. -2. Since this is converted into a large JSON object, you cannot do certain operations in your CDK code. - -This odd behaviour makes a lot more sense when you realize that CDK is masquerading as a an IaC. When in reality it's just a CloudFormation hack. - -One other place where this hack becomes apparent is in CDK's concept of an *app*. A CDK app is a collection of multiple stacks. CloudFormation doesn't have a concept of an app. So CDK has to hack your stacks together to make them seem like an app. - -We'll look at the practical implications of this design flaw below. We'll also look at an alternative design that sidesteps all these issues. - -## Practical Problems - -The above might sound like *theoretical* problems and you might be wondering how this impacts me as a user. Let's look at the practical implications of these design flaws. - -The list below is not comprehensive but they make up most of our support cases. - -### 1. Linking Resources - -Say you have a Next.js app that shows a list of blog posts; where these posts are stored in a DynamoDB table. When your Next.js app builds, it'll generate this page by querying your database for these posts. So to generate your Next.js build, you'll need to deploy the table first. But CloudFormation needs you to provide the assets that your resources need (the Next.js site) to do a deploy. - -Effectively meaning that you need to first deploy your database before deploying your Next.js site. This needs two deploys. It applies to any two resources where an asset for one depends on another (there's a Custom Resource hack that's used for cases like this but it won't work here and has its own problems). - -This problem is a deal-breaker for users that are deploying to multiple environments. Since every time they create a new environment, they'll need to deploy their app in two steps. - -> You'll need to deploy your app in two steps, this makes it a deal-breaker. - -Let's assume you are able to put up with this at your company. You'll run into a new problem. Let's say your Next.js site depends on the value of a resource that's set as a part of the deploy process. Something like a [Config Parameter](https://docs.sst.dev/config). SST needs to pull this value before the deploy, to build your Next.js site. But since this hasn't been re-deployed yet, it can only fetch its previously deployed value. This can be really hard to debug because it's not immediately apparent what's going on. - -SST exists today because of two main reasons; [Live Lambda](https://docs.sst.dev/live-lambda-development) & [Resource Binding](https://docs.sst.dev/resource-binding). And due to the CDK & CFN deployment model we cannot do Resource Binding well. - -### 2. Cyclical Dependencies - -There's another similar problem that's turning into a deal-breaker for our users. Recall that CDK isn't truly IaC, it's a JSON generator. This means that it'll generate JSON CloudFormation templates that won't work. A very common failure case is where some resources depend on each other. These are called cyclical dependencies. They come in two flavours. - -#### Type 1: Resources - -Similar to the example we used above, let's say you create a Lambda function with a function URL and you create a CloudFront distribution that points to the function's URL. And you want the function to have an environment variable with the CloudFront distribution URL. - -```ts -const fn = new Function(); -const dist = new CloudFront({ - route: { - "/my-function": fn.url, - }, -}); - -// You cannot do this -fn.addEnvironment({ - key: "endpoint", - value: dist.url, -}); -``` - -This looks perfectly fine in CDK code but cannot be expressed in a JSON CloudFormation template. This is because the three resources now reference one another. It's a cyclical dependency. - -Unfortunately this comes up in our support pretty often. A *solution* for this is telling people to configure a custom domain so they know the URL before it's deployed. Or storing the distribution URL somewhere that can be later fetched inside the Lambda function. We have ways to make this easier but it requires *top level await* and that doesn't work in many environments and frameworks. - -#### Type 2: Stacks - -There's another version of this that's even more confusing. Let's say we are creating a queue and a function. The function needs to know the queue URL and the queue has a consumer that needs to know the function URL. - -```ts -const q = new SQS(); -const fn = new Function({ - environment: { - q: q.url, - } -}); - -q.consumer = new Function({ - environment: { - fn: fn.url, - } -}); -``` - -This isn't a cyclical dependency. The reasoning is subtle but related to the underlying resources that are being created. It looks the same as the one above in terms of CDK code but it's not the same when written in CloudFormation. - -CloudFormation stacks have resource limits. Meaning that if you have more than 500 resources in a stack, you need to move them out to a new stack. This happens with larger teams. They'll need to refactor their stacks often. - -Say you split this into two stacks. One for the functions: - -```ts -function FnStack() { - const fn = new Function(); - - return fn; -} -``` - -And one for the queues: - -```ts -function QStack() { - const fn = use(FnStack); - - const q = new SQS(); - q.consumer = new Function({ - environment: { - fn: fn.url, - } - }); - - fn.addEnvironment({ - q: q.url, - }); - - return q; -} -``` - -When you deploy an app with these two stacks, you'll get a different cyclical dependency error. Here CloudFormation cannot deploy this because these stacks depend on each other. - -A fix for this is to refactor it in a way that the queue stack can be deployed first. - -```ts -function QStack() { - const q = new SQS(); - - return q; -} -``` - -And then deploy the function stack. - -```ts -function FnStack() { - const q = use(QStack); - - const fn = new Function({ - environment: { - q: q.url, - }, - }); - - q.consumer = new Function({ - environment: { - fn: fn.url, - } - }); - - return fn; -} -``` - -Try and look at these two cases again. They look basically the same, yet one works and the other doesn't. - -The reason for this is subtle. The `addEnvironment` call in the first case *modifies* an existing resource definition. While the `q.consumer` call *adds* a new resource definition. Something that's non-obvious from looking at the code. - -> CDK is leaking implementation details from CloudFormation. - -The core problem is that CDK is leaking an implementation detail from CloudFormation. A sign that the system is poorly designed. - -### 3. Export in Use - -Like the cyclical dependency issue `Export in use` is another dreaded error. It usually looks like this. - -```txt -Export stackA:ExportsOutput****** cannot be deleted as it is in use by stackB -``` - -Let's say there is a Bucket in the `stackA`, and `stackB` references its `bucket.bucketName`. You now want to remove the bucket. But if you do, you'll run into the error above. - -To fix this, you need to do two deploys. You'll need to create a *fake* export with `bucket.bucketName` in `stackA`, remove the reference in `stackB`, and deploy. Then remove the bucket and the fake export in `stackA` and deploy again. - -This happens when the references between the stacks in your CDK app change. CDK makes it really easy to share references between stacks in your app. It's a hack on top of CloudFormation that makes exports easier to use. CloudFormation also doesn't have a concept of an *app*. So it doesn't know this export has been removed in a stack that is about to be deployed. - -This error happens frequently and is incredibly non-obvious to people that are new to CDK. We realized that it's almost impossible to explain this through our docs or through support. So we built a feature in SST to auto-detect this and add the *fake* export for you. - -> CDK creates a hack on top of CloudFormation to make it easier to use. SST then adds a hack to unwind the damage caused by that hack to make CDK easier to use. - -This specific error and its subsequent handling is a microcosm of the problem with the entire model. CDK creates a hack on top of CloudFormation to make it easier to use. SST then adds a hack to unwind the damage caused by that hack to make CDK easier to use. - -### 4. Swallowing Errors - -A consequence of CloudFormation being a black box is that it handles any errors internally. So you'll see the error from CloudFormation as opposed to the underlying error with the resource. This is the reason why many AWS deployment errors are cryptic and vague. - -Here's an example. - -```txt -Error Message: 18:59:16 UTC-0500 CREATE_FAILED AWS::Route53::RecordSetGroup DatabaseDNSRecord Invalid request -``` - -What's happening here is that there was an error within CloudFormation while creating the resource. But it swallows the real error and instead gives you the generic `Invalid request` error. - -> As a framework author, it's these types of things that drive you crazy. - -The *workaround* for this is to look at AWS CloudTrail, their audit log service. It'll show you the original event and error message. As a framework author, it's these types of things that drive you crazy. - -### 5. Custom Resource Hacks - -So we know that CDK translates to CloudFormation that then gets executed. But what if you wanted some custom logic. For example, you have an S3 bucket that your users use for file uploads and you want to remove all the files in it when you remove your app. - -You might think you can just write some CDK code that does this. But you cannot do this natively because it cannot be expressed as a CloudFormation JSON template. To fix this there's an escape hatch called a Custom Resource. It's a Lambda function that can execute as a part of the deployment process. - -The reason it needs to be a Lambda function is because CloudFormation is a black box and it cannot run any local code. You'll need to package it up as a Lambda function. - -Still, this sounds passable. Just run some extra scripts as a workaround. In practice though, Custom resources have their own set of problems; they are slow, have side effects, and when they fail it can be crippling. Unfortunately, the CDK community (and us included) need to rely on this for basically anything that isn't supported. - -#### Hacking Multi-Region - -Custom Resources get used for something seemingly trivial like emptying a bucket to something as crazy as multi-region deployments. CDK *supports* multi-region deployments. But it does this via a Custom Resource. The problem is that CloudFormation is a single-region service. There's no way to link stacks across regions. So when you deploy stacks across regions you'll rely on Custom Resources to share references across them. - -You can see the design flaw with the CDK & CFN model here. CloudFormation is a black box and CDK has to create these hacks to work around it. - -#### Orphan Log Groups - -The Lambda functions in Custom Resources create Log Groups in CloudWatch that they write to. When you remove your app, you want to remove these Log Groups, but you can't completely remove them. If your Custom Resource tries to remove its Log Group, it'll recreate it after it finishes running. There's a similar issue with setting the log retention for Lambda functions. - -> Custom Resources are trying to create another deployment model on top of CloudFormation. - -There are other problems with Custom Resources but the core issue is that these are hacking together another deployment model on top of CloudFormation. That's a huge red flag. - -### 6. Rollback Hell - -CloudFormation can sometimes run into issues when deploying a stack. When it does, it'll rollback all the changes it makes. This sounds good but it has two problems: - -1. It's really slow. CloudFormation deployments in general take very long and when they try to roll back, they take even longer. -2. Rollbacks can fail and get stuck because some resources might fail to rollback. If this happens you are in *rollback hell*. You won't be able to redeploy the stack. You'll need to go to the AWS Console and try to redo the rollback. If it still fails, you'll need to specifically pick the resources that are failing to rollback and tell it not to rollback. - -This is a pretty serious problem and we've gotten plenty of panicked support messages from teams that get stuck in this when they are deploying a big update to prod. People complained about this enough that CloudFormation added a setting to skip rollbacks in the case of failures. - -However, we tried this as a default with SST and immediately we had a bunch of users get into states that they couldn't get out of. We were forced to revert the change. - -Fun fact, if a Custom Resource has some faulty code you are guaranteed to be stuck in *rollback hell*. This is because on deploy, the faulty resource will fail, then it'll try to rollback the stack, and the faulty resource will run again and fail again. - -### 7. Double Builds - -CDK will sometimes do a lookup for a resource and save that information in a `cdk.context.json`. This file is meant to be committed and acts as a cache. If the cache doesn't exist, it'll build your app to create that cache, then build again while using the cached values. You need to commit this file to your Git repo. - -However, if your deploys to prod are run in a CI environment and prod happens to be a separate AWS account, it'll always do a double build. As a developer on the team, you might not have access to prod from your local machine, meaning that you can't generate this file locally and commit it. Or commit the changes when it needs to be updated. - -> CDK tries to maintain its own state on top of CloudFormation. - -This again stems from the design flaws of the system. CloudFormation maintains state internally for your deployed resources. But since it's a black box, CDK tries to maintain its own state on top of it. - -### 8. Stack Resource Limits - -As mentioned above, there's a resource limit of 500 for each CloudFormation stack. Say you have a Next.js site and a DynamoDB table, you might think that's 2 resources. But resources are counted in terms of the low level infrastructure that AWS needs to create these. The Next.js site creates around 68 resources. So you end up hitting this pretty quickly. - -Once you hit this limit, you'll need to split resources into multiple stacks. But that process is not intuitive. You'll likely run into the cyclical dependency issue that we mentioned above. - -### 9. Orphan Stacks - -When you are trying to refactor your stacks, you'll be tempted to rename a stack. If you do that, CDK will just recreate all the resources in that stack with new names. And the old stack and its resources will be orphaned. - -People run into this *gotcha* all the time. The right approach here is to delete the old stack and create a new one. But what if you have resources that cannot be removed; like your database. Well you can't change the stack name. You'll need to tell CDK not to generate a new stack name and continue to use the old stack name. Your infrastructure definition will now forever have this line in it. - -Unless you reimport the resources into your new stack, which is not easy as we'll see. - -### 10. Importing Resources - -CloudFormation keeps state internally of the resources its managing in a stack. But because this is not available locally, it introduces some problems. The biggest one is importing resources. As in, adding a previously created resource to a CloudFormation stack. SST users try to do this frequently because they need to link to previously created resources in their app. - -In theory an import should be simple. Just tell CloudFormation about a new resource and it'll manage it moving forward. In practice though it's extremely painful. You need to mock the resource in your current app, generate the CloudFormation template for your app, remove any extra info from the template, go to the CloudFormation console and ask it to import resources, set a unique ID for the resource, run a diff to see if your local stack is similar to the version that CloudFormation has, and finally do a drift check to make sure they are in sync. - -In short, most people don't do this. This hurts SST as a framework, as it limits how effective it can be for an existing AWS user. - -### 11. Slowness - -I won't spend too much time here but for a myriad of reasons CDK and CloudFormation are extremely slow. There is slow, as-in something is noticeably slow. And then there is *CloudFormation slow*. It's behaviour altering. This was maybe acceptable for a world where you bring up servers and clusters, those are expected to be slow. But if you are dealing with managed services, it really shouldn't be this slow. - -> There is slow, as-in something is noticeably slow. And then there is "CloudFormation slow". - -What's frustrating to us as framework authors is that we have no control over this. CloudFormation arbitrarily waits for resources to get updated because they optimize for the lowest common denominator use case. Imagine migrating from something like Vercel and waiting for 30 minutes for your first SST deployment. - ---- - -# Why The Change - -We've looked at all the problems that we are facing with the current CDK & CFN model. But these are not new issues. So why did we decide to make a change now? - -#### Background - -Before we get into that, let me give you some background. We've worked on SST for 3 years now. You may also know us as the creators of [Seed](https://seed.run) — a *git push to deploy* service for serverless apps. We started Seed in 2017. Prior to it supporting SST, Seed was exclusively for [Serverless Framework](https://www.serverless.com) apps. We've seen the ups and downs of Serverless Framework and their misstep with the [Serverless Components](https://github.com/serverless/components) idea. - -If you are not familiar with that story, I'll give you the gist of it. Serverless Framework uses CloudFormation to deploy your serverless apps. At some point they decided to launch their own infrastructure deployment service, called Serverless Components. It was not based on CloudFormation or Terraform. It would run deployments through their servers (though there was a way to opt out of that). Long story short, it did not work. - -At this point you are probably wondering if we are just repeating that mistake. Having lived through that it took us a really long time to consider options outside CDK. The problems listed above, are not new, we've known them for the better part of 2 years. We've also played around with Terraform versions of SST in the past. - -There's also… - -#### Supporting Non-AWS Providers - -Back in 2017, AWS had a complete stranglehold on the serverless space. And rightfully so. Today in 2024, that is less true. Other providers now have services that are better than the AWS versions. Most notably Cloudflare. Slowly but steadily they've gotten better. To the point that there is now genuine demand from the SST community wanting to use Cloudflare. We are also seeing companies that are using serverless to build their applications and they are completely not on AWS. - -To do this with the current CDK & CFN model we'd have to create Custom Resources for these providers. And as we have seen above, the Custom Resource hack is not worth it. That effectively means we'd have to go outside this model. - -We've known in the back of our minds that at some point we were going to have to do this. However this was going to be such a big change that we basically avoided thinking about it too hard. - -#### What Changed - -Then something shifted over the last year, we launched [OpenNext](https://open-next.js.org). Suddenly SST became the best way to deploy not just Next.js, but Remix, Astro, SvelteKit, and more to your AWS account. - -Now some of the largest Next.js sites in the world are deployed through SST. The resource linking problem that we described up top went from a fringe concern to something that I personally have to deal with in support every single week. - -Added to that we had to ask ourselves, if we weren't limited to the CDK & CFN model could we potentially build a better Next.js experience than Vercel. And we realized that we could. Vercel has to run some complicated infrastructure to support their multi-tenant use case. SST doesn't. Next.js apps deployed with SST are not just cheaper (Vercel's enterprise pricing is absurd) but also faster. - -#### Working With Pulumi - -Also this happened. - -[SST Pulumi tweet](https://twitter.com/funcOfJoe/status/1690115160877535232) - -We decided to build a prototype a couple of months ago. We worked with the Pulumi team and founders closely to understand how their system works. We figured out how we could create a fully open source deployment experience with the Pulumi deployment engine and their bridged Terraform providers. - -You simply install the SST CLI globally, create an `sst.config.ts`, and run `sst deploy`. There's nothing else to install, there are no `node_modules`, no CDK version conflicts, no services to sign up for, and no black boxes. Everything runs on your local machine. - ---- - -# How Does Ion Work - -In Ion you define your infrastructure almost exactly like you do in SST today. Except instead of using CDK underneath it uses a TS version of the underlying Terraform provider. Note that Terraform providers are written in Go and are basically calls to the AWS SDK. There's some additional code to make sure these run safely, so you aren't hammering AWS. - -When you run `sst deploy`, those resources make a call to an embedded Pulumi engine that makes a call to their bridged Terraform provider, and this makes the AWS SDK calls to create your resources. A _bridged Terraform provider_ is a Pulumi provider that's programmatically bridged to the underlying Terraform Go provider. - -If you are familiar with Terraform you might be wondering, isn't Terraform like CloudFormation templates in that you write JSON or HCL. When you deploy these templates through the Terraform engine, it translates these to calls to the Terraform Go providers for those resources. In Ion's case we don't use the Terraform engine, we use Pulumi. - -> You don't need to install Pulumi or Terraform or sign up for anything. - -You don't need to install Pulumi or sign up for it, their engine is embedded in the Ion CLI. Your deployments create a state file locally that are synced with an S3 bucket in your AWS account. - -There are a couple of key things with this model that pretty much addresses all the above issues. - -1. The code is executed exactly how you write it. The deployment engine is run from your local machine and it creates the resources directly. There is no layer or service in between. -2. This simple execution order means there are no cyclical dependencies. If you have a linked resource, you need to create it in the order it is used. -3. If you want to do something like the CloudFront and Lambda function example, where you want to set the distribution URL back into the function environment, you'll need to create a *dynamic provider*, this is basically code that's going to run locally after those resources have both been created. Again, the code you write is what's being executed and deployed. It's Infrastructure as Code. -4. Any deployment errors are displayed directly and in full. -5. Importing resources is a lot easier because you have visibility and control over the state of your deployment. - -> The code you write is what's being executed and deployed. It's Infrastructure as Code. - -This model isn't all perfect. Over the last couple of months we've had to work around some issues. But we have a couple of key tools at our disposal. - -1. We can submit PRs to Terraform providers, since these are open source. -2. There is a process of patching Terraform providers if the changes in the PR are urgent. -3. We can also fork the provider if necessary and create our own. -4. We talk to the Pulumi team regularly and can work with them to find fixes or work arounds. - -The upshot is that we are not dealing with the CloudFormation black box. So we can ultimately do something about the problems we run into. - ---- - -# Roadmap - -Let's look at where we are currently and what we've done for Ion so far. - -#### Step 0: Ion Prototype Demo - -Status: *Complete* - -- Created a prototype by embedding the Pulumi engine -- Created a repo for Ion on [GitHub](https://github.com/sst/ion) -- Implemented the most complicated SST construct in Ion — Next.js -- Implemented a few other components, including a new Vector component based on Amazon Bedrock -- Built a complete full-stack demo application with Ion — [movies.sst.dev](https://movies.sst.dev) - -You can view the repo for our demo movies app on [GitHub](https://github.com/sst/demo-ai-app). The entire SST team worked on this app and it was great watching all the CDK issues we listed basically vanish. - -#### Step 1: Ion General Release - -Timeline: *Couple of weeks from now* - -Here's what we need to do next for a general release. - -- Implement a few more components and CLI features -- Write up the docs -- Do a lot of testing -- Launch a new site — `ion.sst.dev` - -At this point you'll be able to create new apps from scratch in Ion. It'll give you a chance to try it out. We'll be directing new users that want to get started with SST to start with Ion first. - -#### Step 2: Ion → SST v3 - -Timeline: *Couple of months from now* - -Once Ion is stable, it'll give current SST users an opportunity to migrate their apps to Ion. We'll create some tools and documentation that'll help with this process. - -Once we feel comfortable with it and we know many people will be able to move over, we'll set a date for the SST v3 release. This is when `ion.sst.dev` will become `sst.dev` and it'll become SST v3. While SST v2's docs will be moved to a separate site. - ---- - -# What About SST v2 - -So what happens to SST v2 once Ion becomes SST v3? Here's what we are planning: - -- We'll release updates -- We'll accept PRs -- We won't add new constructs -- We won't introduce breaking changes - -There might be caveats here of course but we are planning to let the community drive a lot of what happens with SST v2. - ---- - -# What About Migrating - -Ion is obviously a big change. If you are using mostly SST constructs in your apps, the migration won't be a big problem. - -But what if you are using a ton of CDK constructs currently in your SST apps? There are two types of these: - -1. L1s or low level CDK constructs - - This is far easier to move over because the Terraform AWS providers have support for these. - -2. High level CDK constructs - - But CDK is filled with a ton of high level constructs, especially ones that use the Custom Resource hack described above to make changes that are not in CloudFormation (and also not in Terraform). - -The latter tends to be really messy. There is no way to sugar coat this. Migrating those over is not going to be easy. We'd argue that the new Ion model is better but there are no drop-in replacements for those. You could leave your old SST app around with those resources and not move them over. They'll continue to work because SST v2 isn't going anywhere. - -We'll share more details on the migrations steps through the Ion docs. But in the long run you might have to make a choice. - -#### Is Ion Right For Me - -That brings me to something we should address directly. If your company is completely invested in the CDK & CFN model and you were using SST because of its strong ties to CDK; Ion is probably not going to be right for you. We'd still invite you to give it a try and build something non-trivial with it. But we know some folks are married to CDK. - -In this case, the solution would be to migrate your SST apps to CDK when you can. At the end of the day, SST v2 is open source and built on CDK. We chose this architecture because we did not want you to be locked in to us in case something happened. - -#### What Ion Is Not - -It's also worth mentioning what we are not trying to be. We are not trying to be an extension of CDK or Terraform or Pulumi. We are not AWS purists. - -So if you are choosing SST or Ion because it's basically CDK or Terraform but *nicer*, you might end up disappointed. SST is fundamentally trying to create something that didn't exist before. We've discovered many of our design patterns as a result of our personal experience with building products and working with teams that are doing the same. - ---- - -# What's Our Goal - -So then what is our goal? Why are we doing all of this? - -We want SST to be the best way to deploy an application. Let's take an example. This `sst.config.ts` is based on the movies demo from above. It includes AWS, OpenAI, and Cloudflare as components. - -```ts -const db = new aws.dynamodb.Table("Movies"); - -const bucket = new sst.Bucket("Assets"); - -const vector = new sst.Vector("Vector", { - openAiApiKey: new sst.Secret("OpenAiApiKey").value, -}); - -const site = new sst.Nextjs("Web", { - link: [db, bucket, vector], -}); - -new cloudflare.cdn("Cdn", { - domain: "movies.sst.dev", - route: { - "/": site.url, - }, -}); -``` - -We want you to be able to drop a single type-safe config file in your repo root, and run `sst deploy`. This should be able to create any kind of resource, in any cloud provider, and link them all together. We also want you to be able to customize any of this to the degree that the provider will let you. - -> Drop a type-safe config file and deploy it with a single command. - -We want the best possible developer experience for this idea. And to accomplish it we need to bet on tools that we think will get us there. - ---- - -# FAQ - -I'm sure you have a lot of questions. I'm going to try and add to this section as I address more of them. - -#### 1. Is Ion completely open source and self hosted? - -Yes it's open source and it'll run on your local machine without you having to sign up for anything Pulumi or Terraform related. - -#### 2. Our company only uses AWS, can we still use Ion? - -Yes. While Ion will support multiple providers, if you are using AWS it will deploy completely to your AWS account. There won't be any other services or providers involved outside of the one you choose. - -#### 3. Isn't Terraform not open source anymore? - -There's been some recent fallout from the Terraform licensing change but that applies to the Terraform engine itself. Ion doesn't use this. - -#### 4. What happens to the SST Console? - -It'll support Ion and SST v2 apps. We have some plans for making it easy to self-host the Console. We'll share more details once we launch Ion. diff --git a/_sass/theme/_layout.scss b/_sass/theme/_layout.scss index e273cb31c..46556e4cd 100644 --- a/_sass/theme/_layout.scss +++ b/_sass/theme/_layout.scss @@ -248,6 +248,12 @@ margin-top: calc($spacing-unit / 2 + 5px); } + @include media-query($on-palm) { + &:after { + margin-top: calc($spacing-unit / 2); + } + } + @include media-query($on-laptop) { padding: calc($spacing-unit / 2) calc($spacing-unit / 2) 0; } @@ -342,6 +348,12 @@ } } } + + @include media-query($on-palm) { + .col1 { + margin-bottom: 0; + } + } } } @@ -527,7 +539,7 @@ .site-author { margin: 0; - text-align: center; + text-align: right; font-size: 16px; color: $tertiary-text-color; @@ -535,6 +547,11 @@ @extend %a-tertiary; } } + @include media-query($on-laptop) { + .site-author { + text-align: center; + } + } } // //.footer-heading { @@ -558,7 +575,7 @@ } .footer-col { - margin-bottom: 2 * $spacing-unit - 5px; + /* margin-bottom: 2 * $spacing-unit - 5px; */ margin-right: 1.5 * $spacing-unit; @include media-query($on-laptop) { @@ -568,60 +585,63 @@ &.footer-col-1 { text-align: left; flex: 1 0 auto; + display: flex; + align-items: center; @include media-query($on-laptop) { + display: block; text-align: center; } } - &.footer-col-2 { - flex: 1 0 auto; - display: flex; - flex-wrap: wrap; - - @include media-query($on-laptop) { - margin-bottom: $spacing-unit; - justify-content: center; - } - - & > ul { - @include media-query($on-laptop) { - margin-left: 0; - } - } - - & > ul:not(:last-child) { - margin-right: 2 * $spacing-unit; + /* &.footer-col-2 { */ + /* flex: 1 0 auto; */ + /* display: flex; */ + /* flex-wrap: wrap; */ + /**/ + /* @include media-query($on-laptop) { */ + /* margin-bottom: $spacing-unit; */ + /* justify-content: center; */ + /* } */ + /**/ + /* & > ul { */ + /* @include media-query($on-laptop) { */ + /* margin-left: 0; */ + /* } */ + /* } */ + /**/ + /* & > ul:not(:last-child) { */ + /* margin-right: 2 * $spacing-unit; */ + /**/ + /* @include media-query($on-laptop) { */ + /* margin-right: 1.5 * $spacing-unit; */ + /* } */ + /* @include media-query($on-palm) { */ + /* margin-right: $spacing-unit; */ + /* } */ + /* } */ + /* } */ - @include media-query($on-laptop) { - margin-right: 1.5 * $spacing-unit; - } - @include media-query($on-palm) { - margin-right: $spacing-unit; - } - } - } - - &.footer-col-3 { - margin-bottom: $spacing-unit; + &.footer-col-2 { + /* margin-bottom: $spacing-unit; */ margin-right: 0; flex: 0 1 auto; max-width: 450px; } - a.author-link { - @extend %a-tertiary; - font-weight: bold; - } - - a.email-link, - a.page-link { - font-weight: 400; - line-height: 2; - } + /* a.author-link { */ + /* @extend %a-tertiary; */ + /* font-weight: bold; */ + /* } */ + /**/ + /* a.email-link, */ + /* a.page-link { */ + /* font-weight: 400; */ + /* line-height: 2; */ + /* } */ .social-links { - margin-top: $spacing-unit; + margin-bottom: 7px; @extend %social-buttons; @include media-query($on-laptop) { @@ -940,6 +960,8 @@ } .post-archives { margin-top: 20px; + border-top: 1px solid $grey-color-light; + padding-top: $spacing-unit * 0.5; color: $text-color; font-weight: 600; font-style: italic; diff --git a/about/culture.md b/about/culture.md deleted file mode 100644 index 059a67c6f..000000000 --- a/about/culture.md +++ /dev/null @@ -1,221 +0,0 @@ ---- -layout: page -title: How We Work -editable: true -description: This document is meant to be used as a user manual for SST team. In it we go over our cultural values and how we operate as a team. ---- - -In this document we'll go over the cultural values that drive our team at SST. But before we get to these values, we want to go over a few things. We want to look at what we are building, why we are building it, and how we operate as a team. This'll give us a good sense of where our cultural values come from and why they matter to us. - -Here's what we'll be covering in this document. - -- [Background](#background) -- [Our vision](#our-vision) -- [How we build products](#how-we-build-products) -- [How we operate as a team](#how-we-operate-as-a-team) -- [Cultural values](#cultural-values) - -Let's get started! - -## About this document - -This document is meant to be used as a user manual for SST team. We think sharing it publicly serves two purposes: - -1. It helps the community get a better sense of how we operate. -2. And, it helps keep us accountable to the standards we set. - -This document is a work in progress. If you have feedback on what's covered here, or have suggestions on what we should add, please let us know. - -## Background - -### What is serverless - -Serverless is a new way of building applications. Developers use infrastructure-as-code to define and provision fully-managed services. Resources are provisioned programmatically and the pricing is completely usage based. - -> Serverless is a perfect fit for startups. - -Since the infrastructure is fully-managed and completely programmable, a single developer should be able to build an application that scales to millions of users with no operational overhead. - -It's a perfect fit for a startup. - -### Problems with serverless - -However, there are few different problems with adopting serverless. Let’s just focus on the two biggest issues for now: - -1. It's extremely complicated to configure. This follows from the fact that a serverless application is a combination of at least a handful of fully-managed services. Each service has a large number of configurable options. -2. The development feedback loop is broken. Since these applications are completely based in the cloud. Testing them requires you to either mock these services locally or redeploy them to test. - -## Our vision - -We think every startup should be built using serverless and we want to create a platform that makes this possible. They should be able to get started by using our platform. And continue to use it as their application and company grows. In a sense, they should be able to use our platform to go from _idea to IPO_. - -> Build a platform that a startup can use to go from idea to IPO. - -This means that our platform needs to be both: - -1. Easy to get started, by abstracting out the complexity of the underlying services. -2. And completely configurable, allowing you to use the full power of the underlying cloud services. - -## How we build products - -Building a platform that's both easy to get started and completely configurable is a challenge. There are a broad number of use cases and each use case needs to be configurable. In a sense, the problem space is both wide and deep. - -Problems like these are a good fit for open source. Users of open source projects tend to naturally extend the use cases of the project. This is observed in the long-tail of use cases that an open source project addresses. Especially in comparison to its closed source counterparts. - -Users of open source software are also far more willing to provide feedback, when compared to closed source software. Whether it is sharing key information about their problems or even collaborating to solve it. We noticed that the sense of altruism amongst open source users leads to a much higher bandwidth of feedback. - -> The sense of altruism amongst open source users leads to a much higher bandwidth of feedback. - -The two above ideas together create a virtuous cycle that effectively describes how we build our products. - -1. Open source users extend our products to other use cases. -2. They run into some problems with them. -3. They provide us with detailed feedback, as only open source users can. -4. This feedback allows us to do a good job while addressing their issue. -5. This leads to our users being excited to try it for additional use cases. -6. And the cycle continues. - -This virtuous cycle lets us traverse the problem space while prioritizing our user's needs. It also presents us with natural growth opportunities for the business. - -Let’s look at what this means practically. Starting with how we implement feature requests. - -### How we implement features - -Here’s a rough step-by-step process that we try to follow. - -Let’s assume we get a message on Discord or somebody opens an issue on GitHub. - -1. Start by understanding what the user is trying to do. - - If it’s a bug, understand what's causing it. We don't need to have a solution, but we need to get all the information required to debug the issue. It's harder to get the user to send you debug information after they’ve moved on. - - If it is a feature request, understand what the user is trying to achieve. Listen to their problems, not their solutions. -2. Then we create a GitHub issue with: - - Everything that was talked about - - List of all the places that it’s been brought up in - - List of all the people that’ve brought it up - - If the issue has been brought up before, add the new person to the list -3. After we understand the problem, figure out if it’s straightforward to implement or if we need to design a solution. - - A straightforward solution usually includes bug fixes or features that don’t change the overall design of the product. - - On the other hand, if the solution isn’t obvious or is a bigger change, we need to make some design decisions (more on this below). For design decisions, get the team involved. - - Before the group discussion, come up with a proposed solution. - - If the issue is urgent, don't hesitate to get somebody’s time. The leadership team needs to be on-call for urgent issues. - - If the issue is not urgent, you can book a time on somebody's calendar. Or bring it up in the 1 on 1. -4. We then propose the solution to the user. Preferably with code snippets, and ask the user if it solves their issue. -5. Update the GitHub issue with the proposed solution. For something that's really simple to implement, we can skip this step. -6. We figure out the priority for this issue and when we are going to work on it. More on this below. -7. If you are working on it right now, tell the people that reported the issue. They are likely to help if you need some additional feedback. -8. Implement the solution in a PR. You can read more about PRs and cutting releases in our [CONTRIBUTING.md]({{ site.sst_github_repo }}/blob/master/CONTRIBUTING.md). -9. If the new feature has a new name or it's a new option, review the naming with the team. -10. Write a doc for it and add it to the PR. It doesn’t have to be perfect but it needs to be functional. The copy will be reviewed later but the content needs to be figured out upfront. -11. Cut a release. In the release notes mention how to use the feature. -12. Tell everybody that requested it about the release. Mention the version number, so they can upgrade to it. -13. Announce the release in Discord, with a snippet on how to use the feature. -14. Make a list of all the copy and docs changes that need to be reviewed, create an issue and send it to the team. - -The key here is that it’s easier to gather the requirements and understand the problem when it’s first reported. Even if we don’t end up implementing the fix right away, users are far more engaged when the issue is first reported. We want to figure out a solution and get it validated by our users as early as possible. And document everything in a GitHub issue. - -> We want to figure out a solution and get it validated by our users as early as possible. - -We also want to notify users when we release a fix. It shows them that we personally care. And it makes it more likely that they'll give us feedback in the future. - -### How we prioritize what to work on - -We have a rough flowchart that we use to prioritize features. This will evolve as the priorities of the team changes. - -Is there a user blocked by the issue or feature request? - -- Yes ⇒ Fix it now -- No ⇒ Is the issue related to a new user's experience? - - Yes ⇒ Fix it now - - No ⇒ Is it a quick change (will take less than 30mins to implement)? - - Yes ⇒ Mark it as High priority - - No ⇒ Has it been brought up before? - - Yes ⇒ Mark it as High priority (bumped up from Low) - - No ⇒ Mark it as Low priority - -So the priorities look like: "Fix it now", "High", or "Low". The "Fix it now" ones are the urgent issues that we work on right away. While the "High" priority ones are the issues that we are currently working on (when there's nothing urgent). The "Low" priority ones don't get worked on until we've run out of the "High" priority issues. Or they get bumped in priority. - -For the "Fix it now" and "High" priority issues, we tell the user the timeline for the fix (today or tomorrow vs this week or next week). On the other hand, for low priority issues we tell them we won’t get to it right away. But ask them to let us know if it becomes a blocker and we’ll bump it up in priority. - -While the above flow can seem a bit rigid, there are a couple of caveats. For example, we might prioritize a feature differently: - -- If it's being requested by a valued member of our community -- If a person that's trying to contribute to the project needs it -- If you think we can solve it in a novel way and it can have a big impact - -Feel free to pull the leadership team in, if you need any help. We hope that over time you are able to build a better sense of how to prioritize features. - -### Our design process - -As mentioned above, there are some issues that are not straightforward to implement. They require a certain amount of design. These are typically issues that have multiple solutions and it's not immediately clear which approach makes sense. It's important that we have cohesively designed products that work well together. We also care about making our products intuitive to use. This means that for some issues we need to put a lot more thought while designing a solution. We employ a "design" meeting to work through this. It usually involves: - -1. Understanding the root cause of the problem we are trying to solve. -2. Looking at the prior art in the field and understanding their pros and cons. -3. Weighing the different approaches we can take to solve the problem. - - This involves putting together pseudo code or demos for the team to evaluate. - - It's much easier to evaluate possible options based on something real. -4. Making sure that the proposed solution works with the design choices made across our other products. - -It's important that we work through this process on our own, before a design meeting. The rest of the leadership team is there to help you make a decision. And it allows you to get better at making these decisions. - -> It's important to work through the design process on your own, before meeting with the team. - -It should also be mentioned that it's the responsibility of the leadership team to not make these meetings a blocker. If a feature needs to be implemented urgently, they are on-call for these meetings. - -### Naming things - -We also like to take care while naming features, config options, props, etc. For anything new: - -1. Suggest what you'd like to name it and why. -2. Offer two other suggestions and what you like about them. -3. Post this in the team channel. The rest of the team will quickly vote on them or add their own suggestions. - -Coming up with a good name can sometimes be hard. But it's worth thinking it through, especially for things that can be hard to rename later. - -## How we operate as a team - -The above should give you some sense of how we operate internally as a team. But let's look at it in a little more detail. We’ll look at it from the perspective of an engineer that’s building our products. - -The process of talking to users and building products is the core engine that drives our team. This implies a couple of things: - -- We want the entire product process to be run independently by our engineers. -- This includes talking to users, gathering requirements, proposing solutions, implementing them, releasing them, and notifying our users. -- We want to reduce the number of people an engineer needs to talk to internally to get something done. -- For the cases where we need the leadership team’s input on design, we want to ensure that the leadership team is always available to provide feedback. -- We also want each engineer to have ownership of specific parts of the product and manage the roadmap for it. -- Keep track of the key input and output metrics of the product to drive its growth. - -The role of the leadership team is to give an engineer as much autonomy as possible and to make sure the product process is running smoothly. - -## Cultural values - -All of this leads us to our core tenets, our cultural values. - -### Having a services mindset - -We need to remind ourselves that our users are using our products to get their jobs done. While they need help with our products, it’s because there is a bigger purpose to what they are doing. So our mindset while interacting with our users should be helping them get to where they want to go. - -There's an unhealthy power dynamic in large communities between the "in" crowd and the new folks. We need to avoid this by having a high degree of empathy. No issue is too small or too trivial or too dumb. It’s our job to make sure the user is able to do what they want to do through our products. - -### Thinking as a user and paying attention to the details - -While we are trying to help our users build their products we are not merely providing “support” or “services”. We are trying to figure out how our products can do a better job for them. We need to pay attention to the details of their experience. This doesn’t always mean making big changes to our products. It could be something as simple as clarifying some small details in our docs. We need to think as a user and use their feedback to improve the product. - -As a team, we rely heavily on our users to guide our product roadmap. So it’s important that as engineers we spend time thinking about all the little details of their experience. This information helps us make better product decisions. And ultimately lets us make something that people want. - -### Having good taste - -A lot of the key products and features that we work on, require us to make design decisions on behalf of our users. In an industry where most solutions are overly complicated, we need to be able to design intuitive products that are easy to use. It also matters that we use similar design principles across our products, so as to minimize the number of concepts a user has to learn. - -We need to have a high personal bar when it comes to design. Design in our case is about all the small decisions we make while creating our products. We need to weigh our options carefully and try to make the right tradeoffs. This also makes our users feel that there was a certain degree of care that was taken while building it. - -### Moving with urgency - -As noted in the product process above, it’s important that we respond in a timely manner and gather feedback quickly. It’s important to capture feedback before the user moves on. Similarly, it’s important to push out features right when they need them. - -Moving with a sense of urgency that’s driven by user feedback allows us to delight users, build community engagement, and foster a culture internally that’s exciting to be a part of. - -### Taking ownership - -We want our engineers to run the entire product process. We want them to take on a part of the product and drive the roadmap completely. We want them to select the KPIs, set the goals, and take part in our weekly and monthly reviews as a representative of that product. - -We think it's naturally motivating to be responsible for building something that solves a problem for somebody else. So we want to create an environment where it's possible to take ownership of that entire process. diff --git a/about/index.html b/about/index.html deleted file mode 100644 index 22e67c7b5..000000000 --- a/about/index.html +++ /dev/null @@ -1,214 +0,0 @@ ---- -layout: lander -title: About Us -description: SST is making it easy to build full-stack serverless applications. We've created an open source framework called SST, a guide for building serverless apps, and Seed; a service for teams to manage their serverless apps. ---- - -
- -
-
-

About SST

- - -
-

Founded with the sole purpose of making it easy to build serverless applications. We want to make sure you have everything you need to build great products.

-
- -
- -
-
- -
-

Guide

-

The SST Guide is the most widely read resource for building full-stack serverless apps. Follow our step-by-step guide and build a React.js app with a serverless backend.

-
-
- -
-

SST

-

SST is an open source framework for building modern full-stack applications on AWS. Deploy Next.js, Remix, Astro sites and add any backend feature.

-
-
- -
-

Seed

-

Seed is the easiest way for teams to deploy and manage their serverless applications. It'll incrementally deploy your functions and send you real-time alerts when they fail.

-
-
- -
- -
-

Meet the Founders

-

Originally founded by Jay V and Frank Wang in San Francisco. We now run distributed teams across the globe. We've written about how we work. So if you are passionate about developer tools, we would love for you to join our team!

-
-
- - Jay's profile image - -
- - Jay V - -
-

Founder & CEO

-
- - - - - - - - - - - - - - - -
-
-
-
- - Frank's profile image - -
- - Frank Wang - -
-

Founder & CTO

-
- - - - - - - - - - - - - - - -
-
- - -
-
- -
-
-

Our Investors

- -
-

We are lucky to have some of the greatest investors of Silicon Valley on our side.

-
- - - -
-
- -
-
- -
-

Our Community

-

A huge thanks to all our contributors and community members.

- -
- -
-
-

Brand Guidelines

-

{{ site.email }}

-

Media Kit

- - -
-
- -
diff --git a/assets/lander/logo/sst-guide.svg b/assets/lander/logo/sst-guide.svg new file mode 100644 index 000000000..48ad1a954 --- /dev/null +++ b/assets/lander/logo/sst-guide.svg @@ -0,0 +1,12 @@ + + + + + + + + + + + + diff --git a/blog/index.md b/blog/index.md deleted file mode 100644 index e8597bb3f..000000000 --- a/blog/index.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -layout: blog -title: Blog -description: Updates and announcements from the SST team. ---- - -{% include blog-posts.html posts=site.posts %} diff --git a/careers.html b/careers.html deleted file mode 100644 index f48c512d5..000000000 --- a/careers.html +++ /dev/null @@ -1,42 +0,0 @@ ---- -layout: default -title: Join our team -description: We want to build the future of serverless. If you are passionate about building developer tools, we'd like you to join us! ---- - -
- -
-

Join Our Team

-

We want to build the future of serverless and we could use your help! If you are passionate about building developer tools and love helping other developers, we'd like to meet you.

-

We've also written in detail about how we work.

-
- -
- - - -
- diff --git a/guide.md b/guide.md deleted file mode 100644 index 420d5cf20..000000000 --- a/guide.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -layout: default -title: SST Guide -description: Learn how to build full-stack apps using serverless and React on AWS. ---- - -
- -
-

Join readers from the biggest companies in the world

-

SST Guide

-

- The most widely read resource for building full-stack apps using serverless and React on AWS. -

-
- -
- {% include reader-logos.html %} -
- -
- -
- {% include toc-chapters.html items=site.data.chapterlist.preface id="preface" index="1" %} - - {% include toc-chapters.html items=site.data.chapterlist.intro id="intro" index="2" %} - - {% include toc-chapters.html items=site.data.chapterlist.setup-aws id="setup-aws" index="3" %} - {% include toc-chapters.html items=site.data.chapterlist.setup-sst id="setup-sst" index="4" %} - {% include toc-chapters.html items=site.data.chapterlist.setup-sst-backend id="setup-sst-backend" index="5" %} - {% include toc-chapters.html items=site.data.chapterlist.build-sst-api id="build-sst-api" index="6" %} - {% include toc-chapters.html items=site.data.chapterlist.add-auth-stack id="add-auth-stack" index="7" %} - {% include toc-chapters.html items=site.data.chapterlist.handling-secrets id="handling-secrets" index="8" %} - {% include toc-chapters.html items=site.data.chapterlist.unit-tests id="unit-tests" index="9" %} - {% include toc-chapters.html items=site.data.chapterlist.cors-sst id="cors-sst" index="10" %} - - {% include toc-chapters.html items=site.data.chapterlist.setup-react id="setup-react" index="11" %} - {% include toc-chapters.html items=site.data.chapterlist.react-routes id="react-routes" index="12" %} - {% include toc-chapters.html items=site.data.chapterlist.setup-amplify id="setup-amplify" index="13" %} - {% include toc-chapters.html items=site.data.chapterlist.build-react id="build-react" index="14" %} - {% include toc-chapters.html items=site.data.chapterlist.secure-pages id="secure-pages" index="15" %} - - {% include toc-chapters.html items=site.data.chapterlist.custom-domains id="custom-domains" index="16" %} - {% include toc-chapters.html items=site.data.chapterlist.automating-deployments id="automating-deployments" index="17" %} - - {% include toc-chapters.html items=site.data.chapterlist.conclusion id="conclusion" index="18" %} -
- -
- {% include standalone-newsletter-form.html %} -
- -
-

Archives

-

Older sections of the guide available for reference.

-
- -
- -
-
-
-

Best Practices

-
-
- {% include toc-chapters.html items=site.data.archiveslist.best-practices-intro id="best-practices-intro" %} - {% include toc-chapters.html items=site.data.archiveslist.organize-serverless-apps id="organize-serverless-apps" %} - {% include toc-chapters.html items=site.data.archiveslist.configure-environments id="configure-environments" %} - {% include toc-chapters.html items=site.data.archiveslist.development-lifecycle id="development-lifecycle" %} - {% include toc-chapters.html items=site.data.archiveslist.observability id="observability" %} - {% include toc-chapters.html items=site.data.archiveslist.best-practices-conclusion id="best-practices-conclusion" %} - Show all -
-
- -
-
-

Serverless Framework

-
-
- {% include toc-chapters.html items=site.data.archiveslist.setup-serverless id="setup-serverless" %} - {% include toc-chapters.html items=site.data.archiveslist.setup-backend id="setup-backend" %} - {% include toc-chapters.html items=site.data.archiveslist.build-api id="build-api" %} - {% include toc-chapters.html items=site.data.archiveslist.users-auth id="users-auth" %} - {% include toc-chapters.html items=site.data.archiveslist.third-party-apis id="third-party-apis" %} - {% include toc-chapters.html items=site.data.archiveslist.infrastructure-as-code id="infrastructure-as-code" %} - Show all -
-
-
- -
-
-
-

Extra Credit

-
-
- {% include toc-chapters.html items=site.data.archiveslist.extra-backend id="extra-backend" %} - {% include toc-chapters.html items=site.data.archiveslist.extra-auth id="extra-auth" %} - {% include toc-chapters.html items=site.data.archiveslist.extra-frontend id="extra-frontend" %} -
-
-
-
- -
-
diff --git a/index.md b/index.md index 35b094b6c..7e9dc926a 100644 --- a/index.md +++ b/index.md @@ -1,330 +1,25 @@ --- -layout: lander -description: "Build modern full-stack serverless applications on AWS with Next.js, SvelteKit, Remix, Astro, Solid, and more." +layout: default +title: SST Guide +description: Learn how to build full-stack apps using serverless and React on AWS. +redirect_from: /guide.html --- - - -
-
Loved by over 1,000 amazing teams
- -
- -
- -
-

Start with your favorite frontend

-
-

Use our open source framework to deploy your Next.js, Svelte, Remix, Astro, or Solid site.

- -
- -
- {% include lander-examples/frontend-list.html %} -
- -
-
- -
+
-

Add any backend feature

-
-

- Extend your app with our preconfigured backend components. Even use any AWS service. -

- -
- -
- -
- {% include lander-examples/database.html %} -
-
-
-
-
-
-
-

Database

-

Add a serverless SQL or NoSQL database to power your app.

-
-
- -
-
-
{% include svg/graphql.svg %}
-

GraphQL API

-

Add a dedicated serverless GraphQL or REST API to your app.

-
-
-
-
-
-
- {% include lander-examples/api.html %} -
- -
- {% include lander-examples/auth.html %} -
-
-
-
-
-
-
-

Auth

-

Authenticate your users through any auth provider.

-
-
- -
-
-
-

Cron jobs

-

Run cron jobs powered by serverless functions.

-
-
-
-
-
-
- {% include lander-examples/cron.html %} -
- -
- {% include lander-examples/all.html %} -
-
-
-
-
-
-
{% include svg/aws.svg %}
-

Any AWS service…

-

Go beyond our components and integrate with any AWS service!

-
-
- -
- -
- -
- -
-

Collaborate with your team

-
-

Create preview or feature environments. Or one for everyone on your team.

- -
- -
- -
- {% include lander-examples/deploy.html %} -
-
-
-
-
-

Environments from the CLI

-

Use the CLI to create and deploy to new environments.

-
-
- -
- {% include lander-examples/preview-deploys.html %} -
-
-
-
-
-

Automatic preview environments

-

Get preview environments for every PR or branch with SEED.

-
-
- -
- -
- -
- - Get Started - -
- -
-
-

Testimonials

-
-
- -
- - -
-
-
- -
-
-

Join our growing community

-
    -
  • -
    {{ site.stats.github_short}}+
    -

    GitHub stars

    -
    • -
  • -
    {{ site.stats.discord }}+
    -

    Discord members

    -
    • -
  • -
    {{ site.stats.newsletter_short }}+
    -

    Subscribers

    -
    • -
-
-
- -
-
+

Join readers from the biggest companies in the world

SST Guide

-

- The most widely read resource for building full-stack apps using serverless on AWS. -

+

{{ site.description_full }}

-
-
-

Download the FREE 300 page ebook

-

Join {{ site.stats.newsletter }} readers from the biggest companies in the world. We'll also send you updates when new versions are published.

-
-
- {% include email-octopus-form.html %} -
- - +
+ {% include reader-logos.html %}
-
- -
+
-
-
+
{% include toc-chapters.html items=site.data.chapterlist.preface id="preface" index="1" %} {% include toc-chapters.html items=site.data.chapterlist.intro id="intro" index="2" %} @@ -345,13 +40,67 @@ description: "Build modern full-stack serverless applications on AWS with Next.j {% include toc-chapters.html items=site.data.chapterlist.secure-pages id="secure-pages" index="15" %} {% include toc-chapters.html items=site.data.chapterlist.custom-domains id="custom-domains" index="16" %} - {% include toc-chapters.html items=site.data.chapterlist.automating-serverless-deployments id="automating-serverless-deployments" index="17" %} - {% include toc-chapters.html items=site.data.chapterlist.monitor-debug-errors id="monitor-debug-errors" index="18" %} + {% include toc-chapters.html items=site.data.chapterlist.automating-deployments id="automating-deployments" index="17" %} + + {% include toc-chapters.html items=site.data.chapterlist.conclusion id="conclusion" index="18" %} +
+ +
+ {% include standalone-newsletter-form.html %} +
+ +
+

Archives

+

Older sections of the guide available for reference.

+
+ +
+ +
+
+
+

Best Practices

+
+
+ {% include toc-chapters.html items=site.data.archiveslist.best-practices-intro id="best-practices-intro" %} + {% include toc-chapters.html items=site.data.archiveslist.organize-serverless-apps id="organize-serverless-apps" %} + {% include toc-chapters.html items=site.data.archiveslist.configure-environments id="configure-environments" %} + {% include toc-chapters.html items=site.data.archiveslist.development-lifecycle id="development-lifecycle" %} + {% include toc-chapters.html items=site.data.archiveslist.observability id="observability" %} + {% include toc-chapters.html items=site.data.archiveslist.best-practices-conclusion id="best-practices-conclusion" %} + Show all +
+
+ +
+
+

Serverless Framework

+
+
+ {% include toc-chapters.html items=site.data.archiveslist.setup-serverless id="setup-serverless" %} + {% include toc-chapters.html items=site.data.archiveslist.setup-backend id="setup-backend" %} + {% include toc-chapters.html items=site.data.archiveslist.build-api id="build-api" %} + {% include toc-chapters.html items=site.data.archiveslist.users-auth id="users-auth" %} + {% include toc-chapters.html items=site.data.archiveslist.third-party-apis id="third-party-apis" %} + {% include toc-chapters.html items=site.data.archiveslist.infrastructure-as-code id="infrastructure-as-code" %} + Show all +
+
+
- {% include toc-chapters.html items=site.data.chapterlist.conclusion id="conclusion" index="19" %} - Show all +
+
+
+

Extra Credit

+
+
+ {% include toc-chapters.html items=site.data.archiveslist.extra-backend id="extra-backend" %} + {% include toc-chapters.html items=site.data.archiveslist.extra-auth id="extra-auth" %} + {% include toc-chapters.html items=site.data.archiveslist.extra-frontend id="extra-frontend" %} +
+
+
-
From e287ec03f8a1a986d38aa01b60c8f4ca9dca5f11 Mon Sep 17 00:00:00 2001 From: Jay V Date: Fri, 16 Aug 2024 19:59:50 -0400 Subject: [PATCH 2/3] Updating domains --- sst.config.ts | 22 +++------------------- 1 file changed, 3 insertions(+), 19 deletions(-) diff --git a/sst.config.ts b/sst.config.ts index e83a068b9..e9d71c0dd 100644 --- a/sst.config.ts +++ b/sst.config.ts @@ -1,7 +1,5 @@ import { SSTConfig } from "sst"; import { StaticSite } from "sst/constructs"; -import { HostedZone } from "aws-cdk-lib/aws-route53"; -import { HttpsRedirect } from "aws-cdk-lib/aws-route53-patterns"; export default { config(_input) { @@ -15,32 +13,18 @@ export default { const site = new StaticSite(stack, "site", { customDomain: stack.stage === "prod" - ? { - domainName: "sst.dev", - domainAlias: "www.sst.dev", - } + ? "guide.sst.dev" : stack.stage.startsWith("branchv") - ? { + ? { hostedZone: "archives.sst.dev", domainName: `${stack.stage}.archives.sst.dev`, } - : undefined, + : undefined, errorPage: "404.html", buildOutput: "_site", buildCommand: "bundle install && bundle exec jekyll build", }); - // Redirect serverless-stack.com to sst.dev - if (stack.stage === "prod") { - new HttpsRedirect(stack, "Redirect", { - recordNames: ["serverless-stack.com", "www.serverless-stack.com"], - targetDomain: "sst.dev", - zone: HostedZone.fromLookup(stack, "HostedZone", { - domainName: "serverless-stack.com", - }), - }); - } - stack.addOutputs({ Url: site.customDomainUrl || site.url, }); From 3a1211ec63e3950752090053bf8f6bf519fcd454 Mon Sep 17 00:00:00 2001 From: Jay V Date: Fri, 16 Aug 2024 20:06:45 -0400 Subject: [PATCH 3/3] Updating domains --- sst.config.ts | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/sst.config.ts b/sst.config.ts index e9d71c0dd..fe3294513 100644 --- a/sst.config.ts +++ b/sst.config.ts @@ -13,7 +13,10 @@ export default { const site = new StaticSite(stack, "site", { customDomain: stack.stage === "prod" - ? "guide.sst.dev" + ? { + hostedZone: "sst.dev", + domainName: "guide.sst.dev", + } : stack.stage.startsWith("branchv") ? { hostedZone: "archives.sst.dev",