Scaling a Data-driven Next.JS and Prisma App Globally With Polyscale

When it comes to page speed on the web, every second – every millisecond even – counts. The faster that pages are served, the happier your users are and the more likely they are to be kept engaged. Server-side rendering that relies on dynamic database queries can only be as fast as the slowest query allows. Caching is often introduced to speed up that database bottleneck, but caching is a complex highly technical software engineering problem.

PolyScale is a no-code, plug and play database caching service that gives all the benefits of a database cache without any changes to your existing codebase or database architecture.

To demonstrate the efficacy of PolyScale in a real world application environment we've created a real-estate web application powered by Next.JS, Prisma , backed by a Postgres database and deployed to Heroku.

If you are not familiar with this stack, Next.JS allows developers to build React applications, providing many features out of the box such as static and server rendering, code-splitting and TypeScript support. Prisma is a Node.js and TypeScript ORM which makes database access and management easy by utilizing a schema to declaratively define your application’s models and their relations and auto-generating a client from said schema.

The application

The application reflects the architecture and configuration common to web applications the world over. A front page presents an overview of the catalog (in this case of real estate properties) and each property has its own details page.

The details page for each property is rendered on the application server as it is requested. Rendering the page requires five queries to the database. The first query fetches the property, the second computes the median price for similar properties in the same region, the third fetches the last sale of the property, the fourth the last sale of similar properties in the region and the last simply fetches a list of similar properties.

These queries reflect the range of demand put on the database server by a typical web application. In total, the queries required to render the details page constitute substantial load on the database. It’s an ideal candidate for data caching and an ideal test to demonstrate the efficacy of PolyScale.

Solving cross-region latency

The application server and the database are hosted in the US, specifically on Heroku’s us-east-1 region. For users in the US, a single details page load (HTTP GET) completes in around 400ms. This constitutes the baseline level of performance.

Let’s now assume our real-estate application wishes to expand to support European users. With our current architecture, this is where we start to see geographical latency challenges emerge. Making the same request from the EU the average execution time more than doubles to 830ms. That’s a 105% increase.

Scale the application tier

A logical architecture change to attempt to mitigate this is to add a dedicated application instance in the Heroku EU region (eu-west-1 – Ireland). This lowers the page load time (HTTP GET request) to 682ms as the page load computation is decoupled and the static asset serving is done closer to the EU users.

Below we plot the execution times for each of these three scenarios. These values are averages of the execution times of 300 consecutive requests.

The reason users in the EU experience such drastically different page load times is because the database server is still located in the US. Duplicating the application server in the EU does reduce the http latency for the EU users, but because the queries to the database still must travel around the world, EU users are served much slower than US customers (279ms slower).

A common architectural solution to this problem is to replicate the database server as well as the application server or, develop application level caching with databases like Redis. However, that brings with it significant cost and complexity.

Scale the data tier

Alternatively, PolyScale can be used to cache the data locally to the region. PolyScale is a no-code, plug and play database cache as a service that can be implemented in minutes by simply updating the PostgreSQL connection string used by Prisma. PolyScale will then cache the data at the nearest Point of Presence (PoP) dramatically reducing the latency between EU and US.

Connecting the EU application server to the database through PolyScale’s EU PoP reduces the page load time to under 100ms. With the introduction of PolyScale, EU customers are served 4x faster than the original baseline US customers. All this benefit is had without any changes to the codebase or database architecture.

Solving database concurrency

PolyScale’s caching has two benefits, reducing geographic latency and increasing database read performance and hence concurrency. Here we demonstrate the latter by introducing our application to an increasing number of concurrent users. We alter the configuration used above by utilizing a PolyScale PoP for connections within the US region.

Without PolyScale, as the number of concurrent users increases execution time rises rapidly. This is because the database server becomes overburdened. With PolyScale, the execution times rise much more gradually. For the same level of execution time, the PolyScale based architecture supports 5x as many concurrent users.

The same dramatic effects are seen with our EU based application server connected to the PolyScale EU PoP.

Conclusions

PolyScale accelerates data-driven apps in two ways: it lowers geographic latency by using its global network of Points of Presence (PoP’s). Secondly, it accelerates query performance and concurrency for database reads.

PolyScale can be implemented in minutes without writing code and the platform AI will continuously monitor all database traffic providing insight and recommendations on what to cache and for how long.

The source code for the demo application can be found here.

Ready to try PolyScale.ai? Signup for a free account here (no credit card required) or try out the live interactive demo playground.

Miscellaneous:

• The example database schema can be found here.
• The client load test application was deployed and executed via Heroku.
• PolyScale's global network is external to Heroku and hence accurately portrays network access from an external client source.
• The Heroku Postgres database instance used in these tests can support 20 concurrent connections and Prisma was configured to fully utilize them all.
• Heroku has a default connection timeout of 30 seconds