DevOps

Vercel vs. VPS - What's the drama, and which one should you choose?

May 8, 2024

8 min read

Vercel vs. VPS - What's the drama, and which one should you choose?

Vercel recently announced an update to their pricing. For some users, that meant a significant increase in costs, which has led to some discussions about the costs of using cloud providers like Vercel, with a few suggesting that a VPS is a far superior and cost-effective solution.

Does it make sense to move your popular app to a VPS and save hundreds of dollars? As you might have guessed, the issue is far more nuanced than some tweets suggest. Let's break it down.

Integrations

Let's talk about the elephant in the room first. Vercel is tailored explicitly for Next.js, providing tooling for conformance checks, continuous deployment, branch previews, and more. All of that works out of the box, and if you were to figure all of that out on your own, you'd be spending a lot of time and money on it, exposing yourself to potential bugs, problems, and disturbances in your workflow.

If you're a one-person startup, you may get away with setting up a simple CI/CD pipeline on a VPS, but as your team grows, you'll need to invest more time and money into maintaining it. And that's not even considering the time you'll spend onboarding new team members and teaching them how to use your custom setup.

That being said, some tools can make things easier for you and standardize the process. For example, coolify does a great job of providing a simple and easy-to-use interface for deploying Next.js apps to a VPS. You could also deploy a Docker container with all the necessary tools and configurations, but that's another can of worms. There’s also OpenNext adapter that lets you deploy across different environments, such as AWS. While that takes care of the deployment part, it doesn't solve the potential need for other integrations like conformance checks, branch previews, etc.

Scaling and Performance

Scaling is sometimes overrated in software engineering. Especially at the beginning of a greenfield project, you're better off focusing on building a great product and getting users than worrying about scaling. That said, it's essential to have a plan for scaling when the time comes, not to mention projects that are already popular and are considering moving to a VPS.

I'm not saying you can't successfully run a popular high-traffic project built in Laravel from a Debian server in your basement. But I'm also not suggesting that you should optimize your hosting costs at the expense of investing precious time and energy into building and configuring infrastructure that could be better spent on building your product, especially given the fact that most cloud providers offer a free tier that can handle a decent amount of traffic.

And there is one more thing to consider. Vercel has a global network of edge nodes that can cache your content and serve it to users from the nearest location, which can significantly improve your app's performance. If your app is targeted at a global audience, serving it from one server located in a single region may provide a suboptimal experience for users in other areas.

Edge Nodes

Speaking of edge nodes and Vercel, there has been a pretty significant announcement made by Vercel recently. They have moved away from edge rendering back to Node.js. The reason is that while they initially thought it may be worth the trade-off, having your compute resources far away from your database makes the app slower. Furthermore, the cost benefits of edge rendering are less significant than they initially thought.

That doesn't mean they moved away from edge nodes completely. Static assets and the essential HTML and CSS are still served by the edge nodes. With networks getting fast and Node.js more performant, however, the argument for having a VPS with a CDN instead of a cloud provider like Vercel becomes more compelling.

Skill Requirements

Running a VPS requires a certain level of technical expertise. You must know how to set up and configure a server, install and configure software, manage security, monitor performance, and troubleshoot problems. If you're uncomfortable with these tasks, you may spend a lot of time learning and troubleshooting. While learning new things is great, it's not always the best use of your time, especially if you're trying to build a product.

Part of the cost of using a cloud provider like Vercel is that they take care of all the technical details so you can focus on building your product. Suppose you're not comfortable with managing servers. In that case, it is worth paying extra for the convenience of not having to worry about it while benefiting from a global network of edge nodes and integrations that can save you time and money in the long run.

If you're a developer who enjoys tinkering with servers and learning new things, running a VPS can be a fun and rewarding experience. Similarly, running a VPS may be a good option for you if you're a small team with a dedicated DevOps person who can handle all the technical details. But suppose you're a solo founder or a big company with an abundant budget. In that case, you may be better off using a cloud provider like Vercel that can save you time and money in the long run, allowing you to validate PRs in real-time and comment on a build preview in the process.

Security

A considerable concern when running a VPS is security. You must keep your server updated with security patches, configure firewalls, monitor logs for suspicious activity, and take other steps to protect your server from attacks. There are a lot of bots out there scanning the internet for vulnerable servers, and if you're not careful, you could end up with a compromised server that's being used to send spam, mine cryptocurrency, or launch DDoS attacks. Most cloud providers take care of these things for you, so you don't have to worry about them.

Speaking of DDoS attacks, cloud providers usually have built-in DDoS protection that can help mitigate the impact of an attack. If you're running a VPS, you'll need to set up your own DDoS protection, which can be a complex and expensive process, or set up a CloudFlare in front of your server, effectively giving into a cloud provider anyway. That being said, I have read a few horror stories about landing an enormous bill from a cloud provider after a DDoS attack, so it's not all sunshine and rainbows.

However, if you opt for a cloud hosting solution such as Vercel and unfortunately get attacked, remember they can be chill about it and refund some of the costs. Be aware of the possibility of a DDoS attack, though, and set up limits and alerts to prevent it from happening in the first place.

Tech Stack Flexibility

While you don't have to worry about keeping your server up to date when using a cloud provider, it is unfortunate that most cloud providers are usually late in supporting the newest Node.js versions. Despite Node.js 20 being the latest LTS version, some cloud providers' features still don't support it.

If you plan to use bleeding-edge technologies or have specific requirements that cloud providers don't support, you may be better off running a VPS.

Cost

Finally, let's talk about cost. Running a VPS can be cheaper than using a cloud provider like Vercel, especially if you have a high-traffic app generating a lot of revenue. However, you need to consider the hidden costs of running a VPS, such as the time and money you'll spend on maintaining it, the cost of setting up and configuring a server, the cost of monitoring and troubleshooting problems, and the cost of scaling and performance optimization.

If we take a model app that transfers around 1.5 TB of data per month, does a bit of computation, and we apply the new Vercel pricing, it could look something like this:

Base Plan Cost: $20 per month
Additional Fast Data Transfer: 500 GB x $0.15/GB = $75 (1 TB included in the base plan)
Additional Fast Origin Transfer: 50 GB x $0.06/GB = $3 (100 GB included in the base plan)
Additional Edge Requests: 2 million x $2/million = $4 (10 million included in the base plan)
Additional Function Execution Time: 200 GB-hours x $0.18/GB-hour = $36 (1,000 GB-hours included in the base plan)

That would bring our total cost to $138 per month, assuming you pay for only one seat.

If we decided to run a VPS instead, we would need something with at least 4 GB RAM, 2 vCPUs, and 80 GB SSD storage. A VPS with those specs would cost around $20 per month. You would also need to add the cost of a CDN, which would amount to $20 per month if you chose the CloudFlare Pro plan. That would bring our total cost to $40 per month.

In this case, running a VPS would be significantly cheaper than using Vercel. However, this assumes that you know how much your app will scale in advance or that you're willing to go through the hassle of migrating your application to a larger server when the time comes.

The thing is, if you're starting a new project, you could probably start with the free tier of a cloud provider like Vercel, later transfer to the Pro plan, and scale up as needed. In many cases, the appeal of the pay-as-you-go model is worth paying a bit extra in the long run.

Conclusion

Should you move your popular app to a VPS and save some dollars? The answer is it depends. It all boils down to assessing your project's specific needs, technical expertise, and growth expectations. The recent uproar regarding Vercel's pricing changes has illuminated this dilemma, presenting a classic case of convenience versus cost.

Vercel stands out for its seamless integration with Next.js, providing out-of-the-box solutions that significantly reduce the time and effort required for deployment and ongoing maintenance. This convenience is especially valuable for developers leveraging modern development practices with minimal setup. Additionally, Vercel's edge network capabilities offer significant performance benefits for global applications, ensuring faster load times and improved user experience.

However, these benefits come at a cost, which can be significantly higher than running a VPS, especially as your application scales. For those with the requisite skills, a VPS can offer a more cost-effective solution without the constraints of a platform-centric approach. This route grants more control over the hosting environment and potentially lowers costs at the expense of increased complexity in setup, scaling, and maintenance.

It's also important to consider the non-financial costs associated with each option. Vercel provides a robust, developer-friendly environment that can significantly accelerate development cycles and reduce the burden on your team. On the other hand, managing a VPS requires a steep learning curve and ongoing attention to security, performance, and scalability.

TLDR: If you're a solo founder or a small team looking to deploy and scale your application with minimal overhead quickly, Vercel is likely the best choice. If you are a Linux enthusiast or have a dedicated DevOps team, you can create a decent setup with a VPS and a CDN, but be prepared to invest time and effort into maintaining it. If you are a bigger company or team, the decision will likely depend on your specific needs, growth expectations, and budget constraints.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Jan Kaiser

Software engineer passionate about everything web-related. Particularly loves Angular, SCSS, TypeScript, soccer and dachshunds

@honzikec @honzikec

Local-First Application Development is Back with Dev Agrawal

In a world where connectivity is often taken for granted, the concept of "local first" applications is gaining traction. In this episode of the Modern Web Podcast, Dev Agrawal sheds light on this innovative approach, which prioritizes user devices as the primary data source. By enabling offline access and user control, local-first apps are revolutionizing the way we interact with technology. Traditionally, applications have relied on server-centric models, where data is stored and managed on remote servers. However, local-first architecture flips this paradigm by placing user devices at the forefront. By doing so, these apps empower users with offline access and control over their data. One of the key advantages of local-first architecture is its ability to create personalized experiences. By leveraging the data stored on user devices, apps can tailor their functionality to individual preferences and needs. Moreover, local-first apps excel at synchronization, ensuring that data remains consistent across multiple devices. This seamless synchronization allows users to switch between devices effortlessly, without worrying about data loss or inconsistencies. Data ownership is a critical aspect of local-first applications. With the user's device holding the definitive data version, individuals have greater control over their information. This is particularly important in collaborative environments, where multiple users need to access and modify shared data. To address this, local-first apps employ Conflict-free Replicated Data Types (CRDTs), which ensure that conflicts are resolved automatically and data integrity is maintained. By prioritizing data ownership and collaboration, local-first architecture fosters a more inclusive and efficient work environment. While local-first architecture offers numerous benefits, it is important to strike a balance between local and server data management. Certain data, such as large media files or complex computations, may still be better suited for server storage. Additionally, server-centric models can provide valuable backup and recovery options. As web development paradigms evolve, finding the right balance between local and server data management will be crucial in creating integrated user experiences and adaptable frameworks....

May 9, 2024

2 mins

JavaScriptSolidJS

A Deep Dive into SvelteKit's Rendering Techniques

A Deep Dive into SvelteKit's Rendering Techniques Introduction SvelteKit is a meta-framework for Svelte that allows you to develop pages based on their content. At its core, SvelteKit introduces three fundamental strategies out of the box, each designed to streamline the development process and adapt to the specific needs of your project. These strategies enable you to easily create dynamic, responsive, and highly interactive web applications. These strategies, or as SvelteKit calls them, page options, are: * Prerender: Ideal for static content that doesn't change, making your pages lightning-fast to load. * SSR (Server-Side Rendering): Ideal for rendering full pages with dynamic content from a server. * CSR (Client-Side Rendering): Best for highly dynamic and interactive applications where content updates frequently based on user actions. These page options can be applied to specific pages (when exported from **+page.js or +page.server.js) or to a group of pages (when exported from +layout.js or +layout.server.js). They can also be set across the entire application. You accomplish this by exporting it from the root layout. It's worth noting that child layouts and pages can supersede settings from parent layouts. This means you could activate prerendering for the whole app and then turn it off for certain pages that require dynamic server rendering (SSR). In this blog post, we'll explore these page options and share some insights on how you might use them in everyday web projects. Prerendering Prerendering is akin to taking a snapshot of your web pages when you build your application; you might have heard of this as static rendering. This snapshot is then served to all users, ensuring lightning-fast load times since the server simply delivers the pre-built files without additional processing rather than dynamically generating the files for each request. This method is perfect for content that remains unchanged across visits, such as blog posts, documentation, or landing pages. In other words, pages with no dynamic content. There will be situations where you would like to avoid using this option, though. The rule of thumb is that if two different users will see different content, then this is a no-go. Other reasons are inconvenience for your needs. For example, your build times could drag if you end up prerendering tons of pages. Is that convenient to you? Well, that’s for you to decide! The prerender option is turned off by default, so we need to enable it if we want to start using it. Export the following in the +page.server.js or just +page.js: ` Likewise, if you have a group of pages, you could do the same inside a +layout.js or +layout.server.js . If your app is suitable to be all SSG (Static Side Generation), you could use adapter-static, which will output files suitable for use with any static web server. In cases where you happen to opt-in for this, you could turn off pages that need dynamic rendering: ` Another cool feature about prerendering is that pages that fetch data from server routes can automatically inherit default values during the prerendering process. This feature simplifies data management and enhances the development workflow, especially when dealing with dynamic content that needs to be prerendered with specific data sets. Let's say you have a blog where each post fetches its content from a server route when the page loads. Normally, this would require the user's browser to make a request to the server at runtime. However, with prerendering, you can have this data fetched and embedded into the page at build time. ` In this example, when the blog/[slug].sveltepage is prerendered, it makes a fetch call to /api/posts/[slug], which returns the post data. This data is then used to prerender the blog post page with the content already in place, allowing the page to load instantly for the user, with the blog post content visible even before any JavaScript is executed on the client side. There’s a third and useful option when prerendering: ` Using this option is like telling SvelteKit to make a smart guess about whether to prerender your page in advance. You're saying, "Hey SvelteKit, you decide if this page should be prerendered based on what you find about the page" SvelteKit analyzes your page and if it determines the page can be prerendered without complications, it will automatically generate a prerendered version. This process involves SvelteKit either crawling a link inside an already prerendered page, prerendering entry points or targeting pages that are specifically marked for prerendering set in entries. An example is a blog section where you post articles regularly. The blog section has a main page that lists all your blog posts and individual pages for each blog post. The structure for this might be something like: In this setup, the /blog main entry page will be prerendered automatically. However, individual blog posts at paths like /blog/[slug] will not be prerendered unless linked directly from another prerendered page. For instance, if there’s a link to /blog/some-cool-slug, like: <a href="/blog/some-cool-slug">, SvelteKit will be able to crawl that link and prerender that specific page as well. Now let’s say that you would like to prerender your latest blog post, but there's no link for SvelteKit to crawl to this page. In these cases, you can explicitly add these pages to the prerender entries list. By doing so, SvelteKit will prerender every specified entry, ensuring that the content is immediately accessible to users. You can configure the prerender entries directly in your svelte.config.js file or by exporting an entries function from a +page.js, a +page.server.js or a +server.js belonging to a dynamic route. Here’s how you can do it: ` SSR SSR is similar to prerendering. It ensures that pages are first rendered on the server. This process generates the complete HTML content, which is then sent to the client for hydration). This approach enhances the initial page load performance and SEO, providing a better user experience. Unlike prerendering, where pages are generated at build time, SSR pages are created at runtime. This key difference allows for the generation of dynamic content, making SSR particularly suited for applications that require personalized content for each user or real-time updates, such as user dashboards, e-commerce sites, and social media platforms. Similar to prerendering, SSR comes with its own set of limitations, and there are scenarios where it might not be the best choice for your project: * SSR can be expensive. It can significantly load your server, especially for high-traffic sites, as each page request involves rendering content on the server. If server resources are constrained, this could lead to performance bottlenecks. * Highly Interactive Applications: Applications that rely heavily on user interactions and real-time updates (like games or interactive tools like an admin panel) might not benefit much from SSR. CSR can provide a smoother user experience in these cases, as it minimizes server requests after the initial load. * SEO Is Not YOUR Priority: If search engine optimization isn't a key concern for your project (for example, an internal dashboard or an app behind a login), the SEO benefits of SSR might not justify the additional complexity and server demands. export const ssr = true is the option enabled by default. Thus, we can use its benefits from the start. To execute code exclusively on the server, such as fetching data from a database or an external API, SvelteKit offers a convention using +page.server.js files. This setup is ideal for server-side operations, ensuring sensitive logic and credentials are not exposed to the client. ` Note: When you employ +page.js in SvelteKit, the contained code is executed on both the server and client sides by default. However, if you intend for the code to run exclusively on the client side, you can disable SSR by setting export const ssr = false within your +page.js file. Doing so ensures that the code is only executed in the browser, adhering to client-side rendering principles and turning your app into a SPA. This is useful for cases where you don’t need the load on the server, or you don’t benefit from any of the benefits of SSR. CSR CSR plays a crucial role in making web pages interactive by hydrating them and incorporating JavaScript. JavaScript is crucial for adding interactivity to web pages—everything from animations and video players to form validations and dynamic content updates relies on JavaScript. However, there are instances where JavaScript is unnecessary. Consider a prerendered 'About' page; enabling CSR on this page could be excessive, especially if it lacks interactive elements. In such scenarios, you can streamline your page by disabling CSR that comes enabled by default, which can be done by simply doing this: ` Using this trick smartly can make your web pages load fast because downloading JavaScript is sometimes heavy. The key lies in strategically combining this approach with other rendering techniques to optimize performance and user experience. One factor to consider, though, is that turning off CSR also means you'll lose client-side routing. This requires you to depend on traditional browser navigation instead. Conclusion By thoughtfully applying these strategies, you can craft a SvelteKit application that performs exceptionally and delivers a fantastic user experience tailored to your audience's needs. Wrapping up our journey through SSR with SvelteKit. We discovered how choosing the right way to render pages (like prerendering, SSR, or CSR) is super important and can make a big difference in how well a website works. SvelteKit is awesome because it lets you pick the best method for your website. So, remember, playing with SvelteKit and these rendering methods can make your websites stand out. Use it to build websites that not only work great but are also fun and easy for people to use. Dive in, try things out, and see how your web projects can shine!...

May 1, 2024

7 mins

SvelteSEOJavaScriptWeb Performance

Introduction to Babylon.js

Babylon.js is a powerful, open-source 3D engine capable of rendering interactive 3D and 2D graphics using JavaScript. It is a great choice for creating games, demos, visualizations, and other 3D applications for the web or even for VR. Being free, open-source, and cross-platform, Babylon.js is a great alternative to proprietary 3D engines like Unity and Unreal Engine. It is also a great alternative to other open-source 3D engines like Three.js and PlayCanvas as it provides TypeScript types out of the box, is optimized for performance, and provides advanced debugging tools. Its developer experience is excellent, and it has a large and active community making it a great choice for creating 3D applications for the web for both beginners and experts alike. Getting Started Babylon.js supports both ES6 and CommonJS module imports: - CommonJS Babylon.js npm packages support CommonJS/ES6 imports, UMD, and AMD-imports. - For developers seeking optimization through tree shaking, Babylon.js offers ES6 packages. These include @babylonjs/core for the core functionalities, and additional modules like @babylonjs/materials, @babylonjs/loaders, @babylonjs/gui, etc. It's important not to mix ES6 and legacy packages. If you want to use the CommonJS module imports, you can install Babylon.js as follows: ` Then, include it in your JavaScript or TypeScript file: ` If you want to use the ES6 module imports, you can install Babylon.js as follows: ` Then, include it in your JavaScript or TypeScript file: ` I prefer the ES6 module imports because they allow for tree shaking, which can significantly reduce the size of the final bundle. However, in this tutorial, I will be using the CommonJS module imports because that's what the Babylon.js playground uses. Creating Your First Babylon.js Scene The Babylon.js Playground is an essential tool for learning and developing with Babylon.js. It's a user-friendly environment where you can write code and immediately see the results in a live scene. The playground comes with a default scene, and experimenting with it is a great way to start. Apart from playing around with the default scene, you can also search the playground if you want to see examples of specific features. For example, if you search for "physics," you will find several examples of physics in action. The playground is also often used to share code snippets on the Babylon.js forum both when asking for help and when helping others. I often found myself googling specific Babylon.js problems or features and finding a playground example that helped me understand and solve my problem. Creating and Modifying Meshes Meshes are fundamental in 3D graphics. In Babylon.js, creating a basic mesh, like a sphere, involves a few lines of code: ` You can also create materials and assign them to meshes to change their appearance. For example, to make a ground plane red, you would write: ` Textures can also be added to materials: ` Importing and Using Meshes Babylon.js allows for the importation of complex meshes, which can be scaled and positioned within the scene: ` Making the Scene Interactive Interactivity is a key aspect of web experiences. Attaching controls to a camera enables user interaction through click-and-drag operations. ` Adding Virtual Reality Support Virtual reality is an exciting new technology that allows users to experience 3D environments more immersively. Babylon.js has built-in support for virtual reality, which can be enabled with a few lines of code: ` You just create an XR experience, get the camera from the base experience, and attach it to the canvas and you should be all set for VR. If you don't own a VR headset, you can still test your scene in VR using the Immersive Web Emulator Chrome Extension. Adding Physics Physics is an important part of many 3D applications. Babylon.js has a built-in physics engine that can be enabled with a few lines of code: ` Physics can be applied to meshes by setting their physicsImpostor property: ` Adding Lights Lights are essential for creating realistic scenes. In Babylon.js, there are four main types of lights, each offering unique properties and effects: 1. Directional Light: Mimics sunlight, emitting parallel light rays across the entire scene. It's defined by a direction vector and has an infinite range. 2. Point Light: Resembles a light bulb, radiating light equally in all directions from a single point in space. 3. Spot Light: Functions like a flashlight, emitting a conical beam of light from a specific position in a given direction. Its illumination area and decay are controlled by angle and exponent parameters. 4. Hemispheric Light: Simulates ambient environment lighting, defined by a direction, usually upwards. Its effect is influenced by setting different color properties. Each light type can be customized using properties like intensity and range, and you can control which meshes they illuminate. For more complex lighting scenarios, lightmaps can be utilized to pre-calculate and store lighting effects. For example, to add a directional light to the scene, you could write: ` Adding Shadows Shadows are an important part of creating realistic scenes as they can help convey the 3D structure of the scene by providing cues about the relative positions and distances of objects, enhancing the perception of depth and dimension. Babylon.js has several types of shadows, including PCF, PCFSoft, and PCSS. For example, to add PCF shadows to the scene, you would write: ` Adding Audio Audio is an important part of many 3D applications. Babylon.js has a built-in audio engine that can be enabled with a few lines of code: ` Audio can be added to the scene by creating a sound object: ` This particular example would play a "cannon blast" sound on a loop in your scene. The cannon blast asset is preloaded in the Babylon.js playground. If you were to load a custom asset in your application, you would simply provide a URL pointing to the sound file on the filesystem. For more details, you can check the documentation on playing sounds in Babylon.js. Adding User Interface Elements User interface elements can be used to add interactivity to a scene. Babylon.js provides a GUI library extension built on top of the DynamicTexture. For example, to add a dialog to the scene containing a button, you would write: ` To use the ES6 version, you'll need to install the @babylonjs/gui package: ` Then, import it into your JavaScript or TypeScript file like this: ` > Tip: In case you don't like the controls that allow users to tilt the HolographicSlate, you can disable them by setting slate._gizmo._rootMesh.setEnabled(false); after adding the slate to your scene. Adding Animations Animations can be used to add movement to a scene. Babylon.js has several types of animations, including keyframe, bone, and morph target. For example, to add a keyframe animation to the scene, you would write: ` Here's an explanation of what the code does: 1. Animation Creation: A BABYLON.Animation object named "myAnimation" is created to animate the scaling.x property, indicating the animation will affect the object's width. It runs at 30 frames per second, with values represented as floats, and loops continuously. 2. Defining Keyframes: Three keyframes are defined: - At frame 0, the scale is 1 (original size). - At frame 20, the scale reduces to 0.2. - At frame 100, the scale returns to 1. 3. Applying and Starting Animation: The animation is assigned to the sphere object and starts immediately, looping between frames 0 and 100. This creates a pulsating effect on the sphere's width. For a deeper dive into animations, you can check out the Babylon.js Animation Documentation. Debugging Debugging is an important part of any development process. Babylon.js has a built-in debug layer that can be enabled with a few lines of code: ` The debug layer provides a user-friendly interface for inspecting and modifying the scene. It can also show you the current frame rate and other performance metrics and lets you export the performance data. In case you are using the ES6 module imports, you'll need to install the @babylonjs/inspector package: ` Then, import it into your JavaScript or TypeScript file like this: ` Hosting and Sharing Your Scene Once you're satisfied with your creation, you can download it as an HTML file and host it on platforms like GitHub Pages, making it accessible to the world. You can also share your scene with others by sharing the playground URL. For example, the URL for the default scene is https://playground.babylonjs.com/#6QY4X1#1. In case you would like to integrate your scene with a framework of your choice, you can check out the Babylon.js External Libraries Documentation where you can find examples of Babylon.js being used with frameworks like React, Vue, or Ionic Angular. Conclusion Babylon.js is a powerful, open-source 3D engine capable of rendering interactive 3D and 2D graphics using JavaScript. It is well supported and maintained, providing a good developer experience with many interactive playground examples and a supportive community forum, making it a great choice for creating games, demos, visualizations, and other 3D applications for the web (and eventually even for native platforms as I've heard out of the box React Native support may be coming). This blog post hopefully gave you an overview of some of its capabilities and how to get started with it along with pointers to more in-depth documentation....

Mar 6, 2024

7 mins

JavaScriptBabylon.js

How to Leverage Apollo Client Fetch Policies Like the Pros

Apollo Client provides a rich ecosystem and cache for interfacing with your GraphQL APIs. You write your query and leverage the useQuery hook to fetch your data. It provides you with some state context and eventually resolves your query. That data is stored in a local, normalized, in-memory cache, which allows Apollo Client to respond to most previously run requests near instantaneously. This has huge benefits for client performance and the feel of your apps. However, sometimes Apollo's default doesn't match the user experience you want to provide. They provide fetch policies to allow you to control this behavior on each query you execute. In this article, we'll explore the different fetch policies and how you should leverage them in your application. cache-first This is the default for Apollo Client. Apollo will execute your query against the cache. If the cache can fully fulfill the request, then that's it, and we return to the client. If it can only partially match your request or cannot find any of the related data, the query will be run against your GraphQL server. The response is cached for the next query and returned to the handler. This method prioritizes minimizing the number of requests sent to your server. However, it has an adverse effect on data that changes regularly. Think of your social media feeds - they typically contain constantly changing information as new posts are generated. Or a real-time dashboard app tracking data as it moves through a system. cache-first is probably not the best policy for these use cases as you won't fetch the latest data from the upstream source. You can lower the cache time of items for the dashboard to avoid the staleness issue and still minimize the requests being made, but this problem will persist for social media feeds. The cache-first policy should be considered for data that does not change often in your system or data that the current user fully controls. Data that doesn't change often is easily cached, and that's a recommended pattern. For data that the user controls, we need to consider how that data changes. If only the current user can change it, we have 2 options: Return the updated data in the response of any mutation which is used to update the cache Use cache invalidation methods like refetchQueries or onQueryUpdated These methods will ensure that our cache stays in sync with our server allowing the policy to work optimally. However, if other users in the system can make changes that impact the current user's view, then we can not invalidate the cache properly using these strategies which makes this policy unideal. network-only This policy skips the cache lookup and goes to the server to fetch the results. The results are stored in the cache for other operations to leverage. Going back to the example I gave in my explanation cache-first of a social media feed, the network-only policy would be a great way to implement the feed itself as it's ever-changing, and we'll likely even want to poll for changes every 10s or so. The following is an example of what this component could look like: ` Whenever this SocialFeed component is rendered, we always fetch the latest results from the GraphQL server ensuring we're looking at the current data. The results are put in the cache which we can leverage in some children components. cache-only cache-only only checks the cache for the requested data and never hits the server. It throws an error if the specified cache items cannot be found. At first glance, this cache policy may seem unhelpful because it's unclear if our cache is seeded with our data. However, in combination with the network-only policy above, this policy becomes helpful. This policy is meant for components down tree from network-only level query. This method is for you if you're a fan of React components' compatibility. We can modify the return of our previous example to be as follows: ` Notice we're not passing the full post object as a prop. This simplifies our Post component types and makes later refactors easier. The Post would like like the following: ` In this query, we're grabbing the data directly from our cache every time because our top-level query should have fetched it. Now, a small bug here makes maintainability a bit harder. Our top-level GetFeed query doesn't guarantee fetching the same fields. Notice how our Post component exports a fragment. Fragments are a feature Apollo supports to share query elements across operations. In our SocialFeed component, we can change our query to be: ` Now, as we change our Post to use new fields and display different data, the refactoring is restricted to just that component, and the upstream components will detect the changes and handle them for us making our codebase more maintainable. Because the upstream component is always fetching from the network, we can trust that the cache will have our data, making this component safe to render. With these examples, though, our users will likely have to see a loading spinner or state on every render unless we add some server rendering. cache-and-network This is where cache-and-network comes to play. With this policy, Apollo Client will run your query against your cache and your GraphQL server. This further simplifies our example above if we want to provide the last fetched results to the user but then update the feed immediately upon gathering the latest data. This is similar to what X/Twitter does when you reload the app. You'll see the last value that was in the cache then it'll render the network values when ready. This can cause a jarring user experience though, if the data is changing a lot over time, so I recommend using this methodology sparsely. However, if you wanted to update our existing example, we'd just change our SocialFeed component to use this policy, and that'll keep our client and server better in sync while still enabling 10s polling. no-cache This policy is very similar to the network-only policy, except it bypasses the local cache entirely. In our previous example, we wrote engagement as a sub-selector on a Post and stored fields there. These metrics can change in real time pretty drastically. Chat features, reactions, viewership numbers, etc., are all types of data that may change in real time. The no-cache policy is good when this type of data is active, such as during a live stream or within the first few hours of a post going out. You may typically want to use the cache-and-network policy eventually but during that active period, you'll probably want to use no-cache so your consumers can trust your data. I'd probably recommend changing your server to split these queries and run different policies for the operations for performance reasons. I haven't mentioned this yet, but you can make the fetch policy on a query dynamic, meaning you combine these different policies' pending states. This could look like the following: ` We pass whether the event is live to the component that then leverages that info to determine if we should cache or not when fetching the chat. That being said, we should consider using subscription operations for this type of feature as well, but that's an exercise for another blog post. standby This is the most uncommon fetch policy, but has a lot of use. This option runs like a cache-first query when it executes. However, by default, this query does not run and is treated like a "skip" until it is manually triggered by a refetch or updateQueries caller. You can achieve similar results by leveraging the useLazyQuery operator, but this maintains the same behavior as other useQuery operators so you'll have more consistency among your components. This method is primarily used for operations pending other queries to finish or when you want to trigger the caller on a mutation. Think about a dashboard with many filters that need to be applied before your query executes. The standby fetch policy can wait until the user hits the Apply or Submit button to execute the operation then calls a await client.refetchQueries({ include: ["DashboardQuery"] }), which will then allow your component to pull in the parameters for your operation and execute it. Again, you could achieve this with useLazyQuery so it's really up to you and your team how you want to approach this problem. To avoid learning 2 ways, though, I recommend picking just one path. Conclusion Apollo Client's fetch policies are a versatile and helpful tool for managing your application data and keeping it in sync with your GraphQL server. In general, you should use the defaults provided by the library, but think about the user experience you want to provide. This will help you determine which policy best meets your needs. Leveraging tools like fragments will enable you to manage your application and use composable patterns more effectively. With the rise of React Server Components and other similar patterns, you'll need to be wary of how that impacts your Apollo Client strategy. However, if you're on a legacy application that leverages traditional SSR patterns, Apollo allows you to pre-render queries on the server and their related cache. When you combine these technologies, you'll find that your apps perform great, and your users will be delighted....

May 17, 2024

7 mins

GraphQL

Vercel vs. VPS - What's the drama, and which one should you choose?

Vercel vs. VPS - What's the drama, and which one should you choose?

Integrations

Scaling and Performance

Edge Nodes

Skill Requirements

Security

Tech Stack Flexibility

Cost

Conclusion

Jan Kaiser

You might also like

Local-First Application Development is Back with Dev Agrawal

A Deep Dive into SvelteKit's Rendering Techniques

Introduction to Babylon.js

How to Leverage Apollo Client Fetch Policies Like the Pros

You might also like

Local-First Application Development is Back with Dev Agrawal

A Deep Dive into SvelteKit's Rendering Techniques

Introduction to Babylon.js

How to Leverage Apollo Client Fetch Policies Like the Pros