<h3>How we improved performance with a single plugin — The Magic of Service Worker</h3><h4>Improving Web Performance with Service Workers, Google’s Workbox Plugin, and the Stale-While-Revalidate (SWR) Caching Strategy for Scalable Micro-Frontend Architectures</h4><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*sjINWDGXdfGDvdLt.jpg" /></figure><h4>The Challenge of Scale: Module Federation and Cache Invalidation at Autodesk</h4>At Autodesk, we run a large-scale web application built by 50 independent teams using a micro-frontend architecture powered by Module Federation.While this setup allows for frequent, autonomous deployments, it also introduces a critical performance bottleneck: cache invalidation.In a monolithic application, there’s usually one large codebase to keep track of. When you release a new version, the cache will invalidate for a single deployment. In contrast, a micro-frontend approach has many smaller pieces, each owned by different teams and updated on separate timelines. That means the browser (and any proxies) must consistently detect and update each piece.Every deployment required fetching updated remote (micro-frontend - /my-remote/remoteEntry.js), and this dependency couldn’t be reliably cached in the browser due to constant updates of each remote.Simple browser caching doesn’t always work because we can’t control how or when a user’s browser invalidates its cache. Instead, we rely on a CDN (Content Delivery Network) — a global system of servers that store and deliver content closer to users — to handle updates. But even a CDN has limits with so many micro-frontends changing at once.For users behind Proxies, VPNs, or Firewalls, this led to slow navigation, sluggish first-load times, and a frustrating user experience. Our existing solutions — like CDNs and traditional caching — weren’t enough to address the root cause.<h4>The Client’s Call: Why Traditional Caching Strategies Fell Short</h4>The turning point came when a client reached out, reporting slow application performance despite our best efforts. This was the wake-up call: traditional solutions like CDN optimization were not solving the problem.The root problem was clear — network delays and client-side limits caused the issues. We had to move beyond server-side fixes and explore cutting-edge client-side strategies to solve this.<h4>Discovering the Power of Service Workers with Google’s Workbox Plugin</h4><figure><img alt="" src="https://cdn-images-1.medium.com/max/233/0*9IPMETT1mzerAp1e.png" /></figure>As we brainstormed solutions, we turned to Service Workers — a powerful client-side technology capable of caching and serving assets offline. However, implementing a custom Service Worker for an application as complex as ours, with 50 independently deploying teams, was daunting.That’s when we discovered Google’s Workbox Plugin. This tool simplified the implementation process of a Service Worker, enabling us to configure caching quickly using rules without reinventing the wheel. Workbox became the foundation for our new approach to client-side optimization.Read more on Webpack’s recommendation on how to <a href="https://webpack.js.org/guides/progressive-web-application/">load the Service Worker using the Workbox plugin</a>.<pre>// Inside of webpack.config.js: const {GenerateSW} = require(&#39;workbox-webpack-plugin&#39;); module.exports = { // Other webpack config... plugins: [ // Other plugins... new GenerateSW({ // These are some common options, and not all are required. // Consult the docs for more info. exclude: [/.../, &#39;...&#39;], maximumFileSizeToCacheInBytes: ..., navigateFallback: &#39;...&#39;, runtimeCaching: [{ // Routing via a matchCallback function: urlPattern: ({request, url}) =&gt; ..., handler: &#39;...&#39;, options: { cacheName: &#39;...&#39;, expiration: { maxEntries: ..., }, }, }, { // Routing via a RegExp: urlPattern: new RegExp(&#39;...&#39;), handler: &#39;...&#39;, options: { cacheName: &#39;...&#39;, plugins: [..., ...], }, }], skipWaiting: ..., }), ], };</pre><h4>Revolutionizing Caching with SWR (Stale-While-Revalidate)</h4>Even with a Service Worker in place, we needed a smarter caching strategy. Enter SWR (Stale-While-Revalidate): a strategy that immediately serves cached content while fetching fresh background updates. This approach allowed us to:<ul><li>Serve content instantly for a seamless user experience.</li><li>Ensure that updates from all 50 teams were reflected without forcing full cache invalidation.</li></ul><figure><img alt="" src="https://cdn-images-1.medium.com/max/1014/0*2sedKVwtQpZuYiD_.png" /></figure>By combining Workbox and SWR, we created a solution that delivered the speed of caching without sacrificing the freshness of our micro-frontend architecture.<pre>// Inside of webpack.config.js: const {GenerateSW} = require(&#39;workbox-webpack-plugin&#39;); module.exports = { // Other webpack config... plugins: [ // Other plugins... new GenerateSW({ // ... runtimeCaching: [ { urlPattern: ({ url }) =&gt; [ &#39;.js&#39;, &#39;.css&#39;, &#39;html&#39;, //... ].some((extension) =&gt; url.pathname.endsWith(extension)), handler: &#39;StaleWhileRevalidate&#39;, // &lt;---------- Where the magic happens }, ], // ... }), ], };</pre><h4>The Transformation: Faster Performance, Happier Clients</h4>After rolling out our Service Worker solution powered by Workbox’s Service Worker and SWR strategy, the results were immediate and undeniable. The same client who reported performance issues reached out again to thank us for a “significant improvement” in their experience.This feedback was especially rewarding because we did not announce that we had implemented the solution yet — proof of its seamless effectiveness.<h4>Lessons for the Tech Community: Workbox’s Service Worker and SWR Best Practices</h4>Our journey highlights two essential lessons for teams facing similar challenges:<ol><li>Service Workers are game-changing technology for caching and client-side optimization for applications suffering from network latency.</li><li>Google’s Workbox Plugin simplifies Service Worker implementation, making starting with advanced strategies like SWR easy.</li></ol>Ready to transform your application’s performance? Start with Google’s Workbox documentation:<ul><li><a href="https://developer.chrome.com/docs/workbox">Workbox | Chrome for Developers</a></li><li><a href="https://web.dev/learn/pwa/service-workers">Service workers | web.dev</a></li></ul>If you’d like to discuss this topic further, you can find me on LinkedIn:<a href="https://www.linkedin.com/in/zach-bonfil-21b822187/">https://www.linkedin.com/in/zach-bonfil-21b822187/</a><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=a41a17942103" width="1" height="1" alt=""><hr><a href="https://medium.com/autodesk-tlv/how-we-improved-performance-with-a-single-plugin-the-magic-of-service-worker-a41a17942103">How we improved performance with a single plugin — The Magic of Service Worker</a> was originally published in <a href="https://medium.com/autodesk-tlv">Autodesk TLV</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

How we improved performance with a single plugin — The Magic of Service Worker
Improving Web Performance with Service Workers, Google’s Workbox Plugin, and the Stale-While-Revalidate (SWR) Caching Strategy for Scalable Micro-Frontend Architectures

The Challenge of Scale: Module Federation and Cache Invalidation at Autodesk
At Autodesk, we run a large-scale web application built by 50 independent teams using a micro-frontend architecture powered by Module Federation.
While this setup allows for frequent, autonomous deployments, it also introduces a critical performance bottleneck: cache invalidation.
In a monolithic application, there’s usually one large codebase to keep track of. When you release a new version, the cache will invalidate for a single deployment. In contrast, a micro-frontend approach has many smaller pieces, each owned by different teams and updated on separate timelines. That means the browser (and any proxies) must consistently detect and update each piece.
Every deployment required fetching updated remote (micro-frontend - /my-remote/remoteEntry.js), and this dependency couldn’t be reliably cached in the browser due to constant updates of each remote.
Simple browser caching doesn’t always work because we can’t control how or when a user’s browser invalidates its cache. Instead, we rely on a CDN (Content Delivery Network) — a global system of servers that store and deliver content closer to users — to handle updates. But even a CDN has limits with so many micro-frontends changing at once.
For users behind Proxies, VPNs, or Firewalls, this led to slow navigation, sluggish first-load times, and a frustrating user experience. Our existing solutions — like CDNs and traditional caching — weren’t enough to address the root cause.
The Client’s Call: Why Traditional Caching Strategies Fell Short
The turning point came when a client reached out, reporting slow application performance despite our best efforts. This was the wake-up call: traditional solutions like CDN optimization were not solving the problem.
The root problem was clear — network delays and client-side limits caused the issues. We had to move beyond server-side fixes and explore cutting-edge client-side strategies to solve this.
Discovering the Power of Service Workers with Google’s Workbox Plugin

As we brainstormed solutions, we turned to Service Workers — a powerful client-side technology capable of caching and serving assets offline. However, implementing a custom Service Worker for an application as complex as ours, with 50 independently deploying teams, was daunting.
That’s when we discovered Google’s Workbox Plugin. This tool simplified the implementation process of a Service Worker, enabling us to configure caching quickly using rules without reinventing the wheel. Workbox became the foundation for our new approach to client-side optimization.
Read more on Webpack’s recommendation on how to load the Service Worker using the Workbox plugin.
// Inside of webpack.config.js:
const {GenerateSW} = require('workbox-webpack-plugin');
module.exports = {
 // Other webpack config...
 plugins: [
 // Other plugins...
 new GenerateSW({
 // These are some common options, and not all are required.
 // Consult the docs for more info.
 exclude: [/.../, '...'],
 maximumFileSizeToCacheInBytes: ...,
 navigateFallback: '...',
 runtimeCaching: [{
 // Routing via a matchCallback function:
 urlPattern: ({request, url}) => ...,
 handler: '...',
 options: {
 cacheName: '...',
 expiration: {
 maxEntries: ...,
 },
 },
 }, {
 // Routing via a RegExp:
 urlPattern: new RegExp('...'),
 handler: '...',
 options: {
 cacheName: '...',
 plugins: [..., ...],
 },
 }],
 skipWaiting: ...,
 }),
 ],
};
Revolutionizing Caching with SWR (Stale-While-Revalidate)
Even with a Service Worker in place, we needed a smarter caching strategy. Enter SWR (Stale-While-Revalidate): a strategy that immediately serves cached content while fetching fresh background updates. This approach allowed us to:

Serve content instantly for a seamless user experience.
Ensure that updates from all 50 teams were reflected without forcing full cache invalidation.

By combining Workbox and SWR, we created a solution that delivered the speed of caching without sacrificing the freshness of our micro-frontend architecture.
// Inside of webpack.config.js:
const {GenerateSW} = require('workbox-webpack-plugin');
module.exports = {
 // Other webpack config...
 plugins: [
 // Other plugins...
 new GenerateSW({
 // ...
 runtimeCaching: [
 {
 urlPattern: ({ url }) =>
 [
 '.js',
 '.css',
 'html',
 //...
 ].some((extension) => url.pathname.endsWith(extension)),
 handler: 'StaleWhileRevalidate', // <---------- Where the magic happens
 },
 ],
 // ...
 }),
 ],
};
The Transformation: Faster Performance, Happier Clients
After rolling out our Service Worker solution powered by Workbox’s Service Worker and SWR strategy, the results were immediate and undeniable. The same client who reported performance issues reached out again to thank us for a “significant improvement” in their experience.
This feedback was especially rewarding because we did not announce that we had implemented the solution yet — proof of its seamless effectiveness.
Lessons for the Tech Community: Workbox’s Service Worker and SWR Best Practices
Our journey highlights two essential lessons for teams facing similar challenges:

Service Workers are game-changing technology for caching and client-side optimization for applications suffering from network latency.
Google’s Workbox Plugin simplifies Service Worker implementation, making starting with advanced strategies like SWR easy.

Ready to transform your application’s performance? Start with Google’s Workbox documentation:

Workbox | Chrome for Developers
Service workers | web.dev

If you’d like to discuss this topic further, you can find me on LinkedIn:
https://www.linkedin.com/in/zach-bonfil-21b822187/

How we improved performance with a single plugin — The Magic of Service Worker was originally published in Autodesk TLV on Medium, where people are continuing the conversation by highlighting and responding to this story.

How we improved performance with a single plugin — The Magic of Service Worker

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*qD0JDT3Kk5RqJNwbE4E6FA.jpeg" /></figure>In the dynamic realm of relational databases, PostgreSQL stands tall as a versatile powerhouse. When it comes to optimizing database performance, there is a crucial tool that every developer and database admin relies on — indexes. In this blog post, we’ll take a closer look at PostgreSQL indexes — a handy tool for improving database performance. From demystifying what they are to mastering their creation, understanding when to use them, and ensuring they’re finely tuned, we’ll cover it all, peppered with real code snippets and examples.<h3>Decoding PostgreSQL Indexes</h3>Let’s start with the basics. An index in PostgreSQL is like a map that turbocharges your queries, enabling swift data retrieval. Picture an index as the table of contents in a book — it’s your shortcut to finding exactly what you need, without flipping through every page. Without indexes, databases would slog through entire tables to fetch data, leading to inefficient query performance, especially for large datasets.<h3>Crafting Indexes in PostgreSQL</h3><pre>CREATE INDEX index_name ON table_name (column_name);</pre>Indexes can be sprinkled over one or multiple columns in a table. But, hold on! The columns you pick for indexing and the type of index you choose are pivotal.<h3>The Index Selection Dilemma: When to Index</h3>Indexes are strong tools, but they’re not without their trade-offs. While they boost read performance, they can slow down write operations due to maintenance overhead. The key is to choose your battles wisely. Here are scenarios where indexes shine:<ol><li>Frequent Searches: If your application heavily relies on frequent searches within specific columns, indexing is the optimal choice.</li><li>Joining: Columns used in joining tables are prime candidates for indexing, ensuring faster data retrieval during joins.</li><li>Sorting &amp; Ordering: For columns playing sorting and ordering roles, indexing steps up the game of ORDER BY and GROUP BY clauses.</li></ol><h3>Navigating Index Types</h3>PostgreSQL spoils you with index types, each tailored to specific scenarios. Let’s explore a couple:<ul><li>B-tree Index: Your go-to choice. Great for range queries and equality comparisons.</li></ul><pre>-- Create a B-tree index on a single column CREATE INDEX idx_column_name ON table_name (column_name);</pre><pre>-- Create a B-tree composite index on multiple columns CREATE INDEX idx_multi_column ON table_name (column1, column2);</pre><ul><li>Hash Index: A heavyweight for equality checks, particularly when dealing with limited distinct values.</li></ul><pre>-- Create a hash index on a single column CREATE INDEX idx_column_name ON table_name USING hash (column_name);</pre>Since it <a href="https://www.postgresql.org/docs/current/indexes-types.html#INDEXES-TYPES-HASH:~:text=Hash%20indexes%20store%20a%2032%2Dbit%20hash%20code%20derived%20from%20the%20value%20of%20the%20indexed%20column.%20Hence%2C%20such%20indexes%20can%20only%20handle%20simple%20equality%20comparisons.%20The%20query%20planner%20will%20consider%20using%20a%20hash%20index%20whenever%20an%20indexed%20column%20is%20involved%20in%20a%20comparison%20using%20the%20equal%20operator%3A">uses equality checks(=)</a> If we specify a separate operator (such as pattern matching), it does not use the hash index.<ul><li>GIN (Generalized Inverted Index): A power player for array data queries and full-text search.</li></ul><pre>-- Create a GIN index on an array column CREATE INDEX idx_array_column ON table_name USING gin (array_column);</pre><pre>-- Create a GIN index for full-text search (requires the &quot;pg_trgm&quot; extension) -- Enable the extension if not already enabled CREATE EXTENSION IF NOT EXISTS pg_trgm; CREATE INDEX idx_full_text_search ON table_name USING gin (text_column gin_trgm_ops);</pre><ul><li>GiST (Generalized Search Tree): Versatile and valuable for various data types, including spatial data.</li></ul><pre>-- Create a GiST index on a geometry column (requires the &quot;postgis&quot; extension) -- Enable the extension if not already enabled CREATE EXTENSION IF NOT EXISTS postgis; CREATE INDEX idx_spatial_data ON table_name USING gist (geometry_column);</pre>Please note that for some index types (e.g., GiST and GIN), you may need to enable specific extensions (like “postgis” for spatial data or “pg_trgm” for text search) before you can create indexes of that type.<h3>Harnessing the Power of ANALYZE</h3>The ANALYZE command is your backstage pass to index insights. It offers statistics about table distribution and index usage, helping you evaluate their effectiveness.<h4>The ANALYZE Command:</h4><ul><li>The ANALYZE command is used to collect statistics about a table or an index. It provides the PostgreSQL query planner with information about the distribution of data within a table or index.</li><li>When you perform an ANALYZE operation on a table or an index, PostgreSQL takes a representative sample of the data and collects information about how the data is distributed.</li><li>ANALYZE is employed as part of regular database upkeep to ensure that the statistics remain current and relevant.</li></ul><pre>ANALYZE table_name;</pre><h4>EXPLAIN ANALYZE:</h4><ul><li>The EXPLAIN ANALYZE command is used to obtain the execution plan and performance statistics for a query without actually executing the query. It&#39;s a tool for understanding how PostgreSQL plans to execute a query and how long each part of the query takes to run.</li><li>When you run EXPLAIN ANALYZE followed by a query, PostgreSQL generates the query execution plan, executes the query, and then provides a detailed breakdown of how the query was executed, including the time spent on each step and the number of rows processed at each step. This information is valuable for query optimization and performance tuning.</li></ul><pre>EXPLAIN ANALYZE SELECT * FROM table_name WHERE column_name = &#39;value&#39;;</pre><h3>Indexing Strategies in Action</h3><h4>Scenario 1: Basic Indexing</h4>Imagine you’re overseeing a table named customers, which stores valuable information about your clients. You often need to search for customers using their email addresses. Here&#39;s how it looks:<pre>CREATE TABLE customers ( customer_id SERIAL PRIMARY KEY, first_name VARCHAR(50), last_name VARCHAR(50), email VARCHAR(100) ); INSERT INTO customers (first_name, last_name, email) VALUES (&#39;Arik&#39;, &#39;Jordan&#39;, &#39;Arik@example.com&#39;), (&#39;Jane&#39;, &#39;Smith&#39;, &#39;jane@example.com&#39;), (&#39;Michael&#39;, &#39;Johnson&#39;, &#39;michael@example.com&#39;);</pre>Without an index in place, when you want to find a specific email address, it’s like searching for a needle in a haystack. Here’s what the query would look like:<pre>EXPLAIN ANALYZE SELECT * FROM customers WHERE email = &#39;Arik@example.com&#39;;</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/684/1*1TwA_a0pSjS-ulV6Fpeg0Q.png" /><figcaption>EXPLAIN ANALYZE comman’s output — without index</figcaption></figure>Now, let’s create an index on the email column to speed up these queries, and see the output of the EXPLAIN ANALYZE command:<pre>CREATE INDEX idx_email ON customers (email); EXPLAIN ANALYZE SELECT * FROM customers WHERE email = &#39;Arik@example.com&#39;;</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/790/1*3Zb7hKTlX0VICjYpSDRcqQ.png" /><figcaption>EXPLAIN ANALYZE comman’s output — with index</figcaption></figure>Now the query plan using an index scan instead of a regular seq scan.Wait..! but you said ‘speed up’, it is taking longer now, how is that possible?we will figure it out in last section: When to Avoid Indexing: Situations to Consider.<h4>Scenario 2: Multi-Column Index</h4>In a slightly different scenario, you’re tasked with managing an orders table that keeps track of customer orders. You frequently need to find orders based on two things: the customer&#39;s ID and the order date. Here&#39;s how the orders table looks:<pre>CREATE TABLE orders ( order_id SERIAL PRIMARY KEY, customer_id INT, order_date DATE, total_amount DECIMAL(10, 2) ); INSERT INTO orders (customer_id, order_date, total_amount) VALUES (1, &#39;2023-01-15&#39;, 150.00), (2, &#39;2023-02-10&#39;, 200.00), (1, &#39;2023-02-20&#39;, 120.00);</pre>To make these order-based queries faster, we can create a multi-column index on both customer_id and order_date. It&#39;s like giving your database a roadmap for finding orders efficiently:<pre>CREATE INDEX idx_customer_order_date ON orders (customer_id, order_date);</pre>Now, your queries involving filtering by both criteria will be optimized for speed.<h4>Scenario 3: Index Order and Included Columns</h4>Imagine managing a products table with detailed information about various products. You frequently search for products based on their category and manufacturer. To create a covering index, including the product_name column in the index might enhance performance.<pre>CREATE TABLE products ( product_id SERIAL PRIMARY KEY, product_name VARCHAR(100), category VARCHAR(50), manufacturer VARCHAR(50), price DECIMAL(8, 2) ); INSERT INTO products (product_name, category, manufacturer, price) VALUES (&#39;Laptop&#39;, &#39;Electronics&#39;, &#39;ABC Electronics&#39;, 999.99), (&#39;Smartphone&#39;, &#39;Electronics&#39;, &#39;XYZ Mobile&#39;, 599.99), (&#39;Chair&#39;, &#39;Furniture&#39;, &#39;Furniture Co.&#39;, 149.99);</pre>Create an index with columns ordered by category and manufacturer, and include the product_name:<pre>CREATE INDEX idx_product_search ON products (category, manufacturer) INCLUDE (product_name);</pre><h3>Multi-Column Indexes Order</h3>Consider a scenario where you manage a database of products. The table includes several columns: product_id, category, manufacturer, price, and availability. You frequently run queries to filter products based on their category and manufacturer.<h4>Column Order Matters:</h4>When creating a multi-column index, the order of the columns is crucial. The leftmost column in the index plays a pivotal role. It should align with the most frequently filtered or sorted criteria in your queries.In our case, since we often filter by category first and then by manufacturer, the optimal index order should have category as the leftmost column.<pre>-- Correct Index Order (category, manufacturer) CREATE INDEX idx_product_search ON products (category, manufacturer);</pre>Now, when you run queries filtering by category and manufacturer, the index&#39;s hierarchy aligns perfectly with your query patterns, leading to efficient data retrieval.<h4>Incorrect Index Order:</h4>Conversely, if you create the index with an incorrect order, say, starting with manufacturer, it might not yield the same performance benefits:<pre>-- Incorrect Index Order (manufacturer, category) CREATE INDEX idx_incorrect_order ON products (manufacturer, category);</pre>Queries filtering by category first would not benefit from this index as much, as it doesn&#39;t match the leftmost prefix of the index.<h4>Querying with the Correct Index</h4>Now, let’s see how this well-ordered index improves query performance:<pre>SELECT * FROM products WHERE category = &#39;Electronics&#39; AND manufacturer = &#39;ABC Electronics&#39;;</pre>This query efficiently utilizes the multi-column index, benefiting from the leftmost category column.<h4>Querying without the Correct Index</h4>Contrast this with a query that doesn’t align with the index order:<pre>SELECT * FROM products WHERE manufacturer = &#39;ABC Electronics&#39; AND category = &#39;Electronics&#39;;</pre>This query might not fully leverage the index’s potential, resulting in potentially slower performance.<h3>When to Avoid Indexing: Situations to Consider</h3><ol><li>Highly Volatile Tables: Tables frequently changing with new data or updates may not benefit from indexes due to potential write performance impacts.</li><li>Small Tables: For very small tables with few rows, adding indexes may not significantly boost performance and could be unnecessary.</li><li>Low Selectivity Columns: Columns with limited distinct values might not gain much from indexing; focus on columns with higher variety.</li><li>Frequent Full Table Scans: When queries scan the entire table without leveraging indexes, the overhead of maintaining them may not be justified.</li><li>Batch Insert Operations: During large data imports, temporarily removing and then rebuilding indexes can expedite the process.</li><li>Temporary Tables: For short-lived tables rarely queried, adding indexes might not be worth the effort.</li><li>Queries with Low Complexity: Simple queries with minimal filtering may not see significant performance gains from indexes.</li><li>Low Latency Tolerance: In real-time applications, even minor indexing delays may not be acceptable, necessitating other optimization methods.</li></ol>Keep in mind that whether to use or skip indexes should be based on a thorough analysis of your specific database and your performance needs. It can be beneficial to closely examine your queries, both with and without indexes, and employ the EXPLAIN ANALYZE command to determine the actual impact on performance.<h3>Conclusion: Mastering the Art of Indexing</h3>Becoming professional in indexing is a must skill when working with the PostgreSQL database management system. By knowing which columns to index and understanding how indexing really works, you’ll have the tools to make your queries faster and more efficient. Don’t hesitate to experiment with various types of indexes, monitor their performance, and leverage included columns to create efficient covering indexes. Armed with these practical examples, you’ll be well-prepared to enhance the efficiency of your PostgreSQL database, ensuring that your application remains responsive and fast, even as your data continues to evolve and expand.<img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=5e4b0dc293e5" width="1" height="1" alt=""><hr><a href="https://medium.com/autodesk-tlv/mastering-postgresql-indexes-for-optimal-performance-5e4b0dc293e5">Mastering PostgreSQL Indexes for Optimal Performance</a> was originally published in <a href="https://medium.com/autodesk-tlv">Autodesk TLV</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the dynamic realm of relational databases, PostgreSQL stands tall as a versatile powerhouse. When it comes to optimizing database performance, there is a crucial tool that every developer and database admin relies on — indexes. In this blog post, we’ll take a closer look at PostgreSQL indexes — a handy tool for improving database performance. From demystifying what they are to mastering their creation, understanding when to use them, and ensuring they’re finely tuned, we’ll cover it all, peppered with real code snippets and examples.
Decoding PostgreSQL Indexes
Let’s start with the basics. An index in PostgreSQL is like a map that turbocharges your queries, enabling swift data retrieval. Picture an index as the table of contents in a book — it’s your shortcut to finding exactly what you need, without flipping through every page. Without indexes, databases would slog through entire tables to fetch data, leading to inefficient query performance, especially for large datasets.
Crafting Indexes in PostgreSQL
CREATE INDEX index_name ON table_name (column_name);
Indexes can be sprinkled over one or multiple columns in a table. But, hold on! The columns you pick for indexing and the type of index you choose are pivotal.
The Index Selection Dilemma: When to Index
Indexes are strong tools, but they’re not without their trade-offs. While they boost read performance, they can slow down write operations due to maintenance overhead. The key is to choose your battles wisely. Here are scenarios where indexes shine:

Frequent Searches: If your application heavily relies on frequent searches within specific columns, indexing is the optimal choice.
Joining: Columns used in joining tables are prime candidates for indexing, ensuring faster data retrieval during joins.
Sorting & Ordering: For columns playing sorting and ordering roles, indexing steps up the game of ORDER BY and GROUP BY clauses.

Navigating Index Types
PostgreSQL spoils you with index types, each tailored to specific scenarios. Let’s explore a couple:

B-tree Index: Your go-to choice. Great for range queries and equality comparisons.

-- Create a B-tree index on a single column
CREATE INDEX idx_column_name ON table_name (column_name);
-- Create a B-tree composite index on multiple columns
CREATE INDEX idx_multi_column ON table_name (column1, column2);

Hash Index: A heavyweight for equality checks, particularly when dealing with limited distinct values.

-- Create a hash index on a single column
CREATE INDEX idx_column_name ON table_name USING hash (column_name);
Since it uses equality checks(=) If we specify a separate operator (such as pattern matching), it does not use the hash index.

GIN (Generalized Inverted Index): A power player for array data queries and full-text search.

-- Create a GIN index on an array column
CREATE INDEX idx_array_column ON table_name USING gin (array_column);
-- Create a GIN index for full-text search (requires the "pg_trgm" extension)
-- Enable the extension if not already enabled
CREATE EXTENSION IF NOT EXISTS pg_trgm; 
CREATE INDEX idx_full_text_search 
ON table_name 
USING gin (text_column gin_trgm_ops);

GiST (Generalized Search Tree): Versatile and valuable for various data types, including spatial data.

-- Create a GiST index on a geometry column (requires the "postgis" extension)
-- Enable the extension if not already enabled
CREATE EXTENSION IF NOT EXISTS postgis; 
CREATE INDEX idx_spatial_data ON table_name USING gist (geometry_column);
Please note that for some index types (e.g., GiST and GIN), you may need to enable specific extensions (like “postgis” for spatial data or “pg_trgm” for text search) before you can create indexes of that type.
Harnessing the Power of ANALYZE
The ANALYZE command is your backstage pass to index insights. It offers statistics about table distribution and index usage, helping you evaluate their effectiveness.
The ANALYZE Command:

The ANALYZE command is used to collect statistics about a table or an index. It provides the PostgreSQL query planner with information about the distribution of data within a table or index.
When you perform an ANALYZE operation on a table or an index, PostgreSQL takes a representative sample of the data and collects information about how the data is distributed.
ANALYZE is employed as part of regular database upkeep to ensure that the statistics remain current and relevant.

ANALYZE table_name;
EXPLAIN ANALYZE:

The EXPLAIN ANALYZE command is used to obtain the execution plan and performance statistics for a query without actually executing the query. It's a tool for understanding how PostgreSQL plans to execute a query and how long each part of the query takes to run.
When you run EXPLAIN ANALYZE followed by a query, PostgreSQL generates the query execution plan, executes the query, and then provides a detailed breakdown of how the query was executed, including the time spent on each step and the number of rows processed at each step. This information is valuable for query optimization and performance tuning.

EXPLAIN ANALYZE SELECT * FROM table_name WHERE column_name = 'value';
Indexing Strategies in Action
Scenario 1: Basic Indexing
Imagine you’re overseeing a table named customers, which stores valuable information about your clients. You often need to search for customers using their email addresses. Here's how it looks:
CREATE TABLE customers (
    customer_id SERIAL PRIMARY KEY,
    first_name VARCHAR(50),
    last_name VARCHAR(50),
    email VARCHAR(100)
);
INSERT INTO customers (first_name, last_name, email)
VALUES
    ('Arik', 'Jordan', 'Arik@example.com'),
    ('Jane', 'Smith', 'jane@example.com'),
    ('Michael', 'Johnson', 'michael@example.com');
Without an index in place, when you want to find a specific email address, it’s like searching for a needle in a haystack. Here’s what the query would look like:
EXPLAIN ANALYZE SELECT * FROM customers WHERE email = 'Arik@example.com';
EXPLAIN ANALYZE comman’s output — without index
Now, let’s create an index on the email column to speed up these queries, and see the output of the EXPLAIN ANALYZE command:
CREATE INDEX idx_email ON customers (email);
EXPLAIN ANALYZE SELECT * FROM customers WHERE email = 'Arik@example.com';
EXPLAIN ANALYZE comman’s output — with index
Now the query plan using an index scan instead of a regular seq scan.
Wait..! but you said ‘speed up’, it is taking longer now, how is that possible?we will figure it out in last section: When to Avoid Indexing: Situations to Consider.
Scenario 2: Multi-Column Index
In a slightly different scenario, you’re tasked with managing an orders table that keeps track of customer orders. You frequently need to find orders based on two things: the customer's ID and the order date. Here's how the orders table looks:
CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    customer_id INT,
    order_date DATE,
    total_amount DECIMAL(10, 2)
);
INSERT INTO orders (customer_id, order_date, total_amount)
VALUES
    (1, '2023-01-15', 150.00),
    (2, '2023-02-10', 200.00),
    (1, '2023-02-20', 120.00);
To make these order-based queries faster, we can create a multi-column index on both customer_id and order_date. It's like giving your database a roadmap for finding orders efficiently:
CREATE INDEX idx_customer_order_date ON orders (customer_id, order_date);
Now, your queries involving filtering by both criteria will be optimized for speed.
Scenario 3: Index Order and Included Columns
Imagine managing a products table with detailed information about various products. You frequently search for products based on their category and manufacturer. To create a covering index, including the product_name column in the index might enhance performance.
CREATE TABLE products (
    product_id SERIAL PRIMARY KEY,
    product_name VARCHAR(100),
    category VARCHAR(50),
    manufacturer VARCHAR(50),
    price DECIMAL(8, 2)
);
INSERT INTO products (product_name, category, manufacturer, price)
VALUES
    ('Laptop', 'Electronics', 'ABC Electronics', 999.99),
    ('Smartphone', 'Electronics', 'XYZ Mobile', 599.99),
    ('Chair', 'Furniture', 'Furniture Co.', 149.99);
Create an index with columns ordered by category and manufacturer, and include the product_name:
CREATE INDEX idx_product_search 
ON products (category, manufacturer) 
INCLUDE (product_name);
Multi-Column Indexes Order
Consider a scenario where you manage a database of products. The table includes several columns: product_id, category, manufacturer, price, and availability. You frequently run queries to filter products based on their category and manufacturer.
Column Order Matters:
When creating a multi-column index, the order of the columns is crucial. The leftmost column in the index plays a pivotal role. It should align with the most frequently filtered or sorted criteria in your queries.
In our case, since we often filter by category first and then by manufacturer, the optimal index order should have category as the leftmost column.
-- Correct Index Order (category, manufacturer)
CREATE INDEX idx_product_search ON products (category, manufacturer);
Now, when you run queries filtering by category and manufacturer, the index's hierarchy aligns perfectly with your query patterns, leading to efficient data retrieval.
Incorrect Index Order:
Conversely, if you create the index with an incorrect order, say, starting with manufacturer, it might not yield the same performance benefits:
-- Incorrect Index Order (manufacturer, category)
CREATE INDEX idx_incorrect_order ON products (manufacturer, category);
Queries filtering by category first would not benefit from this index as much, as it doesn't match the leftmost prefix of the index.
Querying with the Correct Index
Now, let’s see how this well-ordered index improves query performance:
SELECT * FROM products 
WHERE category = 'Electronics' AND manufacturer = 'ABC Electronics';
This query efficiently utilizes the multi-column index, benefiting from the leftmost category column.
Querying without the Correct Index
Contrast this with a query that doesn’t align with the index order:
SELECT * FROM products 
WHERE manufacturer = 'ABC Electronics' AND category = 'Electronics';
This query might not fully leverage the index’s potential, resulting in potentially slower performance.
When to Avoid Indexing: Situations to Consider

Highly Volatile Tables: Tables frequently changing with new data or updates may not benefit from indexes due to potential write performance impacts.
Small Tables: For very small tables with few rows, adding indexes may not significantly boost performance and could be unnecessary.
Low Selectivity Columns: Columns with limited distinct values might not gain much from indexing; focus on columns with higher variety.
Frequent Full Table Scans: When queries scan the entire table without leveraging indexes, the overhead of maintaining them may not be justified.
Batch Insert Operations: During large data imports, temporarily removing and then rebuilding indexes can expedite the process.
Temporary Tables: For short-lived tables rarely queried, adding indexes might not be worth the effort.
Queries with Low Complexity: Simple queries with minimal filtering may not see significant performance gains from indexes.
Low Latency Tolerance: In real-time applications, even minor indexing delays may not be acceptable, necessitating other optimization methods.

Keep in mind that whether to use or skip indexes should be based on a thorough analysis of your specific database and your performance needs. It can be beneficial to closely examine your queries, both with and without indexes, and employ the EXPLAIN ANALYZE command to determine the actual impact on performance.
Conclusion: Mastering the Art of Indexing
Becoming professional in indexing is a must skill when working with the PostgreSQL database management system. By knowing which columns to index and understanding how indexing really works, you’ll have the tools to make your queries faster and more efficient. Don’t hesitate to experiment with various types of indexes, monitor their performance, and leverage included columns to create efficient covering indexes. Armed with these practical examples, you’ll be well-prepared to enhance the efficiency of your PostgreSQL database, ensuring that your application remains responsive and fast, even as your data continues to evolve and expand.

Mastering PostgreSQL Indexes for Optimal Performance was originally published in Autodesk TLV on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mastering PostgreSQL Indexes for Optimal Performance

Developing Games for Android and iOS with Kotlin in Jetpack Compose
Jetpack Compose is Android’s recommended modern toolkit for writing and building native UI. Using compose we can bring our app to life using less code, and very quickly, but what about games ?
Recently, Jetbrains announced that compose Multiplatform will be able to target iOS for the first time (Desktop had already been supported for a while) which great news, since now we share the UI between our Android and iOS, which means that we can try to create our game and share the whole code between two platforms, and write it all using Compose.
Let’s see how this can be achieved.
Our first step will be to create new KMP (KMM name is deprecated) and run it to make sure we have a good starting point for running an Android and iOS app.
Our second step will be defining compose Multiplatform libraries support for the KMP, project since they aren’t a part of the basic template, and we need to manually add these libraries into our Gradle settings.
Also we will create a shared composable function that will be shared for Android and iOS.
Finally in the third step we will create a very simple game engine in compose in Kotlin(which is based on the wonderful tutorial of Sebastian Aigner almost two years ago — creating Asteroid game ! Check it out for more info)
First step — Creating KMP Project
Download latest Android Studio and open a new project
Select Kotlin Multiplatform App
Select Kotlin Multiplatform App and this template will generate all the needed files in order to run our app on Android and iOS.
Write your app’s name and package name
Write your app and package names and select the Minimum SDK in order to target your audience. I choose Android 8.1 since it targets most of the devices. Finally leave the build configuration as is, and click Next.0
Write your Android and iOS project names
In the next screen choose the Android and iOS project names and click Finish.
Once finished is clicked, AS will sync all the needed files (which can take a while, since on the first time it needs to download all the packages for KMP)
When finished, you can test and run that everything works OK, in AS click Play and for iOS — open the iOS folder, click on the iosBallApp.xcodeproj and open it using Xcode.
Open with Xcode
Inside Xcode, click Play and see the results :
Android and iOS apps running with KMP support
Second step — Define Jetpack Compose Multiplatform support
Next steps are needed in order to use the compose libraries inside the shared code, this will require manual settings inside the settings and Gradle files. Let’s jump into it.
Open gradle.properies file and add these lines :
kotlin.version=1.8.20
agp.version=8.0.1
compose.version=1.4.0
org.jetbrains.compose.experimental.uikit.enabled=true
kotlin.native.cacheKind=true
Next, open Project build.gradle.kts and replace the lines the template created with the following lines :
 kotlin("multiplatform").apply(false)
 id("com.android.application").apply(false)
 id("com.android.library").apply(false)
 id("org.jetbrains.compose").apply(false)
We just removed the constant versions and we added compose library plugin.
For android and shared build.gradle.kts , add also the plugin of compose as one of the plugins.
id("org.jetbrains.compose")
Inside the shared build.gradle.kts scroll down to the code where there are list of iOS and add isStatic = true so your code will look like this :
listOf(
 iosX64(),
 iosArm64(),
 iosSimulatorArm64()
 ).forEach {
 it.binaries.framework {
 baseName = "shared"
 isStatic = true
 }
 }
Next, we will add the compose dependencies to the common main module. Make sure your commonMain variable will have these dependenices :
val commonMain by getting {
 dependencies {
 implementation(compose.runtime)
 implementation(compose.foundation)
 implementation(compose.material)
 @OptIn(org.jetbrains.compose.ExperimentalComposeLibrary::class)
 implementation(compose.components.resources)
 }
 }
it’s ok that they are still marked in red color, since we didn’t sync the project yet. Let’s wait with the sync for a little bit.
Finally, let’s open settings.gradle.kts and add compose repository so all the dependencies can be resolved :
Add this inside Plugin management repositories, as well as inside the Resolution management :
maven("https://maven.pkg.jetbrains.space/public/p/compose/dev")
Then, inside the Plugin management code, add this block of code:
 plugins {
 val kotlinVersion = extra["kotlin.version"] as String
 val agpVersion = extra["agp.version"] as String
 val composeVersion = extra["compose.version"] as String
 kotlin("jvm").version(kotlinVersion)
 kotlin("multiplatform").version(kotlinVersion)
 kotlin("android").version(kotlinVersion)
 id("com.android.application").version(agpVersion)
 id("com.android.library").version(agpVersion)
 id("org.jetbrains.compose").version(composeVersion)
 }
This code takes the configuration we defined and applies the version to the plugins, so in the future we can easily change the versions.
Now we can click the sync Gradle with project files and hope that everything will sync correctly.
Now we will add shared composable functions that will be in use both for Android and for iOS.
Open commonMain package and add inside Kotlin a new file called App
Add App file tha will contain shared composable code
Add some composable content into that file, for example:
@Composable
fun App() {
 var count by remember { mutableStateOf(0) }
 Box(
 Modifier.fillMaxSize(),
 contentAlignment = Alignment.Center
 ) {
 Button(
 onClick = { count++ }
 ) {
 Text("Count: $count")
 }
 }
}
Next, we will need to use this composable function in Android and in iOS.
For android, let’s open our MainActivity and add the new composable function instead of the current code
class MainActivity : ComponentActivity() {
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)
 setContent {
 MyApplicationTheme {
 App()
 }
 }
 }
}
For iOS we need to do some additional steps.
First, let’s open our iosMain package inside AS and add a new file called App and add this function inside the file :
fun MainViewController() = ComposeUIViewController {
 App()
}
This function creates an iOS style view controller that will be a special composable view controller since we are providing our shared composable function — App()
Second, we need to create a new file
Creating a new Composable view for iOS
Lets call it ComposableView swift file and add this content inside the file
import Foundation
import SwiftUI
import shared
struct ComposeView: UIViewControllerRepresentable {
 func updateUIViewController(_ uiViewController: UIViewControllerType, context: Context) {
 }
 
 func makeUIViewController(context: Context) -> some UIViewController {
 AppKt.MainViewController()
 }
 
}
We can see that we are statically calling our previous method MainViewController (from Kotlin) that will hold our composable shared code.
By running the code after the changes, we will see a simple composable views both on Android and on iOS written from same shared code.
Android and iOS are running the same composable code written once in compose.
This step is described very well by Philipp Lackner in his great tutorial video, you can check it out here
Third step — writing a small game engine.
Inside a commonMain package let’s create a Game class and MainGame file.
enum class GameState {
 STOPPED, RUNNING
}
class Game {
 var prevTime = 0L
 var width by mutableStateOf(0.dp)
 var height by mutableStateOf(0.dp)
 var gameState by mutableStateOf(GameState.STOPPED)
 var totalTime by mutableStateOf(0L)

 fun startGame() {
 gameState = GameState.RUNNING
 totalTime = 0L
 }
 fun endGame() {
 gameState = GameState.STOPPED
 }
 fun update(time: Long) {
 val delta = time - prevTime
 prevTime = time
 if (gameState == GameState.STOPPED) return
 totalTime += delta
 }
}
and MainGame composable with separate file.
@Composable
fun MainGame() {
 val game = remember { Game() }
 val density = LocalDensity.current
 LaunchedEffect(Unit) {
 while (true) {
 withFrameNanos {
 game.update(it)
 }
 }
 }
 Column(modifier = Modifier.background(Color(51, 153, 255)).fillMaxHeight().fillMaxWidth()) {
 Row(modifier = Modifier.align(Alignment.CenterHorizontally).fillMaxWidth()) {
 Button({
 if (game.gameState == GameState.STOPPED)
 game.startGame()
 else
 game.endGame()
 }) {
 Text(if (game.gameState == GameState.STOPPED) "Play" else "Stop")
 }
 Text(
 "${(game.totalTime / 1E8).roundToInt() / 10f} seconds.",
 modifier = Modifier.align(Alignment.CenterVertically).padding(horizontal = 16.dp),
 color = Color.White
 )
 }
 Box(modifier = Modifier
 .background(Color.Black)
 .fillMaxWidth()
 .fillMaxHeight()
 .clipToBounds()
 .onSizeChanged {
 with(density) {
 game.width = it.width.toDp()
 game.height = it.height.toDp()
 }
 }) {
 }
 }
}
We can see that we create our Game class and every time there is an update we call game.update(it) This is the heart of the engine, where update called with some times, and we can know how much time took to draw last frame.
if we compile and play our code, we will see a running time.
Running compose engine code — shows the running time
This maybe isn’t much but it’s actually a template for a very basic game, we just don’t have any game objects, and math and nothing but that’s can be easily added as well.
Let’s add some math library so we can use some basic math vectors.
Add this dependency to the commonMain dependencies, this allow us to use vectors with Float2 (by RomainGuy)
implementation ("dev.romainguy:kotlin-math:1.5.3")
Now let’s create some basic GameObject and add a basic functionality to it :
abstract class GameObject(
 speed: Float = 0.0F,
 angle: Float = 0.0F,
 position: Float2 = Float2()
) {
 companion object {
 val UNIT_X = Float2(1.0f, 0.0f)
 }
 var speed by mutableStateOf(speed)
 var angle by mutableStateOf(angle)
 var position by mutableStateOf(position)
 var movementVector
 get() = (UNIT_X.times(speed)).rotate(angle)
 set(value) {
 speed = length(value)
 angle = value.angle()
 }
 abstract val size: Float // Diameter
 open fun update(realDelta: Float, game: Game) {
 val obj = this
 val velocity = movementVector.times(realDelta)
 obj.position = obj.position.plus(velocity)
 }
}
Then let’s create a BallData class that will be inherited from this game object :
class BallData(
 ballSize: Float = 20f,
 val color: Color = Color.Red,
 var isEnabled: Boolean = true
) :
 GameObject() {
 override var size: Float = ballSize
 override fun update(realDelta: Float, game: Game) {
 if (!isEnabled) return
 super.update(realDelta, game)
 if (xOffset > game.width - size.dp || xOffset < 0.dp) {
 movementVector = movementVector.times(Float2(-1f, 1f))
 if (xOffset < 0.dp) position.x = 0f
 if (xOffset > game.width - size.dp) position.x = game.width.value - size
 } else if (yOffset > game.height - size.dp || yOffset < 0.dp) {
 movementVector = movementVector.times(Float2(1f, -1f))
 if (yOffset < 0.dp) position.y = 0f
 if (yOffset > game.height - size.dp) position.y = game.height.value - size
 }
 }
}
We handle the logic of the ball inside the update method, once the ball hits the walls, we change the vector direction.
Let’s add some code to our Game class that will handle the balls in the game.
class Game {
 var prevTime = 0L
 var gameObjects = mutableStateListOf<GameObject>()
 var gameState by mutableStateOf(GameState.STOPPED)
 var gameStatus by mutableStateOf("Let's play!")
 var totalTime by mutableStateOf(0L)

 fun startGame() {
 gameObjects.clear()
 repeat(10) {
 val ball = BallData(
 ballSize = random(25, 45),
 color = Color(
 red = Random.nextFloat(),
 green = Random.nextFloat(),
 blue = Random.nextFloat()
 )
 )
 ball.position = Float2()//Float2(width.value / 2.0F, height.value / 2.0F)
 ball.movementVector = Float2(1f, 0f)
 ball.speed = random(0, 8) + 16f
 ball.angle = random(0, 15) + 30f
 gameObjects.add(ball)
 }
 gameState = GameState.RUNNING
 gameStatus = "Good luck!"
 totalTime = 0L
 }
 fun update(time: Long) {
 val delta = time - prevTime
 val floatDelta = (delta / 1E8).toFloat()
 prevTime = time
 if (gameState == GameState.STOPPED) return
 for (gameObject in gameObjects) {
 gameObject.update(floatDelta, this)
 }
 val allDisabled = gameObjects.filterIsInstance<BallData>().all {
 !it.isEnabled
 }
 if (allDisabled && gameState == GameState.RUNNING) {
 winGame()
 }
 totalTime += delta
 }
 fun endGame() {
 gameObjects.clear()
 gameState = GameState.STOPPED
 gameStatus = "Better luck next time!"
 }
 fun winGame() {
 gameState = GameState.STOPPED
 gameStatus = "Congratulations!"
 }
 var width by mutableStateOf(0.dp)
 var height by mutableStateOf(0.dp)
}
We are creating 10 random balls and add them to game objects array, when game starts. Then for every update of the game, we call to the update for each ball, so each ball can move.
Once game ended, we clear all the objects. 
This is the main game loop.
In order for code to work we are using some extension methods, create file called GameExtensions.kt and add this code
val GameObject.xOffset: Dp get() = position.x.dp
val GameObject.yOffset: Dp get() = position.y.dp
inline val Float.asRadians: Float get() = this * 0.017453292f
inline val Float.asDegrees: Float get() = this * 57.29578f
fun Float2.angle(): Float {
 val rawAngle = atan2(y = this.y, x = this.x)
 return ((rawAngle / PI) * 180F).toFloat()
}
fun Float2.rotate(degrees: Float, origin: Float2 = Float2()): Float2 {
 val p = this - origin
 val a = degrees.asRadians
 val w = Float2(
 p.x * cos(a) - p.y * sin(a),
 p.y * cos(a) + p.x * sin(a)
 )
 return w + origin
}
fun random(min: Int, max: Int): Float {
 require(min < max) { "Invalid range [$min, $max]" }
 return min + Random.nextFloat() * (max - min)
}
Now let’s create a representation of a ball in compose :
@Composable
fun Ball(ballData: BallData) {
 val ballSize = ballData.size.dp
 Box(
 Modifier
 .offset(ballData.xOffset, ballData.yOffset)
 .size(ballSize)
 .clip(CircleShape)
 .background(ballData.color)
 .clickable { ballData.isEnabled = !ballData.isEnabled }
 )
}
and finally let’s use this inside our main game composable :
@Composable
fun MainGame() {
 val game = remember { Game() }
 val density = LocalDensity.current
 LaunchedEffect(Unit) {
 while (true) {
 withFrameNanos {
 game.update(it)
 }
 }
 }
 Column(modifier = Modifier.background(Color(51, 153, 255)).fillMaxHeight().fillMaxWidth()) {
 Row(modifier = Modifier.align(Alignment.CenterHorizontally).fillMaxWidth()) {
 Button({
 if (game.gameState == GameState.STOPPED)
 game.startGame()
 else
 game.endGame()
 }) {
 Text(if(game.gameState == GameState.STOPPED) "Play" else "Stop")
 }
 Text(
 game.gameStatus,
 modifier = Modifier.align(Alignment.CenterVertically).padding(horizontal = 16.dp),
 color = Color.White
 )
 Text(
 "${(game.totalTime / 1E8).roundToInt() / 10f} seconds.",
 modifier = Modifier.align(Alignment.CenterVertically).padding(horizontal = 16.dp),
 color = Color.White
 )
 }

 Box(modifier = Modifier
 .background(Color.DarkGray)
 .padding(50.dp)
 .border(BorderStroke(2.dp, Color.Red))
 .fillMaxWidth()
 .fillMaxHeight()
 .clipToBounds()
 ) {
 Box(modifier = Modifier
 .background(Color.Black)
 .fillMaxWidth()
 .fillMaxHeight()
 .clipToBounds()
 .onSizeChanged {
 with(density) {
 game.width = it.width.toDp()
 game.height = it.height.toDp()
 }
 }) {
 game.gameObjects.forEach {
 when (it) {
 is BallData -> Ball(it)
 }
 }
 }
 }
 }
}
These lines
game.gameObjects.forEach {
 when (it) {
 is BallData -> Ball(it)
 }
}
means that we are “drawing” the composable ball, and each ball will move by itself (once it’s position will change)
We also enable / disable the ball once it’s clicked, so for our game to end we count the number of disabled balls and when all balls are disabled, we win.
val allDisabled = gameObjects.filterIsInstance<BallData>().all {
 !it.isEnabled
}
if (allDisabled && gameState == GameState.RUNNING) {
 winGame()
 }
Let’s run the games and we will get :
Balls compose game in Android & iOS
I hope that these examples can help you get started with developing your own game using Jetpack Compose Multiplatform with Kotlin.
Please don’t hesitate to contact me with any questions.
Full source code :
GitHub - jazzyjester/BallsComposeKMP: Balls compose game for Android and iOS
Happy Koding !

How to write games for Android and iOS with Kotlin in Jetpack Compose ? was originally published in Autodesk TLV on Medium, where people are continuing the conversation by highlighting and responding to this story.

Shape the world,
shape your future.

Design it.
Build it.
Autodesk it.

Our product.

Shape the world,
shape your future.

Design it.
Build it.
Autodesk it.

Our product.

Shape the world,
shape your future.

Autodesk Construction Cloud

Collaboration at its best

A Day At The Office

Our Blog

Podcast

Autodesk handles software design and development that affects the lives of hundreds of millions of people around the world on a daily basis. Autodesk Israel supports the creation of a varied work environment for the development of innovative technologies, alongside an original and creative design.

Links

Design it.Build it.Autodesk it.

Autodesk Construction Cloud

Collaboration at its best

A Day At The Office

Our Blog

Podcast

Design it.
Build it.
Autodesk it.