<story><title>The Future of the Web Is on the Edge</title><url>https://deno.com/blog/the-future-of-web-is-on-the-edge</url></story><parent_chain><item><author>lewisl9029</author><text>The architecture I eventually ended up with for my product (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;reflame.app&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;reflame.app&lt;/a&gt;) involves:&lt;p&gt;1. A strongly consistent globally replicated DB for most data that needs fast reads (&amp;lt;100ms) but not necessarily fast writes (&amp;gt;200ms). I&amp;#x27;ve been using Fauna, but there are other options too such as CockroachDB and Spanner, and more in the works.&lt;p&gt;2. An eventually consistent globally replicated DB for the subset of data that does also need fast writes. I eventually settled on Dynamo for this, but there are even more options here.&lt;p&gt;I think for all but the most latency-sensitive products, 1. will be all they need. IMHO the strongly consistently replicated database is a strictly superior product compared to databases that are single-region by default and only support replication through read-replicas.&lt;p&gt;In a read-replica system, we have to account for stale reads due to replication delays, and redirect writes to the primary, resulting in inconsistent latencies across regions. This is an extremely expensive complexity tax that will significantly increase the cognitive load on every engineer, lead to a ton of bugs around stale reads, and cause edge case handling code to seep into every corner of our codebase.&lt;p&gt;Strongly consistently replicated databases on the other hand, offer the exact same mental model as a database that lives in a single region with a single source of truth, while offering consistent, fast, up-to-date reads everywhere, at the cost of consistently slower writes everywhere. I actually consider the consistently slower writes also a benefit since it doesn&amp;#x27;t allow us to fool ourselves into thinking our app is fast for everybody, when it&amp;#x27;s only fast for us because we placed the primary db right next to us, and forces us to actually solve for the higher write latency using other technologies if our use case truly requires it (see 2.).&lt;p&gt;In the super long term, I don&amp;#x27;t think the future is on what&amp;#x27;s currently referred to as &amp;quot;the edge&amp;quot;, as this &amp;quot;edge&amp;quot; doesn&amp;#x27;t extend nearly far enough. The true edge is client devices: reading from and writing to client devices is the only way to truly eliminate speed-of-light induced latency.&lt;p&gt;For a long time, most truly client-first apps have been relegated to single-user experiences due to how most popular client-first architectures have not had an answer for collaboration and authorization, but with this new wave of client-first architectures solving for collaboration and authorization with client-side reads and optimistic client-side writes with server-side validation (see Replicache), I&amp;#x27;ve never been more optimistic about the future (an open source alternative to Replicache would do wonders to accelerate us to this future. clientdb looks promising).</text></item><item><author>jensneuse</author><text>Instead of &amp;quot;edge&amp;quot;, a lot of websites should just have 3 locations (us,eu,apac) with a non geo replicated Serverless database in each region. At least that&amp;#x27;s what we&amp;#x27;re building at WunderGraph (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;wundergraph.com&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;wundergraph.com&amp;#x2F;&lt;/a&gt;). Edge sounds super cool, but if you take state and consistency into consideration, you just can&amp;#x27;t have servers across the globe that also replicate their state consistently with low latency. TTFB doesn&amp;#x27;t matter as much as correctness. And if stale content is acceptable, then we can also just push it to a CDN. Most importantly, you&amp;#x27;d want to have low latency between server and storage. So if your servers are on the &amp;quot;edge&amp;quot;, they are close to the user, but (randomly) further away from the database. Durable objcets might solve this, but they are nowhere near a postgres database. I think the &amp;quot;edge&amp;quot; is good for some stateless use cases, like validating auth and inputs, etc., but it won&amp;#x27;t make &amp;quot;boring&amp;quot; services, even serverless in &amp;quot;non-edge&amp;quot; Locations obsolete. You can see this on Vercel. Serverless for functions, server side rendering, etc. and cloudflare workers for edge middleware. But they explicitly say that your serverless functions should be close to a database if you&amp;#x27;re using one.</text></item></parent_chain><comment><author>ihattendorf</author><text>FYI your light&amp;#x2F;dark mode icon is off-center for me. Fedora 36&amp;#x2F;Firefox.&lt;p&gt;Also at some window heights, the &amp;quot;Deployed with Reflame in x ms&amp;quot; box obscures the &amp;quot;Have questions? Let&amp;#x27;s chat!&amp;quot; text without generating a scrollbar.</text></comment>
<story><title>The Future of the Web Is on the Edge</title><url>https://deno.com/blog/the-future-of-web-is-on-the-edge</url></story><parent_chain><item><author>lewisl9029</author><text>The architecture I eventually ended up with for my product (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;reflame.app&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;reflame.app&lt;/a&gt;) involves:&lt;p&gt;1. A strongly consistent globally replicated DB for most data that needs fast reads (&amp;lt;100ms) but not necessarily fast writes (&amp;gt;200ms). I&amp;#x27;ve been using Fauna, but there are other options too such as CockroachDB and Spanner, and more in the works.&lt;p&gt;2. An eventually consistent globally replicated DB for the subset of data that does also need fast writes. I eventually settled on Dynamo for this, but there are even more options here.&lt;p&gt;I think for all but the most latency-sensitive products, 1. will be all they need. IMHO the strongly consistently replicated database is a strictly superior product compared to databases that are single-region by default and only support replication through read-replicas.&lt;p&gt;In a read-replica system, we have to account for stale reads due to replication delays, and redirect writes to the primary, resulting in inconsistent latencies across regions. This is an extremely expensive complexity tax that will significantly increase the cognitive load on every engineer, lead to a ton of bugs around stale reads, and cause edge case handling code to seep into every corner of our codebase.&lt;p&gt;Strongly consistently replicated databases on the other hand, offer the exact same mental model as a database that lives in a single region with a single source of truth, while offering consistent, fast, up-to-date reads everywhere, at the cost of consistently slower writes everywhere. I actually consider the consistently slower writes also a benefit since it doesn&amp;#x27;t allow us to fool ourselves into thinking our app is fast for everybody, when it&amp;#x27;s only fast for us because we placed the primary db right next to us, and forces us to actually solve for the higher write latency using other technologies if our use case truly requires it (see 2.).&lt;p&gt;In the super long term, I don&amp;#x27;t think the future is on what&amp;#x27;s currently referred to as &amp;quot;the edge&amp;quot;, as this &amp;quot;edge&amp;quot; doesn&amp;#x27;t extend nearly far enough. The true edge is client devices: reading from and writing to client devices is the only way to truly eliminate speed-of-light induced latency.&lt;p&gt;For a long time, most truly client-first apps have been relegated to single-user experiences due to how most popular client-first architectures have not had an answer for collaboration and authorization, but with this new wave of client-first architectures solving for collaboration and authorization with client-side reads and optimistic client-side writes with server-side validation (see Replicache), I&amp;#x27;ve never been more optimistic about the future (an open source alternative to Replicache would do wonders to accelerate us to this future. clientdb looks promising).</text></item><item><author>jensneuse</author><text>Instead of &amp;quot;edge&amp;quot;, a lot of websites should just have 3 locations (us,eu,apac) with a non geo replicated Serverless database in each region. At least that&amp;#x27;s what we&amp;#x27;re building at WunderGraph (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;wundergraph.com&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;wundergraph.com&amp;#x2F;&lt;/a&gt;). Edge sounds super cool, but if you take state and consistency into consideration, you just can&amp;#x27;t have servers across the globe that also replicate their state consistently with low latency. TTFB doesn&amp;#x27;t matter as much as correctness. And if stale content is acceptable, then we can also just push it to a CDN. Most importantly, you&amp;#x27;d want to have low latency between server and storage. So if your servers are on the &amp;quot;edge&amp;quot;, they are close to the user, but (randomly) further away from the database. Durable objcets might solve this, but they are nowhere near a postgres database. I think the &amp;quot;edge&amp;quot; is good for some stateless use cases, like validating auth and inputs, etc., but it won&amp;#x27;t make &amp;quot;boring&amp;quot; services, even serverless in &amp;quot;non-edge&amp;quot; Locations obsolete. You can see this on Vercel. Serverless for functions, server side rendering, etc. and cloudflare workers for edge middleware. But they explicitly say that your serverless functions should be close to a database if you&amp;#x27;re using one.</text></item></parent_chain><comment><author>anonymousDan</author><text>Good post. Do you have any resources describing the &amp;#x27;new wave of client-first architectures&amp;#x27; you mention? I&amp;#x27;m struggling to understand how you can do client-side authorization securely.</text></comment>