How Local-First Development Is Changing How We Make Software

• 

  Heavybit
  Heavybit

What Local First Is, and Why It Matters

Local-first development is a development ethos that keeps data and code on your device first. It is inherently different from cloud-first development, which puts the central “source of truth” for code online.

While cloud-based development has offered a number of advantages, it has removed significant control and access from the hands of end-users. Because most cloud applications are offered as a service, in the event of an interruption of service, users lose access to their data.

Local-first development is about building products with the cloud as optional. Its goal is to provide the cross-device collaboration of cloud with the personal data ownership of pre-cloud software development.

The benefits of local first come with tradeoffs. Even though local-first devs work primarily with data and code on their own computers, they still need to manage authentications for sensitive customer data. They also need to manage data sync issues, though techniques like auto-merging and using conflict-free replicated data types (CRDT) have helped researchers and early adopters make significant strides forward.

To help us understand the potential impact of local first, we’ve assembled a group of experts, including Heroku co-founder Adam Wiggins, researcher Brooklyn Zelenka, Netlify co-founder Matt Biilmann, and Vella founder Yonatan Feleke to cover:

• The Benefits of Local First for Software Development
• The Potential Trade-Offs of Local First
• Why Local First Is Gaining Traction
• How Local First Will Change the Way We Build Software Products

Local First Will Make Small, Sharp Tools Sharper

Adam Wiggins is the Platform GM at The Browser Company. He also co-founded the research lab Ink & Switch; the pioneering Cloud infrastructure company Heroku; and Muse, the canvas for thinking. He envisions a future where local first lets developers experiment and innovate faster, as local-first development:

• Increases Velocity: CRDT-based sync engines are the foundation for local first. Building apps on top of such a sync engine takes away all the complexity of client-server network operations, error handling, optimistic UI updates, and more. Instead, developers can work faster by just operating on all the data as if it is local.
• Decreases Resource Requirements: Cloud hosting bills are a fraction of the size when the end user’s computer does a lot more of the basic work of the application.
• Lowers the Barrier of Entry to a Wider Variety of Projects: With local-first development, it’s fast and cheap to build an app that has multi-device and multi-user capability. That means many smaller-scale projects may be built that never would have been feasible in the cloud.

More Ownership, Speed, and Better Economics with Adam Wiggins

Wiggins is direct on the value of local-first development: “Local first offers the benefits of Cloud (shareable, collaborative docs by default) together with the benefits of traditional desktop software (on-device data is much faster and works offline). There are many reasons to prefer this architecture, but my personal feeling is the most important part is the data ownership and agency this gives to end users.

For commercial engineering teams, local first offers powerful, practical benefits that are difficult to ignore. “The biggest benefits we've seen from local-first development in commercial products at scale are improved developer productivity (and thus higher shipping velocity), and lower hosting costs due to needing much less server-side compute. This is on top of the user-facing benefits of more-responsive UIs and seamless offline capability, and the philosophical benefits of data ownership.”

The co-founder suggests that if local-first development faces any significant challenges, they aren’t technical so much as they are due to relative novelty. “Most developers assume that merge conflicts will be the hardest part, but in practice, this is essentially a non-issue thanks to over a decade of deep computer science algorithm work. There are some open technical questions in the space, schema migrations being one.”

“The real biggest challenge is just that this is such a new technology that (1) it's hard to find engineers with experience in it and (2) most of the libraries and vendors available today are still fairly young. Someone new to the community compared local-first development in 2024 as being comparable to React in 2013, which I think is about right. It's exciting to be part of such a dynamic and fast-moving technical community, but for building a product in this way it means you're way out on the frontier with fast-shifting infrastructure and fewer instructional resources to rely on.”

Heroku co-founder Adam Wiggins discusses the evolution of app development at the 2012 Waza Event. Image courtesy Heroku

Where Local First Goes From Here

While local first offers powerful benefits, Wiggins suggests its growing popularity may not be due to any specific economic or data privacy-related concern. “Honestly, I think it's more just a ‘tipping point’ kind of thing.” Since 2019, the co-founder and his team have been hard at work building out both the theory and principles behind local first development, and the practical frameworks developers need.

“A small set of people (I'm one of them) from the deep research world got excited about this direction for app development seven or eight years ago and laid some of the groundwork. But it's taken this long for the theoretical and philosophical basis to transform into a set of open-source libraries, commercial vendors, and real-world success stories to light the way.”

The co-founder sees an obvious future for traditional startups to successfully adopt local first. One example is the project-tracking app Linear, which offers a real-time sync engine under the hood that enables developers to work simultaneously with far less concern for conflicts or online data issues.

“Obviously, you can point to a success story like Linear and talk about how this will change large-scale, venture-backed software. Namely, faster iteration speed, more focus on interface development compared to the backend, and a higher-performance UI for end users.”

But Wiggins is hopeful that it will spur innovation from smaller groups or individuals who might otherwise have thought their projects didn’t merit the effort or resources. “My personal hope is that the biggest impact will be the change to the economics of small-scale apps.”

“Stuff like internal tools at a company, commercial products by indie app developers, or just home-cooked apps you might make for your friends and family. In the current world, the cost to host and manage (for example) a Postgres-backed database app remains high enough to stop some of these things from being built. A local-first app can live longer and at lower cost, and that may enable a whole new class of apps to become feasible.”

Reduced Complexity vs. Cultural and Business Pushback

Brooklyn Zelenka is a researcher and builder who has previously focused on Web development and blockchain. She has served as an engineer, technical lead, and founder at organizations like Fission, Kickstarter, and MetaLab. She explains that local first could have a profound impact on:

• Reducing Architectural Complexity: Local first will streamline the entire development stack, reducing dependence on tools that specifically enable building in the Cloud
• Building and Onboarding Developer Teams: By reducing architectural complexity, local first will also lower the barrier to entry on getting new developers ramped
• Cultural Expectations for “How We’ve Always Done It”: Local first may cause cultural clashes with conservative dev teams–and massive cloud providers with a vested interest in maintaining the status quo

Local First Might Be Like the Shift to Cloud With Brooklyn Zelenka

Zelenka suggests that local first is a response to the way software has become exponentially more complicated to make. “We’ve been building apps the same way for more than 30 years. And that's led to complexity. It's very difficult to onboard new developers. You have to learn front end, back end, managing containers–all of these things.”

“So you have to build a big team of experts in many different things. Which makes it very difficult for people to own their own data, to have a customized, malleable software interface, and so on. Local first is really about radically reducing the complexity of building applications.” Additional benefits like low latency and always-on access don’t hurt either.

The researcher’s frustration with modern development crystallized in 2019 when she noticed open repositories like GitHub offered thousands of projects–but hardly any seemed to offer the ability to bring infrastructure to the commons, leaving most to reinvent the wheel. “As a developer, I've written the same apps and modules over and over again–just to deploy them in different environments.”

Researcher Brooklyn Zelenka discusses authentication systems for local-first systems at the Local First Berlin conference. Image courtesy Local First Conference

Still Being Resolved: Big World vs. Small World, BigCo vs. Small Startup

Zelenka suggests that a key question to resolve is the “big world, small world” distinction. “If I want to collaborate with 10,000 people, no problem. But to try to ingest the entire data firehose for BlueSky? I’m not going to do that on my phone–that’s going to be out on a server somewhere. I can send an email on my phone, but I won’t run a mail server on it.”

Because the field is still relatively new, conventional tooling may not have caught up with the most recent developments. “The question is: How can we still respect local-first principles for ‘big world’ things? And can we have these autonomous, or ‘higher user agency’ architectures applied to things that have to run in a more-centralized way? For example, I’m currently working on a local-first access control project, as there is no drop-in solution for that today. In cases like these with no established option, people often fall back to using a cloud server.”

For smaller orgs, local first can represent the exact kind of path-less-traveled advantage you’d expect, though even larger organizations are starting to reap the benefits. “I’ve heard that in larger organizations, people are using things like auto-merge to sync database configurations, using local first and extremely high availability to maintain consistency. A lot of the focus, especially for CRDTs and in local first, is on collaborative software because that's where all the hard problems were a couple of years ago. There's always going to be problems in that space, but as time passes, they’re getting solved.”

How Local First Development Might Look in Practice

How will local first ultimately change the way people build software? The researcher suggests that a major difference will be making network infrastructure optional–which means managing cloud payloads across different regions could simply go away. “All [your infrastructure needs] to know is: I am able to upload some bytes, and somebody else is allowed to download those bytes.”

“And if the startup that you're relying on goes under, you can just switch to another one for your sync on the backend. There's a lot of talk in the community right now about sync engines–essentially a buffer between front end and back end. We used to describe the workflow needed for software as ‘shipping your box.’”

“As an example, let’s say you were using Rails to build a React app. Previously, you’d create some dummy data in the browser, mock up what it would look like, then build a backend and serialization on both sides, including an auth login system and all of those things. And then, to ‘ship your box,’ you’d have to deploy it somewhere and have it scale, as you’d expect.”

“With local first, you’d just build a front-end app. And for that data layer, just use this library. And if you want to back it up somewhere online, once it's at the server, you're done. You don't have to touch any special code. It feels like building an iOS or Android app–where you just have data ‘as an API.’”

“You don't need to become an expert in this towering stack of technologies anymore. Literally, what you’re working on in the ‘mockup’ phase is your production app. If you want to keep working on your app and try something out, you don't have to make a copy of the entire production database. You can just use your production data because it's your data. You have a copy that's ‘as good’ as anybody else's copy.”

You don't need to become an expert in this towering stack of technologies anymore. Literally, what you’re working on in the ‘mockup’ phase is your production app.” -Brooklyn Zelenka, Researcher/Ink & Switch

Cultural and Business Challenges

While local first offers tremendous potential for individual devs, the benefits might not seem obvious, or enticing, to stubborn system administrators who “have always done it this way,” or to massive providers who make billions by hosting cloud environments. Zelenka recalls pitching to skeptical audiences: “When I started working on this in 2019, I’d be on calls pitching to VCs, and they wouldn’t believe us–even when we’d show them a demo.”

“Is local first going to work for absolutely, completely every problem? Maybe not, but saying everything has to get shoved into a traditional architecture isn’t the only way we can ever possibly write software, either. It’s like when we saw the shift to the Cloud 10 or 15 years ago, there was absolutely nothing [established] at the time.”

“For people who have expertise in cloud scaling, it’s understandable if they wouldn’t be thrilled about part of their job potentially becoming obsolete due to a generic sync server. And from a business perspective, I would say there’s an open debate on whether local first is–and this isn’t quite the right framing, I admit–a ‘product’ versus a ‘feature.’”

Zelenka also concedes there are still questions about how local first itself can be a sustainable business model. “It's very difficult to build a moat around something that also doesn’t let you hold people's data for ransom–where they can just take their data somewhere else. It's very user-friendly, but maybe not compatible with the usual SaaS business model.”

“One version might be people making local first part of a larger SaaS application, or maybe we see people going back to selling licenses. While there are people who are excited about local-first features, some of the early pioneers in the space are still trying to figure out: What's the optimal business model to succeed financially in the long term?”

Local First Changes Development From Imperative to Declarative

Matt Biilmann is the co-founder of Netlify, a leading hosting platform that pioneered modern Web architecture with the Jamstack (JavaScript, APIs, and markup). He sees local-first development paving the way for a massively multiplayer future that entails:

• Sync Engines Handling the Gory Details: As robust sync engines evolve, conflicts between builds will approach zero, paving the way for massive adoption of AI agents
• Developers Working Harmoniously with AI Agents: Web apps could become joint projects between human devs and AI agents quietly resolving issues under the hood
• Developer Experience Becoming “Declarative”: Developers will worry less about conflicts and server issues, focusing on the code in front of them at this moment

Let Agents and Sync Engines Handle the Back End with Matt Biilmann

The co-founder reflects on the evolution of Web development–and how it hasn’t gotten much easier. “It feels like we've made our tooling more complex without really changing the kind of stuff we're building. That feels a little backwards.”

The co-founder suggests the real potential of local first could be in managing the state of a codebase, even as different parties work on it simultaneously. “The reason I’m looking forward to [advancements in] local first is a different abstraction of dealing with state and data. Every time you click a button, a developer has written some code that says, ‘Let me fetch this and show it to you,’ and every time you do an update, some other developer has code that says, ‘Let's change this piece.’”

“And you start having a local-first view of all the states that get synced–it persists, and it works across many different computers working on that state in some multiplayer manner. It feels like there’s an opportunity now for an ecosystem to make it really easy to build those kinds of experiences. And if that happens, we'll see a lot more of them, and the Web will be stronger and better.”

Matt Biilmann discusses the evolution of front-end development. Image courtesy Netlify

How Local First and Sync Engines Unlock a Multiplayer AI Agent Future

Biilmann confides, “What I like most about local first is that work feels very fast and collaborative. But there’s another part of it–the multiplayer. Once you start [using it], you have to deal with issues like conflict resolution. How do we let multiple different people work on something at the same time, and show feedback, and so on?”

The co-founder suggests that while today’s Web doesn’t always require concurrent development, that’ll change. “In the next five years, it's almost certain AI agents will play a much bigger role in how applications work and how we interact with computers. It will massively drive the number of websites and Web apps that actually need some form of multiplayer.”

“Suddenly, it won’t just be about real-time collaboration between humans working around the same underlying state. It might be you and a bunch of AI agents doing stuff that needs you to be the ‘human in the loop.’ It’s another area where I think local first and the multiplayer experience are going to be much more important. And the logical architecture to address that change is local first.”

The co-founder cautions that any serious local-first architecture will need to tackle the multiplayer issue. “When you’re using a browser, you don't get to run just one version of your application, even when there’s only one user. For example, how many versions of the same Google Sheet do I have open in my browser tabs? If I do some work on one tab, then accidentally open a new browser window with the same tab, I expect the new work will be in both of them–synced and accurate.”

“Given the way the Web works, if you start doing local first, you’d better have a sync story. Otherwise, you will quickly start seeing people lose their work, just within a single tab. Which is why all apps essentially become multiplayer apps.” The co-founder notes that the core of the experience will come down to a robust sync engine.

“Most apps don’t have any kind of sync engine. That's why a lot of this movement started around research interests, for things like CRDTs. That’s the big architectural difference. Without a sync engine, building something multiplayer is very manual and hard. On the other hand, the moment you do have that kind of sync engine, multiplayer is the logical next step.”

Without a sync engine, building something multiplayer is very manual and hard. On the other hand, the moment you do have that kind of sync engine, multiplayer is the logical next step.” -Matt Biilmann, CEO and Co-Founder/Netlify

Closed-Circuit Privacy vs. Figuring Out Where Data Goes

Biilmann muses, “When you think about having a sync engine behind your website–and loading a bunch of independent states in the browser–there's still a lot of challenges for very complex apps. If you have apps built–not on top of some simple data source–but on top of different APIs and services, then how do you make a viable sync engine?”

“If we’re worried about more than just syncing my Postgres database to this other user’s view of the database–when you suddenly have a set of different microservices, with the database and the APIs and so on, things change. No one has figured out how to simplify everything into a single engine without lots of complexity yet. And the tooling is still very new.”

“There’s no simple path to ‘Here’s how you build a local-first app with great synergy and the right infrastructure and the right front-end UI architecture. We're still figuring that out as a community, I think.”

As to why local first may be having a moment now, Biilmann points to Linear, whose real-time sync engine is an example of a real-world B2B SaaS app using the kind of tech that should underpin such systems. “I think that that has been one of the catalysts for getting people to believe in this kind of thing.”

“The other thing has been that Ink & Switch has done a lot of foundational work around CRDT to make this something we can actually think about seriously–on the technical underpinnings that need to be in place. And then, as I mentioned, as we move to a world that's much more AI-based, sync engines will become a much more natural way to drive it.”

The co-founder suggests that while on-device data privacy is a nice-to-have, it’s not a driving force for innovation. “I think you still send your data somewhere. Local first is more about the actual benefits to the experience and to the kind of applications that we now get to build. And maybe then data privacy, which is an interesting story, but I've rarely seen it change people’s behavior. Whereas giving developers tools that let them build better user experiences that are faster and more interactive and richer? That's what changes developers’ behavior.”

Local First + Sync Engines + AI Agents = The Declarative Web?

Biilmann suggests that local first could mean a massively simpler future for front-end developers that doesn’t involve writing stepwise code for repeated API queries. “The way we build apps today is very imperative. We write all these sequential calls to do this, then do that. In a local-first world, you have this idea of the UI representing the state that's relevant to the user at this time.”

“When you want to write a list, you just query that internally. When you want to update, you query that update, and you assume that behind the scenes, all the magic is happening. You move from an imperative to a declarative world in terms of how you deal with the state of your code.”

“It may matter less in a world where all the changes for that state are triggered by the current user viewing the browser. But it matters more if that state can also be changed by AI agents working in the background. The more we go in that direction, the harder it will be to work imperatively with the state of your code, and the more you will want a sync engine to solve that problem for you.”

“You will have agents running in the background, running tests and reporting back in the Cloud. That will be really common. Which means that as a developer, should you write code that asks every 10 seconds: ‘What are the AI agents doing? Should I update my UI?’ No. You’ll want some mechanism where, whenever the state of your app gets updated–whether by you or an AI agent–it just shows ‘the right thing.’ That’s the declarative approach to state management I think we’ll see.”

We Need Legos, Not Silos!

Yonatan Feleke is the founder of Vella.ai with experience across the stack at LinkedIn and Qualcomm. He started working on Vella during his Harvard MBA and would later found the thriving Local First community featuring 3,000+ developers to unlock the potential to:

• Dramatically Improve Individual Experience: What if total ownership of your data translated to outcomes like context-aware identity/auth management in any app?
• Radically Simplify Modern Architecture: What if your core infrastructure was mostly just your local database, a data model, and your business logic?
• Increase Interoperability Everywhere: With slimmer infrastructure and seamless integration of local data, orgs will see collaboration opportunities up and down the stack

The Future Is a Shared Data Substrate with Yonatan Feleke (Yonz)

Yonz suggests that anyone can see the need for local first by just looking at how people have to juggle their personal data today. “Everybody's fed up. Something is ‘off.’ Yes, our passwords are in one place. But you can’t use Notion to send an email or a calendar invite if you don’t have the LinkedIn profile of the person you’re trying to reach, for instance.”

“We were promised tools that would accelerate human ingenuity–Lego blocks that would let us build anything. But we’ve ended up with entrenched silos that prevent us from achieving our objectives. That’s my starting point. To me, local first is the path to tackling the central planning problem for our digital lives.”

The founder suggests two main challenges for pure local-first implementations – storage and compute. “For local first, there are questions about–if we completely adhere to having everything on the device with the Cloud to sync it–won’t we hit limits of inference and storage, especially with terabytes of photos and video?”

Yonz points out that other than all those stored videos and photos, people don’t necessarily have a ton of personal data–the remainder could be stored on-device–for most products. More importantly, making your device the ‘system of interface’ for cloud-based services unlocks many new possibilities for interoperability, like the filesystem in Linux.

“If my device is just a ‘warm cache’ for my emails, there is no world where I can have my emails read, modified, or even turned into a CRM by another app on my device because it will only have a limited seven-day download of all my information.”

“But if I downloaded my emails locally or with higher coverage for usability, then you can imagine a CRM running from my device and operating on my data. So, extensibility and connecting silos is a big part of why I get excited about local first prioritizing devices over the Cloud as the source of truth.”

Taking on Technical Limitations

The founder is frank about current challenges, likening limitations to building in React. A Web app may be relatively easy to get to a demo-ready state, but painful re-render and complex state-transformation challenges emerge when you hit production scale that force you to deviate from a pure View(State) pattern. Similarly, local first is great if your device can handle all the information, but it will require loading a subset of the data and leveraging remote indexes and cloud GPUs for inference when you scale.

“With something like 100GB of data, depending on how aggressive you are, it can mean anywhere from 20GB to 200GB worth of indexes. Being able to do inference becomes unapproachable. We're really pushing the limits of this with my startup, Vella.”

“I’m working with all ‘local’ AI. So, zero servers, but you start needing to run heterogeneous device resources to offload heavy workloads, and that's a complicated scheduling/development problem, in addition to managing API responses and who serves them–and being able to merge all of that.”

“We have these fundamental problems in addition to how to resolve issues with conflicts and replication. I think we need more focus on these types of issues if we are ever to get to a point where local first is a sustainable, competitive architecture for building the software of the future. Today, a lot of attention is dedicated to conflict resolution for text editing and multiplayer systems.”

Yonz moderates a discussion on identity and authentication at the Local First Meetup. Image courtesy Local First Meetup.

The Future Needs More Than Just LLMs

Yonz reflects on the seeming convergence of on-device needs for LoFi and the rise of edge computing for LLMs in response to the ballooning costs of pretraining. “Everybody seems to think that LLMs will answer every need–to the point where we started trying to replace symbolic programs with LLM prompts.”

The founder suggests that putting blind faith in GenAI is as bad an idea as putting blind faith in any emerging technology. A better idea: Finding a middle ground that leverages the strengths of new tech but emphasizes results. “Here’s an example: Running a regex over a million documents is way faster than spending hundreds of milliseconds per paragraph to extract data.”

“You can have your LLM write the regex, execute it repeatedly until it fails, and then ask the LLM to write the next template. Then, you have more of a balance between speed and adaptability using the real strengths LLMs provide. You don't want to build specialized things that don't generalize well. I get excited about this because I love emergent conventions."

“We'll have these people who drive the embedded edge-device ML models while we have the OpenAIs and Claudes of the world pushing forward on global models. And in the middle, people experiment with things like structured queries, which will hopefully get us to the best outcome. The market becomes imperfect when everybody ‘goes one way’ because the last 10% is probably five times harder than the first 90%.”

Yonz muses that the growing LoFi movement “feels like there’s finally something new that can do something better. In a way, we’re all craftsmen, and it feels like most of the technology nowadays is a cabinet that doesn't have its backboard painted.” A few people following each other on Twitter became a community, which Yonz helped start in 2022 with James Pearce. Since then, the community has hosted 20+ meetups and features over 3,000 developers who are passionate about improving the status quo.

Yonz calls for a “shared data substrate” that connects storage, identity, and personalization across products. Developers could start creating software around that connected data instead of forcing users to create new accounts and start from scratch with every new service.

“In 2016, I ended up moving five times in two years–and on my journey of changing addresses and managing credit card accounts, I realized we need some kind of central planning. I would later quit my job at LinkedIn to embark on this journey to fix the macro fragmentation problem.”

“We live among this chaotic favela of products...and there's no sewer system. There's not even a single way to log in to all my applications. Naturally, I gravitated to building a password manager, but I realized we're still shuffling context every day without realizing it, whether it is copying a meeting address into Uber or searching for an attendee on LinkedIn.”

“Furthermore, we are always starting from scratch. Take, for example, when you sign up for a new streaming service, it starts from scratch trying to understand what you like–deriving context that already existed on a different streaming platform.” The founder then points out that mundane tasks like travel require complex interconnections between data across your travel services, airlines, and any tracking tools you might use.

“You just became the interface point for 150+ products. But imagine a frictionless, connected world where I am Yonatan. I have a personal data store and some authorization or authentication mechanism that allows these services to coordinate and call me a Lyft, suggest a flight, or show me profile summaries of meeting attendees.”

“When I come to your store to purchase something, I shouldn't have to have a bouncer check my credentials and fill out a form. I will just authorize you to sell to me and save my identity so you can recognize me the next time I come in. More of a ‘MetaMask’ experience – that ‘frictionless connected internet’ people used to talk about.”

“Except that everything looks like a heaping pile of trash because now you notice it–every time you copy an address and paste it from Google Maps to Uber because these two services–just as an example–don’t have a direct link. These pain points are visceral to me, and the hundreds of people I’ve spoken to as I researched my startup have validated what we’re talking about.”

To me, local first is the path to tackling the central planning problem in our digital lives.” - Yonatan Feleke, Founder/Vella.ai

Moving Forward: How to Collapse the Stack

The founder concedes that although there are still primitives to iron out, local first is paving the way for a future that dramatically streamlines the different services devs must manage. “We will have collapsed the stack into three things: Your local database, the data model (whatever you want to use with that database), and your business logic for the app.”

“Now, however, you have a front end on a website, you'll have a database API, and then you'll have a back end for a front end, and then a middle layer, and caches strewn about everywhere for the critical paths. So for a single business objective or business model to go from storage to a view, you have upwards of 12 different steps.”

“In the future, you’ll save an update and then read that data. You don't think about whether it's on a Web page or a mobile device or if it's a server. The authorization and component updates all become seamless. To distill all of that down to one simple pain point, I have a thesis that it will solve the 40%+ of engineering costs today spent shuffling Protobuf types around in big tech.”

“You have X number of microservices and X squared combinatorics of how those things can be meshed together. And then, you have yet another view where you have nested data types that do X squared times the layers you can get in. And that complexity turns into something more like ‘Save your business logic data and then read it.’”

“To clarify, microservices have a reason for existing–to decouple things and then really do those small things at scale. Having GraphQL as a wrapper in front of millions of microservices is an architecture that can unlock the benefit of consolidated business logic and microservice specialization.”

“With microservices, you can spin up Lambdas and have them service a particular endpoint that may not be needed as often. And then you can just literally break your function into services that can be turned off. Your hundred or so services break into thousands of functions that only execute when they're called.”

“That's why I'm a big fan of evolutionary convergence. There are varying needs that compete and then evolve to unlock new heights. Encapsulating a ton of complexity into a simple read-write show pattern has a lot of value, and competing needs for micro-services architectures can result in new middle-ground patterns that get us the best of both worlds.

“10 years from now, we’ll have a radical flattening of the digital landscape. The first offense was the location-based address with the IP stack. To get anything, you must first describe where you can find it. Let's say I have the same image on my laptop, Google Drive, and other places.”

“I will never be able to send a query that says, ‘Give me that picture from anywhere, like with content addressing,’ but I have to make a request for that particular thing from a particular place.” These result in more-entrenched siloes and prevent data from flowing smoothly.

“If the world gets flattened into a connected flat surface, what you will have is a singular expression of authentication with verifiable credentials or what have you, and a way to ask for the thing [which is content addressing].”

“A lot of cool things can be unlocked in this world. First, I can run my ML on all my data everywhere once I authorize it to read everything. It can connect the dots and enrich them with sensor-fusion-like patterns to enrich them even better than the sum of each singular data point.”

“And two, you can do really powerful stuff like auto-update my GitHub issue when somebody has filed a PR to fix that thing I depend on three layers down without me doing anything. It's stuff like that that gets me excited and fired up. And we are not limited by technology, just business moats that have made everyone erect rigid silos.”

More Resources

• Podcast: The Local First Podcast
• The Local First Developer Community
• Podcast: JAMstack Radio Ep. #150 with Matt Biilmann of Netlify