Qwik

Introducing Qwik City Server Functions

February 15, 2023

Written By Manu Mtz.-Almeida

Today we are thrilled to show what the Qwik Core Team has been working on:

Data Loaders: reactive low latency data loading in the server.
Form Actions: run server code on user interaction

The Server vs. Browser Duality

One of the core ideas of Qwik is to run your app on the server and continue its execution on the browser when the user interacts. While Qwik was designed from the ground up to be a Server-Side Rendered (SSR) and Single-Page Application (SPA) technology, it doesn't distinguish between server and browser, ie, it treats all code equally, all code might run in the server or the browser.

That's where Qwik City enters the scene, a meta framework built on top of the resumability capabilities of Qwik to bring routing and data-fetching patterns. Qwik City is to Qwik, what NextJS is to React, Sveltekit is to Svelte or Solid Start is to Solid.

Data fetching ecosystem

In this great tweet from Theo (CEO of ping.gg), he points out 3 big camps of solutions for the server/client communication problem:

Different teams/companies: GraphQL / REST
Same team: tRPC / GraphQL
Same team using typescript: tRPC / Qwik City

tRPC hits the sweet spot for most web apps! This is exactly the problem that Qwik City server functions solve.

In the context of Qwik City, the problem becomes a little bit more complicated than hitting an HTTP endpoint, reactivity, validation, streaming, avoiding request waterfalls, caching, and the list goes on. That’s why this is a problem that’s worth solving at the meta-framework level!

Introducing Qwik `loader$()`

Qwik's Data Loader solves the issue of quickly fetching data to be displayed in the HTML. It helps to ensure that the data is available in a timely manner. This helps to improve the user experience and reduce loading times.

Qwik City goes a long way to execute all relevant loaders as soon as possible and in parallel to keep latency as low as possible, in addition, loaders are connected to the reactivity system of Qwik powered by signals, so new data will automatically and efficiently update all parts of the app that depend on it.

Thanks to defer, loaders can return a promise and start streaming HTML before completion, meaning that we can render and send parts of the site before the loader has resolved. This way, loaders that might take a longer time to resolve will not block the whole site.

Data loaders are equivalent to Next's getServerProps(), Remix loaders, SvelteKit’s load function and SolidStart’s createResource function. They are server-only routines that are executed as soon as possible to reduce latency and provide data to the later rendering process.

However, Qwik is able to take these concepts even further and loader$() comes with some advantages!

Zero-effort type safety

Server loaders are just exported functions that can be consumed, imported, and bring all the type information without any extra errors or manual, error-prone typing.

In other solutions, developers are required to manually specify the types, because the loaders and the components are connected through some internal magic that the type system does not understand, for example:

With Qwik, the type information naturally flows because the loaders references are implicitly imported, allowing TS to do its job for you:

Colocation

Loaders can be located anywhere and referenced and imported from any file, bringing with them their types and data efficiently.

Low-level HTTP request access

Loaders are internally implemented as middleware. This means that loaders get full access to the Request and Response, allowing them to take control of the request header, status, and HTTP body.

Even Qwiks streaming SSR is implemented as a middleware, so even a custom error middleware can capture a crash coming from a component.

Introducing Qwik `action$()`

Form Actions solve the problem of executing code in the server when there is some user interaction such as: submitting a form, signing in, or adding an item to the cart.