When Worlds Collide: Frontend vs Database

Rate this content

Classic frontend vs backend API design conflicts are becoming a headache of the past with serverless and Jamstack architectures and tools; frontend developers are building the full stack. But this poses a new problem: “What database? Who cares about the database?” This talk will help you with the questions you should ask of the database for your next side project...and a place to begin your journey in database internals.

8 min
18 Jun, 2021

AI Generated Video Summary

Tyler Hannon discusses the importance of choosing the right database and explains the ACID acronym, which stands for Atomicity, Consistency, Isolation, and Durability. He also highlights the challenges and benefits of distributed transactions in Fullstack applications. Various approaches to solving database challenges are mentioned, with a focus on FAUNA and its CALVIN protocol. The goal is to have a fast, reliable, and serverless database that meets specific requirements.

1. Choosing the Right Database and Understanding ACID

Short description:

In this talk, Tyler Hannon discusses the importance of choosing the right database for your application. He introduces the ACID acronym, which stands for Atomicity, Consistency, Isolation, and Durability. Tyler explains each component of ACID and its significance in maintaining data integrity and reliability. He also highlights the challenges and benefits of distributed transactions in modern Fullstack applications.

Excellent, so thanks so much for joining me today. My name is Tyler Hannon, and I look after community, and support, and customer success at Fauna. My background is actually in distributed systems and databases, so an event like JS Nation is not where I am most comfortable, but similarly, my expertise is perhaps where you're not most comfortable. And that's why I titled this talk When Worlds Collide.

We are in a sociological shift in the Fullstack world, where a web server was adjacent to the database, to this new world with global clients and global APIs, where latency and consistency at the edge is critical. But unfortunately, we're all being marketed at. So when you think about your application, the reality is we just want to dump data somewhere, and we want to read data from somewhere. And I guarantee that either in a diagram you have on your own or somewhere inside of the company you work for, there is this 1980s looking bit of clip art that represents a database with the notes, insert the logo here. And that's what I want to talk about today. What is important to consider when you choose what logo to insert into that database diagram?

We know that the database is often a bottleneck, and just like so many database vendors are talking now, we also know that distributed transactions are the solutions, but distributed, what even now? And what is this thing, ACID, that database vendors keep talking about? It is not related to the thing you can find here in the city that I'm from of Amsterdam. It's something entirely different. In fact, it's an acronym and acronyms are weird. So I thought I would take a little bit of time to walk through this ACID acronym with you. So the first is A, atomic or atomicity. Basically what it's saying is that all changes to the data are performed as if they were a single operation. That is like everything happens or nothing happens. The canonical example for this kind of workflow is financial services. If I am debiting an account that debit must be made successfully and the credit must be made successfully but that's a lot of words. So I like to think of the atomic property as all or nothing. There's C for consistent. Data is in a consistent state when the transaction starts and when the transaction ends. Again, to use our canonical example, this would be in an application that's transferring funds from one place to another. This property ensures that the total value combined is in the same state both before and after the transaction. It is valid before, it is valid after. I is for isolation in that the intermediate state of a transaction is invisible to others. Basically, things happen one at a time or in parallel, but regardless, the result is the same, and D is durable, or durability. When the transaction is complete, the changes are persisted and are not undone. This is probably what you are most familiar with. Once it's complete, it survives in outage. Now, there are a wide variety of database vendors that talk about distributed transactions.

2. Choosing the Right Database Approach

Short description:

There are various approaches to solving database challenges, including Mongo, Dynamo, Firebase, Cassandra, and FAUNA. FAUNA's approach is based on the CALVIN distributed transaction and data replication protocol. CALVIN ensures data integrity and provides global replication, allowing for temporal capabilities and integration with multiple cloud vendors. For those interested in learning more, resources like CMU Database Group YouTube and jepson.io offer valuable insights. Ultimately, the goal is to have a fast, reliable, and serverless database that meets your specific requirements. Try FAUNA for free and reach out for any questions or support.

There's many approaches to how to solve this. There's Mongo's approach and Dynamo's approach, and what Firebase talks about, and what Cassandra talk about. What we at FAUNA talk about as well. Our approach, for what it's worth, is based in a distributed transaction and data replication protocol called CALVIN. This is the title of the paper. CALVIN Fast Distributed Transactions for Partitioned Database Systems. If you have any interest, I encourage you to read about it. Because ultimately, understanding how your requirements are met are important in ensuring that they are met completely.

In simple though, it's a multi-document transaction, and it looks a little bit like this. I have built a compelling, awesome app in some flavor of JavaScript using the frameworks and tools that I trust, be that React, or Next, or whatever. My app has a piece of data, and my friendly little helper in my app goes to the database and says, hey, here's data. And that data falls into the transaction log. That transaction log is then replicated to another site globally. The replication is acknowledged. There's a whole bunch of checks, and maths, and confusing things that go into place. And then the data is written. As that data is replicated globally, because it's in the transaction log, it is returned to the application as complete. This also allows for some really cool capabilities around temporality, knowing what happened at what point in time. And it allows us to reach out to a variety of cloud vendors in a variety of regions around the world, some of which are available today and some of which will be available in the future.

But your journey is just beginning. I encourage you to look at the CMU Database Group YouTube if you're interested in how these sorts of things work. To look at jepson.io and the amazing talks that Kyle Kingsbury has done and the work that he has done in breaking distributed databases and making us as an industry better for it. But at its simplest, you just wanna dump your data somewhere. You just wanna read what you wrote. You just want it to be fast everywhere. You have described a geographically redundant distributed system. And because you don't want to be an operator, you've described a database that's built for serverless. You just want it to work. We want that for you to try it. It's free, there's a free tier. It's great. Also feel free to hit me up. I'm at Tyler Hannon. You can also find us at at fauna. I am marketing to you. You are being marketed to all the time. Know that your journey of understanding about distributed database fundamentals begins with knowing what you care about. Thank you so much, and I'll be in chat if people have questions.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TypeScript Congress 2022TypeScript Congress 2022
27 min
TypeScript and the Database: Who Owns the Types?
We all love writing types in TypeScript, but we often find ourselves having to write types in another language as well: SQL. This talk will present the choose-your-own-adventure story that you face when combining TypeScript and SQL and will walk you through the tradeoffs between the various options. Combined poorly, TypeScript and SQL can be duplicative and a source of headaches, but done well they can complement one another by addressing each other's weaknesses.
JSNation 2023JSNation 2023
29 min
I Would Never Use an ORM
What's an ORM? An Object-Relational Mapping tool (ORM) is a library to map a SQL table to a Class. In most cases, ORMs force the users to structure their code to have Model objects that include both data access and business logic.
Once upon a time, I did several projects using ORMs as I followed the common belief that they would simplify the development and maintenance of projects. I was wrong. ORMs are often a hurdle to overcome for the most complex part of a project.
As the next stop of my journey, I recommended people use the native languages of their databases, e.g., SQL. This works great for the most part, but it creates quite a struggle: there is a lot of boilerplate code to write that can be pretty tedious. I was wrong, again.
Today I'm presenting you Platformatic DB.
Node Congress 2022Node Congress 2022
31 min
Database Access on the Edge with Cloudflare Workers & Prisma
Edge functions are pushing the limit of serverless computing – but with new tools, come new challenges. Due to their limitations, edge functions don't allow talking to popular databases like PostgreSQL and MySQL. In this talk, you will learn how you can connect and interact with your database from Cloudflare Workers using the Prisma Data Proxy.
You can check the slides for Alex's talk here. 
React Summit 2022React Summit 2022
22 min
A Frontend Developer’s Guide to Web3
There is a lot of hype and interest around diving into the Web3 space, and it can be hard to manage the information overload and the emphasis on learning new languages to work on smart contracts. Many developers in the frontend space ask, “How much of this new information do I need to transition into web3?” The truth is as a React developer, the skills I know are essential in web3. Let’s add some context around how to leverage those existing skills to succeed in this new space.
In this talk, we’re going to explore how to build the correct context and the technologies to understand to help you dive into web3 as a front-end developer. We’ll go over popular packages like Ethers, which can be used in React applications to interact with wallets and existing smart contracts. We will also explore how you can leverage your Javascript skills to build full-stack dApps using managed services like Moralis and Thirdweb.
Let’s demystify some of the concepts in web3 and leverage our existing skills to start building.
Remix Conf Europe 2022Remix Conf Europe 2022
41 min
Remix Persistence With DynamoDB
Remix is the best React framework for working with the second most important feature of the web: forms. (Anchors are more important.) But building forms is the fun part: the tricky part is what happens when a web consumer submits a form! Not the client side validation logic but the brass tacks backend logic for creating, reading, updating, destroying, and listing records in a durable database (CRUDL). Databases can be intimidating. Which one to choose? What are the tradeoffs? How do I model data for fast queries? In this talk, we'll learn about the incredibly powerful AWS DynamoDB. Dynamo promises single-digit millisecond latency no matter how much data you have stored, scaling is completely transparent, and it comes with a generous free tier. Dynamo is a different level of database but it does not have to be intimidating.

Workshops on related topic

Remix Conf Europe 2022Remix Conf Europe 2022
195 min
How to Solve Real-World Problems with Remix
Featured Workshop
- Errors? How to render and log your server and client errorsa - When to return errors vs throwb - Setup logging service like Sentry, LogRocket, and Bugsnag- Forms? How to validate and handle multi-page formsa - Use zod to validate form data in your actionb - Step through multi-page forms without losing data- Stuck? How to patch bugs or missing features in Remix so you can move ona - Use patch-package to quickly fix your Remix installb - Show tool for managing multiple patches and cherry-pick open PRs- Users? How to handle multi-tenant apps with Prismaa - Determine tenant by host or by userb - Multiple database or single database/multiple schemasc - Ensures tenant data always separate from others
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
In this workshop we'll dig deeper into data modeling. We'll start with a discussion about various database types and how they map to GraphQL. Once that groundwork is laid out, the focus will shift to specific types of databases and how to build data models that work best for GraphQL within various scenarios.
Table of contentsPart 1 - Hour 1      a. Relational Database Data Modeling      b. Comparing Relational and NoSQL Databases      c. GraphQL with the Database in mindPart 2 - Hour 2      a. Designing Relational Data Models      b. Relationship, Building MultijoinsTables      c. GraphQL & Relational Data Modeling Query Complexities
Prerequisites      a. Data modeling tool. The trainer will be using dbdiagram      b. Postgres, albeit no need to install this locally, as I'll be using a Postgres Dicker image, from Docker Hub for all examples      c. Hasura
Node Congress 2023Node Congress 2023
33 min
Scaling up Your Database With ReadySet
The database can be one of the hardest parts of a web app to scale. Many projects end up using ad-hoc caching systems that are complex, error-prone, and expensive to build. What if you could drop in a ready-built caching system to enable better throughput and latency with no code changes to your application?
Join developers Aspen Smith and Nick Marino to see how you can change one line of config in your app and use ReadySet to scale up your query performance by orders of magnitude today.
GraphQL Galaxy 2021GraphQL Galaxy 2021
143 min
Building a GraphQL-native serverless backend with Fauna
Welcome to Fauna! This workshop helps GraphQL developers build performant applications with Fauna that scale to any size userbase. You start with the basics, using only the GraphQL playground in the Fauna dashboard, then build a complete full-stack application with Next.js, adding functionality as you go along.

In the first section, Getting started with Fauna, you learn how Fauna automatically creates queries, mutations, and other resources based on your GraphQL schema. You learn how to accomplish common tasks with GraphQL, how to use the Fauna Query Language (FQL) to perform more advanced tasks.

In the second section, Building with Fauna, you learn how Fauna automatically creates queries, mutations, and other resources based on your GraphQL schema. You learn how to accomplish common tasks with GraphQL, how to use the Fauna Query Language (FQL) to perform more advanced tasks.
Remix Conf Europe 2022Remix Conf Europe 2022
156 min
Building a Realtime App with Remix and Supabase
Supabase and Remix make building fullstack apps easy. In this workshop, we are going to learn how to use Supabase to implement authentication and authorization into a realtime Remix application. Join Jon Meyers as he steps through building this app from scratch and demonstrating how you can harness the power of relational databases!