web服务弹性伸缩
This post details the languages, libraries, and tools that I’m using to build Skilled.dev, a platform to prepare developers to succeed in coding interviews.
这篇文章详细介绍了我用来构建Skilled.dev的语言，库和工具， Skilled.dev是一个平台，旨在帮助开发人员成功地编写采访访谈。
TLDR (TLDR)
UX + Performance + Scalable + Customizable
UX +性能+可扩展+可自定义
My decisions focus on automating parts of the process that would prevent me from doing what I want to do — building a product that provides a ton of value to my users. I optimize for fast iteration speed, developer experience, and scalability, without sacrificing control or customization when it’s needed.
我的决定集中在流程的某些部分的自动化上，这些部分可能会阻止我做自己想做的事情-开发一种为用户提供大量价值的产品。 我为快速迭代速度，开发人员体验和可伸缩性进行了优化，而无需在需要时牺牲控制或自定义。
Cost: $77 all-in right now. This is all in infrastructure costs and likely won’t grow to be more much expensive for a while. There will be additional costs like email marketing and transaction fees.
费用：77美元，现在全额支付 。 这全部是基础设施成本，很可能在一段时间内不会变得更加昂贵。 会有电子邮件营销和交易费用之类的额外费用。
Stress Test Results: I sent 10000 page requests over the course of 1 minute (167 per second) and the infrastructure didn’t flinch. The overall response time average was 990ms, and the 95th percentile database response time was 75ms. The $7 dyno I’m using didn’t cross 60% usage. I used loader.io to perform the test. This is 10k page views, but I haven’t added up the additional calls it makes inside the page which would be many more.
压力测试结果 ：我在1分钟内发送了10000个页面请求(每秒167个)，而基础架构没有退缩。 总体平均响应时间为990ms，第95个百分位数的数据库响应时间为75ms。 我正在使用的$ 7 dyno没有超过60％的使用率。 我使用loader.io进行测试。 这是10k的页面浏览量，但是我没有将它在页面内进行的其他调用加起来的数量会更多。
You can find a more in-depth analysis towards the end of the article in the “Stress Test and Scalability” section.
在“压力测试和可伸缩性”部分中，您可以在本文结尾处找到更深入的分析。
介绍 (Intro)
Skilled.dev is a user-focused app where the UX is essential to teaching as effectively as possible, and I think it has parallels with a broad category of products. I also want to move beyond the standard programming tutorials and show why we use certain tools and how to we can leverage them to rapidly build applications that scale, even if you’re a solo developer or on a small team.
Skilled.dev是一个以用户为中心的应用程序，其中UX对于尽可能有效地教学至关重要，我认为它与广泛的产品类别具有相似之处。 我还想超越标准的编程教程，并说明为什么我们使用某些工具，以及如何利用它们来快速构建可扩展的应用程序，即使您是一个单独的开发人员或一个小型团队也是如此。
I’m also starting a YouTube channel where I’ll be sharing insight into our projects (Level Up Coding, Skilled.dev, gitconnected.com) and walk you through the code and how we build things. I’ll also be creating videos for coding interview questions and provide career growth advice.
我还将启动一个YouTube频道 ，在该频道中 ，我将分享对我们项目的了解(Level Up Coding，Skilled.dev，gitconnected.com)，并向您介绍代码以及我们如何构建事物。 我还将创建用于编码面试问题的视频，并提供职业发展建议。
我的堆栈 (My Stack)
I’ll briefly mention the tools here and go into more detail in the rest of the article for why I chose each one.
我将在此处简要提及这些工具，并在本文的其余部分中详细介绍为什么我选择每种工具。
At the end of the article, I’ll also provide screenshots of how I’ve structured the code.
在文章的结尾，我还将提供如何构造代码的屏幕截图。
前端($ 0) (Frontend ($0))
TypeScript (with auto-generated types through GraphQL)
TypeScript (通过GraphQL自动生成的类型)
CSS-in-JS using Styled Components
Apollo for GraphQL API consumption
Apollo用于GraphQL API的使用
MDX for writing lesson content
MDX用于编写课程内容
后端($ 0) (Backend ($0))
GraphQL using Hasura
- Lambda functions through Next.js Lambda通过Next.js函数
- PostgreSQL PostgreSQL
- Authentication is hand-rolled initially to prevent vendor lock-in 最初会手动进行身份验证，以防止供应商锁定
基础设施($ 77) (Infrastructure ($77))
Frontend / serverless API deployed to Vercel
部署到Vercel的前端/无服务器API
GraphQL API deployed to Heroku
GraphQL API部署到Heroku
GitHub for storing code
GitHub用于存储代码
Sentry for bugs and application crashes
哨兵的错误和应用程序崩溃
开发资源 (Dev Resources)
Having the right workflow makes you as effective as possible. These aren’t part of my code stack, but I think it’s worthing mentioning because they save me a ton of time.
拥有正确的工作流程将使您尽可能地高效。 这些不是我的代码堆栈的一部分，但是我认为值得一提，因为它们为我节省了大量时间。
Daily.dev (Daily.dev)
The first is daily.dev. They aggregate and algorithmically sort the best developer news as a new tab in your browser. This has saved me a ton of time by finding the content I care about without needing to switch between different websites.
第一个是daily.dev 。 他们将最佳开发者新闻汇总并按算法排序，作为浏览器中的新标签页。 通过查找所需内容，无需在其他网站之间切换，这为我节省了很多时间。
TabNine (TabNine)
A tool I discovered recently that has made me way more productive in my text editor is TabNine. It’s an autocompletion tool that’s powered by AI. In many cases, it feels like it codes for me. For example, it has recognized the patterns I use for writing styles where I call the outer div a Wrapper:
我最近发现的一个工具TabNine使我的文本编辑器更加高效。 这是一个由AI驱动的自动完成工具。 在许多情况下，感觉像是为我编码。 例如，它已经识别出我用于编写样式的模式，其中我将外部div称为Wrapper ：
One bonus for me is that I’m writing my content for lessons in my text editor using Markdown, and TabNine is smart enough to suggest words and spell check for English sentences as well as code.
对我来说，一个好处是，我可以使用Markdown在文本编辑器中编写课程内容，TabNine足够聪明，可以建议单词和英语句子以及代码的拼写检查。
Here’s a brief example of TabNine, but you’ll also notice in some of the images/screen recordings in the article.
这是TabNine的简短示例，但您还将在文章中的某些图像/屏幕记录中注意到。
前端($ 0) (Frontend ($0))
打字稿 (TypeScript)
TypeScript has transformed the frontend and should be strongly considered for any production project. It makes our code safer (by at least 38% according to Airbnb), integrates with our text editors to improve productivity, and makes our code more readable.
TypeScript改变了前端，应该在任何生产项目中都强烈考虑。 它使我们的代码更安全( 根据Airbnb至少达到38％ )，与我们的文本编辑器集成以提高生产率，并使我们的代码更具可读性。
But that’s not even the best part — TypeScript seamlessly integrates with GraphQL to generate types for your client and React hook fetches (more on this later). Honestly, it’s like programming with cheat codes. Just put in a couple of keystrokes, and the autocompletion basically writes all your code and builds your components for you. I use graphql-code-generator, but there are other options.
但这还不是最好的部分-TypeScript与GraphQL无缝集成以为您的客户端和React钩子获取生成类型(稍后会详细介绍)。 老实说， 这 就像 使用作弊代码进行编程 一样 。 只需输入几次击键，自动完成功能就可以编写所有代码并为您构建组件。 我使用graphql-code-generator ，但是还有其他选择。
There is admittedly some upfront cost to learning TypeScript and maintaining it, but I couldn’t imagine working on a project without it at this point.
诚然，学习TypeScript和维护它需要一定的前期成本，但我无法想象目前没有它就可以进行项目。
与Next.jsReact (React with Next.js)
I’ll be brief on the React part because most people know what it is at this point. I know it’s up for debate, but to me React is still the best library to build UI. The core team is strong, the library is constantly improving, and the community huge. Also (if things go well 🤞) it should be easiest to hire developers with React experience.
我将简要介绍一下React部分，因为大多数人都知道这是什么。 我知道这是个有争议的话题，但是对我而言，React仍然是构建UI的最佳库。 核心团队强大，图书馆在不断完善，社区庞大。 同样(如果一切顺利)，雇用具有React经验的开发人员应该是最容易的。
Next.js is a semi-opinionated React framework for building incredibly fast applications. It requires some codebase structuring and has a strict API on how you access the document and data, but the value it provides is amazing.
Next.js是一个半概念化的React框架，用于构建令人难以置信的快速应用程序。 它需要一些代码库结构，并具有关于如何访问文档和数据的严格API，但是它提供的价值是惊人的。
Next.js handles all the client-side toolchain for you and is highly optimized for production applications. As long as you follow their patterns, you don’t have to worry about the painful parts of setting up an application (ie. Webpack configs, code splitting, routing) and can instead focus your time on building a web app your users love. Also, it’s really fast and follows best practices. Below is the Lighthouse result for the page:
Next.js为您处理所有客户端工具链，并针对生产应用程序进行了高度优化 。 只要遵循它们的模式，您就不必担心设置应用程序的痛苦部分(即Webpack配置，代码拆分，路由)，而可以将时间集中在构建用户喜欢的Web应用程序上 。 此外，它确实非常快并且遵循最佳实践。 以下是该页面的Lighthouse结果：
Next.js provides server-side rendering and static site generation out of the box, and will even granularly render the most optimized way (CSR/SSR/SSG) based on how you provide data to each individual page.
Next.js提供了开箱即用的服务器端渲染和静态站点生成功能，甚至可以根据您向每个页面提供数据的方式来细化最优化的方式(CSR / SSR / SSG)。
It also optimizes the build and code splits so you only download the JavaScript needed for each page. It will then eagerly download the JavaScript for subsequent pages so it’s already in the browser as your user navigates around.
它还优化了构建和代码拆分，因此您只需下载每个页面所需JavaScript。 然后，它会急切地下载后续页面JavaScript，因此当您的用户四处浏览时，它已经在浏览器中。
If you use Vercel (creators of Next.js) as your frontend infrastructure provider, it’s seamless and automatic to deploy your app. You can learn more about this below in the infrastructure section.
如果将Vercel(Next.js的创建者)用作前端基础结构提供程序，则部署应用程序是无缝且自动的。 您可以在下面的基础结构部分中了解更多有关此内容的信息。
TLDR: Next.js improves the performance of your app while also requiring less of your time to configure and maintain it.
TLDR：Next.js可以提高应用程序的性能，同时还需要更少的时间来配置和维护它。
CSS库-无 (CSS Library — None)
I really wanted to have full control over the user experience and design, so I decided to code the entire UI from scratch. This allows me to optimize for the value that I’m trying to deliver. All my components are being built by hand with the exception of some lower-level libraries to facilitate functionality.
我真的很想完全控制用户体验和设计，因此我决定从头开始编写整个UI。 这使我可以优化自己想要提供的价值。 我的所有组件都是手工构建的，除了一些较低级的库以方便使用。
One thing I am considering adding is Tailwind CSS. I’ve found myself writing a lot of boilerplate styles and wasting time. I also dread building new components for simple things. I think Tailwind will help be an additional benefit to further improve iteration speed.
我正在考虑添加的一件事是Tailwind CSS 。 我发现自己写了许多样板样式并浪费时间。 我还害怕为简单的事情构建新的组件。 我认为Tailwind将有助于进一步提高迭代速度。
Also, accessibility (a11y) is very important to me, and from my research, not many frameworks do a great job. It was also an opportunity for me to really understand how to correctly build an accessible website and continue to improve it over time. It’s an ongoing process, but my hope is that I’m building something that’s usable by everyone.
另外，可访问性(a11y)对我来说非常重要，从我的研究来看，没有多少框架做得很好。 这也是我真正了解如何正确构建可访问网站并随着时间的推移不断改进的机会。 这是一个持续的过程，但是我希望我正在构建一个每个人都可以使用的东西。
The important pieces of accessibility that I’ve learned:
我学到的重要的可访问性：
- The most important thing is well-structured HTML. Computers understand how to handle this. 最重要的是结构良好HTML。 计算机了解如何处理。
- Manage cursor and focus. 管理光标和焦点。
- Use a screen reader to test pages. 使用屏幕阅读器测试页面。
- Aria should only need to be used for a small number of cases when HTML structure isn’t enough. 只有在HTML结构不够用的少数情况下，才需要使用Aria。
If
如果
UI样式CSS-in-JS (CSS-in-JS for UI Styles)
I was reluctant for a long time to adopt this approach, but now I consider it an essential part of my stack. I’m using Styled Components, but I’ve also had an excellent experience in the past using Emotion.
我很长时间都不愿采用这种方法，但是现在我认为它是我堆栈中必不可少的一部分。 我使用的是样式化组件，但过去使用Emotion也有出色的经验。
CSS-in-JS allows me to think of the UI style as simply a component in my app. The styled-components can receive props and can dictate the way the style renders based on the state of the application.
CSS-in-JS使我可以将UI样式视为应用程序中的一个简单组件。 样式化的组件可以接收道具，并可以根据应用程序的状态指示样式的渲染方式。
It also allows you to share styles using the standard import/export syntax, so you’re always just writing JavaScript.
它还允许您使用标准的import / export语法共享样式，因此您始终只在编写JavaScript。
So instead of doing this where our component manages the style:
因此，与其在我们的组件管理样式的地方这样做，不如：
We simply pass the prop to our styled component, and it decides how to render:
我们只需将prop传递给样式化的组件，即可决定如何渲染：
I used to be against CSS-in-JS because I thought it broke separation of concerns, but after years of painfully managing classes to dictate styles, I realized the concerns aren’t separate at all. The style, state, and layout of your application are so tightly coupled, that it makes more sense to unify them.
我曾经反对CSS-in-JS，因为我认为它打破了关注点的分离，但是经过多年痛苦地管理类以指示样式的痛苦之后，我才意识到关注点根本不是分离的。 应用程序的样式，状态和布局是如此紧密地耦合在一起，因此将它们统一起来更为有意义。
So, it takes a different view on separation of concerns — instead of a component managing the class names to style a component, the component that actually is changing its style receives the data and makes the decision.
因此，对于关注点的分离采取了不同的观点-实际上是在改变其样式的组件接收数据并做出决定，而不是通过组件管理类名称来对组件进行样式设置。
内容的Markdown Extended(MDX) (Markdown Extended (MDX) for Content)
I was torn between using a content management system (CMS) or writing the lessons inside the codebase. I want to add dynamic functionality to the content to improve the educational experience which means I likely need to wire JavaScript up to it — this means a CMS isn’t really an option since it’s static strings.
在使用内容管理系统(CMS)或在代码库内编写课程之间，我陷入了困境。 我想在内容中添加动态功能以改善教育体验，这意味着我可能需要将JavaScript连接到它-这意味着CMS并不是真正的选择，因为它是静态字符串。
This made MDX the perfect option. It allows me to write content using markdown inside the codebase, but also marry it with React. So, I can import components into my markdown to add additional functionality without sacrificing the ease of how I write lessons.
这使MDX成为理想的选择。 它允许我在代码库中使用markdown编写内容，也可以将其与React结合使用。 因此，我可以将组件导入到Markdown中以添加其他功能，而无需牺牲编写课程的简便性。
As an example, I wanted to help my users visualize what it means to recursively generator permutations, so I built a component that generates them and embedded it alongside my text content:
举例来说，我想帮助用户直观地了解递归生成器排列的含义，因此我构建了一个生成这些排列并将其嵌入文本内容的组件：
后端($ 0) (Backend ($0))
My backend requires very little coding. I get a full GraphQL API managed by a dashboard through Hasura which is perfect for handling CRUD operations. For more complex business logic, I use API routes provided by Next.js (from my frontend), so it takes minimal additional effort.
我的后端需要很少的编码。 我通过Hasura获得了由仪表板管理的完整GraphQL API，非常适合处理CRUD操作。 对于更复杂的业务逻辑，我使用了Next.js提供的API路由(来自我的前端)，因此只需很少的工作。
The one area that I did things the hard way is authentication. I coded that all myself because any provider requires heavy lock-in, and I wasn’t ready to commit yet.
我很难完成的工作之一是身份验证。 我自己编写了所有代码，因为任何提供程序都需要大量锁定，而我还没有准备好提交。
GraphQL与Hasura (GraphQL with Hasura)
Hasura has saved me hundreds of hours of coding and has totally changed how I think about my stack. Their dashboard allows you to manage your database with a user interface, and it creates migration files for you automatically. Hasura also builds your GraphQL API with all the necessary CRUD operations.
Hasura为我节省了数百小时的编码，并彻底改变了我对堆栈的看法。 他们的仪表板允许您使用用户界面管理数据库，并自动为您创建迁移文件。 Hasura还使用所有必要的CRUD操作来构建您的GraphQL API。
It runs on Haskell and transforms GraphQL requests directly to a SQL query to run on PostgreSQL. Because of this, it’s blazing fast, and they claim you can support 1000 concurrent users on the cheapest tier of plans in cloud infrastructure providers.
它在Haskell上运行，并将GraphQL请求直接转换为SQL查询以在PostgreSQL上运行。 因此，它的速度非常快，他们声称您可以在云基础架构提供商中最便宜的计划层上支持1000个并发用户。
Not only is it incredibly simple, but it’s also extendable. You can combine it with custom GraphQL schemas on other servers, use hooks that can execute lambda functions at any point during the database transaction lifecycle, and schedule cron jobs.
它不仅非常简单，而且还可以扩展。 您可以将其与其他服务器上的自定义GraphQL模式结合使用，使用可以在数据库事务生命周期中的任何时候执行lambda函数的挂钩，并计划cron作业。
Hasura also uses other open source technologies, so the vendor lock-in is minimal. It’s built on top of PostgreSQL and works with any authentication provider and GraphQL client. You can use your own tools to manage migrations or work within their dashboard. You have as much or as little control as you want, and if you ever want to use something different, just remove Hasura and you still have a well-formed Postgres database.
Hasura还使用其他开放源代码技术，因此供应商锁定很少。 它基于PostgreSQL构建，可与任何身份验证提供程序和GraphQL客户端一起使用。 您可以使用自己的工具来管理迁移或在其仪表板中工作。 您拥有所需的控制权，或者，如果您想使用其他功能，只需删除Hasura，您仍然拥有格式良好的Postgres数据库。
You control everything — auto-generated migrations, permissions, relationships — all through their dashboard. Check it out below:
您可以控制所有内容，包括自动生成的迁移，权限和关系，这些都可以通过其仪表板进行。 在下面查看：
Hasura provides a secure GraphQL API for minimal effort that I can manage through a dashboard. The strong typing from GraphQL propagates to my frontend with automatic code generation tools, so the queries and data in my TypeScript match exactly to what’s expected from the database. My entire stack is in sync, and I don’t have to write any code to make it happen.
Hasura提供了一个安全的GraphQL API，使我可以通过仪表板进行最小的工作。 GraphQL的强类型通过自动代码生成工具传播到我的前端，因此TypeScript中的查询和数据与数据库期望的完全匹配。 我的整个堆栈都处于同步状态，而不必编写任何代码即可实现它 。
Also, did I mention Hasura is free and open source?
另外，我是否提到过Hasura是免费和开源的？
Next.js中具有Lambda函数的业务逻辑 (Business Logic with Lambda Functions in Next.js)
Hasura is excellent for CRUD operations, but you still need additional tools for server-side business logic. Luckily with Next.js you can easily add this through API routes, and they work automagically when you deploy with Vercel.
Hasura非常适合CRUD操作，但是您仍然需要用于服务器端业务逻辑的其他工具。 幸运的是，通过Next.js，您可以轻松地通过API路由添加此路由，并且在使用Vercel进行部署时，它们会自动运行。
Next.js stores routes in a pages folder, and you can create API routes inside a pages/api folder. Then each file is treated as a standalone Lambda function where you receive an object containing the request data, allowing you to handle any logic that you are unable to with Hasura.
Next.js将路由存储在pages文件夹中，您可以在pages/api文件夹中创建API路由。 然后，每个文件都被视为独立的Lambda函数，在该函数中您会收到一个包含请求数据的对象，从而使您可以处理Hasura无法处理的任何逻辑。
基础设施($ 77) (Infrastructure ($77))
The goal with infrastructure was to be as automated as possible and rely on companies who have perfected their systems. I also want it to be reasonably priced because it’s very easy to get caught up in overpaying for cloud services.
基础架构的目标是尽可能自动化，并依靠完善其系统的公司。 我也希望它的价格合理，因为很容易陷入为云服务支付过多的困境。
前端/无服务器API托管— Vercel(每月20美元) (Frontend / Serverless API Hosting — Vercel ($20/mo))
Moving towards Vercel has saved me a ton of time and money. There is nothing for you to manage in terms of maintenance or scaling. Since it is entirely based on Lambda functions, the scalability should be infinite (or at least far beyond what most apps would ever need).
转向Vercel节省了我大量的时间和金钱。 在维护或扩展方面，您无需管理。 由于它完全基于Lambda函数，因此可扩展性应该是无限的(或至少远远超出大多数应用程序所需的范围)。
Next.js was created by Vercel, so they have made it incredibly simple to deploy apps. Everything is either a lambda function (including server-side rendering) or a static file that can be cached across the world.
Next.js是由Vercel创建的，因此他们使部署应用程序变得异常简单。 一切都是lambda函数(包括服务器端渲染)或可以在世界范围内缓存的静态文件。
I set up staging deployments happen automatically on Git commits. Production deployments happen when I execute now --prod in the CLI. I could have production automated as well, but I still want a human touchpoint just to make sure everything is good before release. Still, one CLI command to deploy your production application is nothing.
我设置了分阶段部署，该部署在Git提交时自动进行。 我now --prod在CLI中执行now --prod ，就会进行生产部署。 我也可以使生产自动化，但是我仍然希望有一个人工接触点，以确保发布前一切都很好。 尽管如此，用于部署生产应用程序的一个CLI命令还是没有什么。
The $20 includes all your bandwidth and site access needs. However, if I have one complaint, it’s they have a pretty low limit on the number of lambda functions you can use (12 on the free plan, 24 on a paid plan). This may seem like a reasonable amount, but it also includes all routes that are server-side rendered. I unknowingly maxed out the free plan before I even made my first deployment to a test server.
$ 20包括您的所有带宽和站点访问需求。 但是，如果我有一个抱怨，那就是它们对您可以使用的lambda函数的数量有非常低的限制(免费计划为12，付费计划为24)。 这似乎是一个合理的数量，但它还包括服务器端渲染的所有路由。 在不知不觉中，我甚至没有将免费计划完全部署到测试服务器上。
GraphQL API — Heroku($ 50数据库+ $ 7 dyno) (GraphQL API — Heroku ($50 database + $7 dyno))
Heroku makes it incredibly simple to deploy an API, and Hasura provides a template to make maintaining and upgrading their engine trivial. It’s as simple as a git push command. Heroku also fully manages the Postgres database for you.
Heroku使部署API变得异常简单，而Hasura提供了一个模板，使维护和升级其引擎变得微不足道。 就像git push命令一样简单。 Heroku还可以为您完全管理Postgres数据库。
I’m currently paying for a 64GB Postgres database and a $7 dyno (although I may need a tier up here after launch). I think the database storage should last me for a while, but there are cheaper options if you want to bootstrap a little more. You can also use the database free tier to build your app before it’s ready for production (or always for your staging environment).
我目前正在为一个64GB的Postgres数据库和一个7美元的dyno支付费用(尽管在发布后我可能需要在这里加一层)。 我认为数据库存储应该可以使用一段时间，但是如果您想进行更多引导，则可以使用更便宜的选择。 您还可以使用数据库免费层来构建您的应用程序，然后再将其准备好进行生产(或始终用于您的暂存环境)。
$50 is probably middle of the road in terms of pricing. You can definitely go cheaper if you want to manage it all yourself, or you can opt for more expensive options on something like AWS. To me, it’s worth the price to get everything Heroku has to offer. It’s likely more than I’ll need for a while, but I know it’s going to be blazing fast, and I never have to think about maintaining it.
就定价而言，50美元可能只是中间价。 如果您想自己管理所有事务，那么绝对可以便宜一些，或者可以在AWS等产品上选择更昂贵的选择。 对我来说，获得Heroku提供的一切都是值得的。 它可能超出了我一段时间的需求，但我知道它会很快发展起来，而且我永远不必考虑维护它。
An additional benefit of Heroku is their metrics. They provide some general insight into the requests and your database performance, so you won’t need additional tooling for visibility, at least early on.
Heroku的另一个好处是它们的指标。 它们提供了对请求和数据库性能的一般了解，因此，至少在早期，您不需要其他工具即可获得可见性。
GitHub用于代码存储和版本控制(免费) (GitHub for Code Storage and Versioning (free))
GitHub has made pretty much everything free now for individuals or small teams, so it was a no brainer for me to use them. Their user experience and tools are the best out there, and there are integrations with all the other tools I use.
GitHub现在已经为个人或小型团队免费提供了几乎所有内容，因此使用它们对我来说丝毫不费吹灰之力。 他们的用户体验和工具是最好的，并且与我使用的所有其他工具集成在一起。
漏洞跟踪和应用程序崩溃哨兵(免费) (Sentry for Bug Tracking and Application Crashes (free))
Using Sentry is essential for an application with real users. No matter how careful you are when you code or how many tests you have, there will always be issues when you have real users on your application. Sentry lets you discover bugs and quickly determine what the cause was.
对于拥有真实用户的应用程序，使用Sentry是必不可少的。 无论您在编写代码时有多认真，还是拥有多少测试，当您在应用程序中拥有真正的用户时，总会出现问题。 Sentry使您可以发现错误并快速确定原因。
Sentry’s free plan is pretty generous and should last you a while. If you get to the point where you’re maxing it out, then your app is also probably earning enough revenue to afford the next step.
Sentry的免费计划相当慷慨，应该持续一会儿。 如果您达到了极限，那么您的应用程序也可能会获得足够的收入，足以承担下一步的任务。
压力测试和可伸缩性 (Stress Test and Scalability)
I used loader.io with 5000 clients to two URLs (10000 total page requests) distributedly evenly over the course of one minute. This is equivalent to 167 requests per second.
我将loader.io与5000个客户端一起使用，在一分钟的时间内平均分配了两个URL(总共10000个页面请求)。 这相当于每秒167个请求。
One interesting thing to note is that there is a large peak at the beginning of the test. My assumption is that there was either a cache miss or booting up a cold lambda function that caused it. After it resolves, all the requests consistently are handled in 600–800ms.
需要注意的一件有趣的事是，测试开始时有一个很大的峰值。 我的假设是，可能是缓存未命中或启动了导致它的冷lambda函数。 解决后，所有请求均在600-800毫秒内得到一致处理。
Honestly, if your app is handling this much traffic, you probably have an amazing business, and this is likely more traffic than I’ll ever receive to this site. This would be the equivalent of millions of users per month.
老实说，如果您的应用程序处理的流量如此之多，那么您的生意可能就很棒，而且这可能比我收到的该网站的流量还要多。 这相当于每月有数百万的用户。
I was honestly blown away with how well it performed. The infrastructure barely moved.
老实说，我对它的表现感到震惊。 基础设施几乎没有动。
Results:
结果：
- 10000 total page requests 总共10000个页面请求
- 990ms overall average response time 整体平均响应时间990ms
- 75ms 95th percentile database response time. This means 95% of database requests were handled faster than 75ms. 75ms第95个百分点的数据库响应时间。 这意味着95％的数据库请求处理速度超过75ms。
- 60% max CPU load 最大CPU负载60％
- 9959 successful requests 9959个成功请求
- 20 timeouts 20超时
- 643MB of data transferred 传输643MB的数据
- Zero error responses (4xx or 5xx) 零错误响应(4xx或5xx)
Load test results:
加载测试结果：
Metrics from Hasura dashboard:
Hasura仪表板的指标：
结论 (Conclusion)
Honing in my stack was a lot of painful trial and error, and I hope this saves you time for making decisions for your own projects. This setup makes feel very empowered to move quickly while building fast, scalable apps and also provides the control for the user experience to create something my community will love.
在我的堆栈中磨练很多痛苦的尝试和错误，我希望这可以节省您为自己的项目制定决策的时间。 此设置使您感到非常有能力在构建快速，可扩展的应用程序时快速移动，还可以控制用户体验，以创建我的社区会喜欢的东西。
web服务弹性伸缩
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
