The data API for your client‑serverless applications

The fourth generation application model

IT has seen only three major application architectures in the last 50 years and the fourth is now upon us. All three of these architectures and their related programming models had dramatically different requirements for the underlying data infrastructure. These requirements gave rise to major new product lines, new delivery methods, and entirely new companies.


From mainframes to client-server

Mainframes and minicomputers were monolithic, with data storage, application code, and terminal services all in one box. The rise of the microprocessor and ethernet enabled lower cost computers to work together and communicate over local area networks. PC’s began to connect to servers, leveraging a new client-server programming model for applications. Client-server applications emerged with a graphical user interface coupled to a backend SQL Database (frequently Oracle or SQL Server).

Client-server applications were built very differently than monolithic applications, with the presentation code running on the client computer and business logic on the server, typically encapsulated within SQL stored procedures:

Client-server applications created a new generation of easy-to-use, graphical applications that delivered computing to hundreds of thousands of small businesses for the first time. The combination of Visual Basic client applications calling SQL Server stored procedures built the Microsoft server business and created an entire industry of software vendors and value-added resellers.

Client-server, though, quickly became legacy with the rise of the Internet and the Web.


The internet & three-tier applications

The revolution of the global Internet brought a new generation of open standard protocols and formats. These new technologies required different infrastructure. Initially, simple web servers delivered static websites. But commerce and other applications quickly drove the emergence of a new, three-tier application model:

The three-tier application model combines a web server that speaks Internet protocols with an application server for business logic and a database. The database, app server, and web server work together to create the fully-formed web page, which is then rendered in the browser on the client. In practice, client-side Javascript usually provides local client interactivity. The level of local browser interactivity has increased over time and Javascript has driven key industry standards such as REST for remote APIs and JSON for data formats.

Unlike client-server, the three-tier application model has aged quite gracefully and is now used to provide API services in addition to web pages. The evolution of a standard API interface based on REST has enabled complex business logic to be encapsulated within globally available services that are callable by any application with the appropriate security credentials.


The "Client-serverless" application model

When services are delivered as an API, are automatically scaled within a cloud, and are priced based on usage, they are known as serverless services. Customers (users of these services) don’t need to manage the server infrastructure.

Today, we find ourselves in a connected world with a variety of powerful mobile and portable computing devices. All of these devices now support compatible browsers that are capable of providing an end user experience that approaches or in some ways, exceeds the quality of a native application on that device. An example of this is Google docs, which uses the browser to provide a seamless, collaborative experience across devices.

At the same time, new SaaS applications are being reimagined as a complete set of Internet-compatible APIs that deliver an ever expanding variety of different services using usage-based pricing. Payment (Stripe), search (Algolia), communication (Twilio), logistics, order management, 3D printing, you name it, they are all becoming APIs that are callable from anywhere: other servers, mobile applications and the browser.

After a long evolution, the browser has become a ubiquitous, programmable client that lives in a globally connected world of serverless APIs. This combination of a ubiquitous client together with a sea of serverless APIs has enabled the new, client-serverless application model:

In client-serverless, the application code runs on the client and calls a wide variety of services. The client handles the presentation while the business logic is encapsulated within callable services. Native IOS and Android applications are examples of client-serverless but the browser is where the action is with Jamstack growing rapidly. As client-serverless matures, it will grow to support consumer and business applications of any size or complexity.

Client-serverless also applies to servers and microservices that are orchestrating business processes. In this case the server application or workflow engine acts as the client making calls to remote services using serverless APIs.


Jamstack & the client-serverless data API

The JAM in Jamstack stands for Javascript, APIs, and markup. In a Jamstack application, the browser markup is static and is readily accessible from a nearby CDN. The application is instantiated by Javascript within the browser and the presentation logic runs as a Javascript browser application. The client application makes calls to remote service APIs. Jamstack is an example of the client-serverless archiecture. It delivers a great experience for users anywhere and enables a highly productive developer workflow.

The Jamstack approach enables very powerful client applications to be developed. Like all applications, these apps create data that needs safe, secure, transactionally consistent database storage. But unlike three-tier, Jamstack applications require a secure database that is available anywhere on the Internet. Existing SQL and NoSQL databases are all built to sit behind an app server so they are not directly accessible to Jamstack clients. No existing database meets the requirements needed by this new generation of client-serverless applications.

Jamstack requires a database that was built for the client-serverless world. In a sea of serverless APIs, Jamstack is missing the client-serverless data API.


Why Fauna?

Fauna is unlike any other data management layer. Fauna was designed to provide secure, anywhere access database services to any client. It delivers strictly serialized consistency, the highest level of transactional consistency to ensure application correctness and it does this very efficiently on a global basis using a state of the art optimized algorithm inspired by Calvin.

Similar to client-server stored procedures, business logic using Fauna are performed by functions within the database. Fauna UDFs replace stored procedures and while Fauna is a relational database, it doesn’t use SQL. Instead, it exposes a flexible document model that is appropriate for Javascript developers and it uses the industry-standard, GraphQL API to efficiently return data.

Serverless APIs are redefining what is possible in today’s world. These possibilities are accessible to businesses modernizing their current systems as well as those building completely new client-serverless applications. For example, Nextdoor and Hannon Hill are using serverless backends to scale their existing infrastructure for global reach. Boutique studios such as Matter Supply, Bejamas as well as startups such as Faros are building entirely new experiences with the serverless and Jamstack ecosystem.

Every application architecture has spawned new databases that have enabled developers to build applications that were not possible before and given rise to new products, companies, and delivery models.

Fauna is the data API that will provide developers the data layer they need for this whole new world of anywhere access, client-serverless applications.