惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园 - 聂微东
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
L
LangChain Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 司徒正美
WordPress大学
WordPress大学
T
The Blog of Author Tim Ferriss
Blog — PlanetScale
Blog — PlanetScale
J
Java Code Geeks
Y
Y Combinator Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
GbyAI
GbyAI
Vercel News
Vercel News
大猫的无限游戏
大猫的无限游戏
T
Tailwind CSS Blog
Jina AI
Jina AI
B
Blog
Recorded Future
Recorded Future
MyScale Blog
MyScale Blog
I
InfoQ
aimingoo的专栏
aimingoo的专栏
博客园_首页
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
The Cloudflare Blog
雷峰网
雷峰网
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
腾讯CDC
爱范儿
爱范儿
Last Week in AI
Last Week in AI
博客园 - 三生石上(FineUI控件)
博客园 - Franky
Schneier on Security
Schneier on Security
V
V2EX
TaoSecurity Blog
TaoSecurity Blog
H
Hacker News: Front Page
Cloudbric
Cloudbric
D
DataBreaches.Net
B
Blog RSS Feed
P
Palo Alto Networks Blog
云风的 BLOG
云风的 BLOG
NISL@THU
NISL@THU
I
Intezer
Recent Commits to openclaw:main
Recent Commits to openclaw:main
Cyberwarzone
Cyberwarzone
F
Fortinet All Blogs
D
Darknet – Hacking Tools, Hacker News & Cyber Security
C
Cybersecurity and Infrastructure Security Agency CISA
C
Cisco Blogs
K
Kaspersky official blog
Forbes - Security
Forbes - Security

Graphite blog

Introducing Code Tours: a new way to review Introducing Cursor Cloud Agents in Graphite Building the future of software development with Cursor Reimagining the PR Page: Designing for speed and focus Graphite changelog [11-20-2025] Graphite changelog [11-04-2025] Graphite changelog [10-16-2025] The future of engineering is collaborative (and already here) Meet Graphite Agent: the next evolution of AI code review Introducing frozen branches: A safer way to build on your teammates’ work Graphite changelog [09-17-2025] How we sped up code search for Graphite Chat Introducing Graphite Chat AI is writing code—here's why it also needs to review that code How I got Claude to write code I could actually ship How we built the first stack-aware merge queue (and why it matters) How we organize our monorepo to ship fast Graphite brings stacking to Tower Code review tooling: Should you build or buy? Making AI code review available to everyone Introducing: The new Graphite + Linear integration Graphite raises $52M and launches Diamond to reimagine code review for the age of AI Why AI will never replace human code review How stacked PRs unblock distributed development teams Graphite is going to Developer Week 2025 Beating the end of year code freeze How Graphite’s eng team ships code remarkably fast Why we chose Anthropic's Claude to power Graphite Reviewer AI code generation will remain fragmented How we redesigned Graphite's landing page in-house Introducing Graphite Reviewer: your AI code review companion How AI code review reduces review cycles to improve developer productivity What if you could get instant feedback on your code? The new developer toolchain Not Rocket Science - How Bors and Google’s TAP inspired modern merge queues Graphite's State of code review 2024 How Google migrated billions of lines of code from Perforce to Piper Going from 0 to 1: How to write better unit tests when there are none Speed up your merges: Parallel CI is now generally available for teams using Graphite’s merge queue Down for less than four minutes a month: how AWS deploys code BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days Graphite is now free for startups and open source projects Launch week wrap-up (May 2024) Reduce CI costs for Buildkite and GitHub Actions Cheaper CI & faster merging with batching How Google does code review The technical learning curve at a startup is gentler than you might think Graphite will now automatically rebase your partially-merged stacks Multiple engineers can now seamlessly collaborate on the same stack of PRs Do you ever outgrow GitHub? From the 80's to 2024 - how CI tests were invented and optimized Graphite changelog [4/10/2024] 🎺 Graphite changelog [4/25/2024] 🐸 How Stack Overflow replaced Experts Exchange How GitHub monopolized code hosting Graphite changelog [3/27/2024] 🤝 The core principles of building a good AI feature Onboarding roulette: deleting our employee accounts daily Graphite changelog [3/13/2024] 🚁 Why Facebook doesn’t use Git How to recreate the Phabricator code review workflow Types of code reviews: Improve performance, velocity, and quality What's the best GitHub pull request merge strategy? Phabricator vs GitHub vs Graphite: How do they stack up? Improving team velocity through better pull request practices Moving fast breaks things: the importance of a staging environment Building trust as a software engineer Keeping code simple: moving fast by avoiding over-engineering What's better than GitHub pull request filters? The Graphite pull request inbox 7 Best Phabricator alternatives for PR stacking + code review [2024] Accurate eng estimations: predicting and negotiating the future Tracking and understanding GitHub PR stats: A step-by-step guide 8 pull request best practices for optimal engineering What’s next for Graphite Graphite Q1 Launch week: Stacking with the tools you love Graphite Q1 Launch week: Making stacking seamless Accelerating code review The Mom Test How to use stacked PRs to unblock your entire team Graphite Q1 launch week 2024 The practical and philosophical problems with AI code review Empirically sup code review best practices Call site attribution: how to pinpoint rogue SQL queries throttling your performance Every engineer should understand git reflog Post mortem: we took 124 seconds from you, here's 378 back Your GitHub pull request workflow is slowing everyone down Optimizing CI/CD workflows for trunk-based development How large pull requests slow down development 3 key lessons in application server optimization Trunk-based development: why you should stop using feature branches Git was built in 5 days Why large companies and fast-moving startups are banning merge commits How long should your CI take? Experimenting with AI code review CRA to AppRouter in 5 Steps: A case study with Graphite Graphite Changelog [10/18/2023] The comprehensive guide to writing the best PR title of all time How 10,000 Developers All Contribute to the same Repo
Why we use AWS instead of Vercel to host our Next.js app
Greg Foster · 2023-11-28 · via Graphite blog

Bottom Line Up Front: At Graphite, we moved from a simple SPA deployment to a robust containerized environment using AWS ECS, enhancing our ability to manage, deploy, and scale our Next.js application.

AWS re:Invent 2023 is in full swing, and we’re here in the heart of Las Vegas, seeing the sights, exploring the conference, and spreading the word about stacking. It’s the perfect time to showcase how Graphite uses AWS in our own infrastructure, in combination with Next.js, to support our growing user base. In this post I’ll walk you through our journey from a simple SPA architecture to the adoption of a more robust solution. I'll explain why we considered various hosting options, the technical considerations that guided our decision, and why we ultimately chose to host our Next.js web application on ECS.

First, some context.

Moving away from single-page applications

The software development world moves incredibly fast - so much so that the tools and practices that served us well yesterday can quickly become limitations today. For our team at Graphite, this became especially salient as we reevaluated our web hosting strategy for our code review platform.

As a startup, the choices we make now for infrastructure can either pay dividends in empowering our growth or they can be ticking time-bombs of tech debt that create roadblocks in the future. Choosing the quick and easy path in the moment is always tempting, particularly for a small team, but the time you’ll save if you do your homework first can far outweigh the benefits of immediate gratification.

We've historically hosted our splash page and web app as single-page applications (SPAs) in S3, distributed with CloudFront—a setup known for its speed, simplicity, and reliability. However, as our platform and user base grew, the limitations of our current system began to show. It was time for change.

Migrating to Next.js for enhanced scalability and performance

Create React App had served us well, but we were in need of more sophisticated features such as faster build times and bundle splitting. We had to choose a new direction that would allow us to implement these capabilities without significantly increasing our system complexity or hosting costs.

After much exploration and debate, we decided on Next.js, primarily on account of its rapid widespread adoption and the reliability of its maintainers at Vercel.

You can read more about our journey in depth and how we moved to Next.js in just 5 PRs, however, migrating to Next wasn’t just about adopting a new framework; it was also about how to host it effectively while maintaining our performance standards and cost efficiency.

Vercel vs Amplify vs Amazon ECS

Vercel seemed like the obvious choice for hosting a Next.js app in terms of performance, simplicity, and devex, and for many companies is probably the right answer. However, it didn't align with our preference for keeping all of our hosting within our AWS VPC, and the costs were intimidating compared to our near-zero expenses with S3.

(Update: since writing, Vercel has updated their billing model to reduce the price of bandwidth and functions)

AWS Amplify also caught our attention initially, but the devex wasn’t a great fit for our enterprise-level needs - Amplify offers little visibility into builds and lacks the sophisticated deployment features we needed.

Ultimately, we decided to go with a familiar technology our team already trusted: containers on Amazon Elastic Container Service (ECS). Containerizing our Next.js application unified our frontend and backend hosting strategies, allowing us to use templated terraform configurations and take advantage of the load balancers already in place for our backend, setting the stage for blue-green deployments and simplified rollbacks.

This choice may seem unconventional—running Next.js in a container rather than utilizing edge compute features—but it was a calculated decision. We conducted rigorous testing, including a head-to-head comparison of our Next.js splash page hosted on edge lambdas versus ECS containers, and found no significant difference in performance.

Let’s take a look at the real-world applications of our hosting strategy and how it stands up to the demands of a growing enterprise platform.

Streamlining deployment with Next.js on AWS ECS

The shift to hosting our Next.js application on AWS ECS didn't happen in a vacuum; it came soon after our launch out of beta. We needed to scale and needed infrastructure that would scale with us, both in terms of performance, and feature set.

The six main benefits of deploying Next.js on AWS ECS :

  • Performance: One of the initial concerns with containerized hosting was performance, especially when compared to edge computing solutions. However, our empirical tests showed that Next.js running in containers on ECS performed just as well as an edge compute setup. The ability to leverage Amazon's reliable infrastructure meant that we didn't sacrifice the speed our users had come to expect.

  • Scalability: As our user base grows, so does the load on our services. ECS facilitates easy scaling of our containerized services to meet increasing demand. By using templated Terraform configurations, we can replicate environments quickly and efficiently, which is also essential for a growing startup like ours.

  • Cost Efficiency: Keeping an eye on compute costs is crucial for an early-stage startup. With our ECS setup, we continue to benefit from AWS's pay-as-you-go pricing model, maintaining cost-effectiveness while enjoying the advantages of a more dynamic hosting environment.

  • Consistency and Simplification: By unifying our hosting strategy for both frontend and backend services on ECS, we’ve simplified our infrastructure. This consistency reduces cognitive load for our team and streamlines our development pipeline, making the entire deployment process more straightforward.

  • Deployment Flexibility: ECS allows us to implement sophisticated deployment strategies. We've adopted blue-green deployment, which reduces downtime and risk by running two identical production environments, only one of which serves live production traffic at any time. This means we can deploy and test a new version without impacting our users, switching over only when we're confident in the update.

  • Security and Compliance: Hosting within our AWS VPC keeps all of our services within a secure, controlled environment. This is not just about peace of mind; it's about ensuring that we adhere to best practices and compliance requirements, which is non-negotiable for enterprise-grade applications.

While these benefits were a huge upgrade over our previous SPA setup, even the best infrastructure requires careful management and optimization. Next, we’ll share some of the tips and best practices that have helped us make the most of our ECS hosting environment.

Maximizing efficiency with Next.js and AWS best practices

Migrating to a containerized environment with ECS was a significant technical undertaking that required a lot of iteration, and along the way we developed the following list of best practices:

  • Optimize for cold starts: When using server-side rendering with Next.js on ECS, it’s crucial to optimize for cold starts. Efficient container startup times are vital for ensuring that new instances can handle traffic spikes gracefully.

  • Automate your infrastructure: Use infrastructure as code (IaC) tools like Terraform to automate the deployment and management of your ECS infrastructure. This ensures consistency, reduces human error, and makes your infrastructure easily reproducible.

  • Utilize ECS features for deployment: Take full advantage of ECS features like service discovery, which makes it easier to connect the containers within your environment, and task definitions to control deployments and rollbacks precisely.

  • Optimize costs: Regularly review your resource utilization and optimize container sizing to manage costs effectively. AWS offers a range of pricing options and services that can help manage and reduce your spending. Twice now, one of our engineers has noticed a huge upward trend in AWS cost, and introduced optimizations that saved us hundreds of thousands of dollars annually.

By adhering to these best practices, we ensure that our ECS-hosted applications at Graphite remain robust, secure, and ready to scale. In the final section, I'll wrap up with a summary of our journey and the actionable takeaways that you can apply to your own projects.

Key takeaways

Our journey at Graphite to find the optimal hosting solution for our Next.js application led us down a path filled with technical and strategic considerations. Our final landing spot, AWS ECS, provided the sweet spot of performance, control, and scalability—aligning perfectly with our growth trajectory and technical needs. Here are the actionable takeaways from our experience:

  • Evaluate your requirements: Carefully assess your current and future infrastructure needs before committing to a migration or a new hosting strategy.

  • Don’t fear the container: Embrace containerization for its benefits in consistency, scalability, and performance. With the right expertise, containers can be a game-changer for your deployment processes.

  • Invest in automation: Leverage IaC for repeatable, reliable deployment processes. Automation isn't just a time-saver; it's a critical component of modern, scalable infrastructure.

  • Stay cost-aware: Keep an eye on your usage and optimize costs without compromising on necessary resources.

  • Continuous learning: The tech landscape is constantly evolving and it’s crucial to not stay locked-in to previous strategies based on sunk-cost fallacies. Try to be flexible and adapt as new technologies emerge.

As a final note, while the above approach has worked well for Graphite, the right solution is always context-dependent, and your mileage may vary. Hopefully this is helpful to teams considering the best way to host their Next.js applications - let us know if you find our learnings useful!