You may encounter performance issues when using Entity Framework as your object-relational mapper. These performance issues can cause your apps to run slowly and become less effective. Common causes include incorrect settings, slow bulk operations, and excessive memory usage when tracking many entities. Default change tracking can quickly consume resources. Utilizing methods like AsNoTracking can help your app perform better for read-heavy queries. If you use EF to enforce domain rules and leverage the Fluent API, you can prevent some performance issues. By learning key performance tips, you can avoid these issues and optimize EF Core’s efficiency. Monitor how your app interacts with the database and identify performance issues early before they impact your users.

Key Takeaways

• Watch how your app works by using tools like EF Core logging and SQL Server Profiler. These tools help you find slow queries so you can make them faster.
• Use Eager Loading with the Include method. This helps stop the N+1 query problem. It gets related data in one query, so your app works better.
• Use AsNoTracking for read-only queries. This makes your app faster and uses less memory. It is very helpful for web APIs that just show data.
• Use pagination with Skip() and Take(). This helps you handle big data sets well. It stops your app from getting slow or crashing.
• Use bulk operations when you add, change, or delete lots of records. This makes your database work much better.

8 Surprising Facts About Entity Framework

1. Entity Framework can generate very different SQL for the same LINQ query depending on minor changes in expression structure, which can unexpectedly impact performance.
2. Lazy loading, while convenient, can cause the "N+1" query problem by issuing many small queries; disabling it and using explicit eager loading or projection often improves entity framework performance issues.
3. Change tracking adds runtime overhead even for read-only operations; using AsNoTracking() can dramatically reduce memory use and speed for large result sets.
4. Complex type mappings and inheritance hierarchies can produce inefficient joins and discriminator checks that lead to unexpectedly slow queries.
5. Query translation limits mean some C# methods are evaluated in memory after fetching data, potentially pulling more rows than necessary and worsening entity framework performance issues.
6. LINQ-to-Entities cannot always reuse parameterized query plans the same way raw SQL does; small differences in queries can prevent plan reuse and increase database CPU.
7. Bulk operations are not optimized by default; performing many inserts/updates/deletes one-by-one causes round-trips—using third-party bulk libraries or raw SQL fixes this.
8. First-level caching (DbContext lifetime) can hide duplicate loading costs or, if a context lives too long, cause memory bloat and stale data; managing context scope is crucial for avoiding entity framework performance issues.

Identifying EF Performance Issues

Common Signs of Slow Performance

Your app might run slower than you want. This can mean there are problems with your entity framework core setup. Watch for these signs and use good habits to fix them:

If you notice slow queries or high CPU use, look at how your queries work with the database. Sometimes, missing indexes or bad queries cause these issues. You can make things faster by checking your queries and adding indexes where needed.

Tools for Performance Visibility

You need helpful tools to find and fix slow spots in entity framework core. These tools show what happens in the background and help you see how your app performs.

• EF Core logging (ILogger)
• MiniProfiler
• SQL Server Profiler
• Visual Studio Diagnostic Tools

These tools let you check how long queries take, find extra database calls, and spot bad SQL from LINQ. For example, entity framework core lets you see command times with easy logging. If you set logging to Information, you can see each command and how long it takes. This helps you find slow parts fast.

You can also use tools like Glimpse and Performance Counters for more details. Using these tools gives you a clear view of performance and helps you make smart choices to improve your ef apps.

N+1 Query Problem in Entity Framework Core

What is N+1?

The n+1 problem happens when you load related data in a way that causes many extra queries. In entity framework core, this often appears when you access related data inside a loop. For example, you might fetch 100 orders. Then, for each order, you access the customer property. This triggers one query for all orders and then 100 more queries for each customer. You end up with 101 queries instead of just one. This slows down your app, especially when you have lots of data. You may not notice this issue with small datasets, but it becomes a big problem in production.

Detecting N+1

You can spot the n+1 problem by watching how many queries your app sends to the database. Here are some ways to detect it:

• Enable SQL logging to see every query that runs.
• Use profiling tools to check query performance.
• Monitor the number of queries. If you see many queries for a small result, you might have an n+1 problem.
• Test your app with large data sets, similar to what you use in production.

Tip: Always check your logs and profiling tools after you add new queries or change how you load related data.

Fixing N+1 with Eager Loading

You can fix the n+1 problem in entity framework core by using eager loading. Eager loading lets you fetch all the data you need in one query. You do this by using the Include method. This tells ef to join related tables and get everything at once. For example, if you want to get authors and their books, you can write:

var authorsWithBooks = context.Authors.Include(a => a.Books).ToList();

This code runs a single query that joins authors and books. Your app gets all the data in one go. Eager loading reduces the number of queries and makes your app faster. You should use eager loading when you know you need related data right away. This helps you avoid slowdowns and keeps your app running smoothly.

Inefficient Queries and Query Optimization

Causes of Inefficient Queries

Sometimes, ef core queries can run slowly. There are many reasons for this. Check the table below to see the main causes:

If your queries are slow, look for these problems.

Analyzing Generated SQL

You can make ef core queries better by checking the sql they create. When you write linq queries, entity framework core turns them into sql. Sometimes, the sql is too big or has extra joins. You should look at the raw sql to see if it is what you want. Use logging tools to see the sql and find problems. For example, using multi-level Include can make big results and slow things down. You can use split queries to break up hard queries and make them faster. Always check the sql to find slow spots and make things better.

Performance Tips for Query Optimization

Here are some ways to make your ef core queries faster:

1. Use pagination with Skip() and Take() to get small pieces of data instead of everything.
2. Use AsNoTracking() for read-only queries to use less memory and make things faster.
3. Use async methods so your app can do other things while waiting for the database.
4. Pick the right loading strategy. Choose lazy loading or eager loading based on what you need.
5. Use split queries to stop big joins and cut down on extra data.
6. Use compiled queries to make repeated queries faster.
7. Use AddDbContextPool to reuse context instances and help busy apps run better.

It is important to know how ef core queries work. This helps you write good queries and get the best speed from your database. Always test your queries with real data and watch how much memory and time they use. Streaming results can also help when you have lots of data.

Tracking and No-Tracking in EF Core

Tracking Impact on Performance

Entity framework core keeps track of every entity you load. This is the default setting. Tracking helps ef know if you change something. But tracking can slow your app down. It is slower with big data sets. You may see your app use more memory. Queries can also take longer when tracking is on. The table below shows how tracking changes performance:

Using asnotracking makes queries faster. It also uses less memory. Your app can answer faster and help more users at once.

Tip: If you turn off tracking, your queries run faster. This is best when you only need to read data.

When to Use AsNoTracking

Use asnotracking if you do not want to update or delete the data. Most web APIs just read data. About 70-80% of endpoints only show information. These work better with asnotracking. Here are some good times to use it:

• Reports and dashboards that only show data
• API responses that give lists or details to display
• Search or filter endpoints that only read from the database

Turning off tracking in these cases makes your app faster. Asnotracking is important for read-only situations. It stops extra work from tracking every entity.

Best Practices for Tracking

Entity framework core tracks changes so you can update data. For normal use, keep AutoDetectChangesEnabled set to true. If you add or update many records at once, turn off AutoDetectChanges. This makes things faster. For example, adding thousands of rows is much quicker this way. It can go from over 40 minutes to under 3 minutes. You can use tools like EFCore.BulkExtensions to make bulk work even faster. Always turn AutoDetectChanges back on after you finish bulk work.

Remember to use asnotracking for read-only queries. Use tracking when you want to update data. This gives you the best speed and keeps your data safe.

Loading Strategies and Performance

Eager vs Lazy Loading

There are different ways to get related data in entity framework core. The two main ways are eager loading and lazy loading. Eager loading uses the .Include() method. It gets all the related data in one query. Lazy loading waits until you use the related data. Then it runs a new query each time you access it. This can make lots of extra queries and slow things down.

Here is a table that shows the main differences:

Eager loading is good when you need related data right away. Lazy loading gives you more choices, but it can cause the N+1 problem. Your app might run many queries if you loop through related items.

Tip: Pick eager loading if you want to stop extra database calls and make your queries faster.

Choosing the Right Strategy

You need to choose the best way to load data for your app. Eager loading is best when you always need the related data. Lazy loading is helpful if you want your first query to be small. But you should watch out for hidden slowdowns. Explicit loading lets you decide when to get related data. This is good for big data sets or when you want more control.

Here is a table to help you decide:

• Use eager loading if you know you will need the data.
• Use lazy loading for more options, but check for extra queries.
• Use explicit loading if you want the most control or have lots of data.

You can make entity framework faster by picking the right way to load data for each case. Always test your queries and see how your app works.

Pagination and Large Data Sets

Problems with Large Data Loads

When you use ef with lots of data, you can have big problems. Loading too much at once can make your app slow or even crash. Here are some things that can happen:

• Your app might use too much memory and run out.
• It can take a long time to get answers because there is too much data.
• The database might stop working if you try to load too much at once.

The N+1 selects problem has been a problem for databases for a long time. It means your app sends many small queries instead of one big one. This can make things much slower.

If you do not use the right way to get data, your app might freeze. You should not load all the records at the same time. This helps your app stay healthy and keeps users happy.

Efficient Pagination in EF Core

You can fix these problems by using pagination. Pagination splits your data into smaller pieces. This makes your app faster and easier to use. In ef, you can use Skip() and Take() to do this. Skip lets you move past some records. Take gets only the number you want. This helps you work with big data and keeps your app running well.

• Getting lots of data without pagination can slow things down.
• Your app can use too much memory and get slow if you do not use pagination.
• Pagination is important to keep your app working well.

If you use ToList() to get everything, your app can slow down or stop. Instead, just get the data you need for each page. This keeps memory use low and makes your app answer fast.

Offset pagination is simple with Skip and Take. But for really big tables, keyset pagination can be better.

Keyset pagination is a better way for big data. It does not skip rows. It starts after the last record you got. This makes it faster and more steady.

Pick the best way to use pagination for your app. This will help your app stay quick and work well, even with lots of data.

Quick Wins for EF Performance

Using DTO Projection

You can make your app faster by using DTO projection. DTO means Data Transfer Object. With DTOs, you only pick the fields you need from the database. This makes your queries quicker and saves memory. Here are some good things about using DTOs:

• You get less data, so queries finish faster.
• Your app uses less memory and sends smaller data over the network.
• You choose just the properties you want, which helps with big data or busy APIs.

DTO projection is great when you want to show lists or details but not every property. This keeps your app light and quick.

Compiled Queries

Compiled queries help your app run faster if you use the same query a lot. EF lets you compile queries so they work quicker. Use compiled queries where speed is very important. Here is a table that shows the good and bad sides:

Use compiled queries for busy APIs, background jobs, and places where the same query runs many times each second. Compiled queries can make things 8 to 12 percent faster, but they are best for special cases. Do not use them for rare or changing queries.

Async Operations

Async operations help your app handle more users and stay fast. When you use async methods, your app does not stop and wait for the database. This means your app can do other things at the same time. It is important for busy websites. Async APIs keep your app quick even when lots of people use it. You should use async/await in your queries to help your app run well.

Caching Strategies in Entity Framework

Query Caching Basics

Caching makes your app faster by saving data or query plans. When you use ef, there are different kinds of caching. Each kind helps in its own way and works best in certain cases.

You can use results caching, also called second-level caching, with tools like NCache. Entity Framework 5 can save LINQ queries for you with autocompiled queries. If you change how you write a query, ef might make a new plan and not use the saved one.

Tip: Caching is best when you run the same queries a lot or your data does not change often.

When to Use Caching

Use caching for data you look up many times or that takes a long time to get. Data that does not change much, like country or currency lists, is great for caching. Big API answers also work well with caching.

• Caching helps when you need the same data a lot.
• Use caching for things that slow your app down.
• Data that stays the same gives you the most help from caching.
• Always set rules to clear old cache so your data is right.

If you cache data that changes a lot, you might show old info. Make sure you update or clear the cache when the data changes. Caching makes your app answer faster and helps your database do less work.

Bulk Operations and Batching

Bulk Insert, Update, Delete

You can make your database work faster with bulk operations. These methods let you change many records at the same time. Standard EF methods are fine for small jobs. But they get slow when you have lots of data. Bulk operations help you insert, update, or delete thousands of rows quickly. You might use them when you import data from CSV files. They also help when you sync records or do nightly updates.

Here is a table that shows how much faster bulk operations are than standard EF methods:

You can see that bulk operations are much faster. They are great for big jobs like moving lots of data or updating inventory.

Batching for Better Performance

Batching lets you group actions so your app works faster. You can use batch updates with UpdateRange() to change many things at once. Try not to call SaveChanges() too often. Each call sends data to the database. EF Core 7 has new methods like ExecuteUpdate and ExecuteDelete for bulk changes.

Here are some ways to batch your work:

• Use UpdateRange() for batch updates.
• Call SaveChanges() less to cut down on database trips.
• Try ExecuteUpdate and ExecuteDelete in EF Core 7 for faster bulk changes.
• Pool your DbContext to use it again and lower extra work.
• Turn off change tracking for read-only queries.
• Use streaming for big data sets.

You can use code like this to batch updates:

public void BatchUpdateAuthors(List<Author> authors)
{
    var students = this.Authors.Where(a => a.Id > 10).ToList();
    this.UpdateRange(authors);
    SaveChanges();
}

For EF Core 7 or later, you can use:

_context.Authors.Where(a => a.Id > 10).ExecuteUpdate();

Batching and bulk operations help your database work better. You can finish big jobs fast and keep your app running well.

Indexing and Database Optimization

Impact of Indexes on Performance

Indexes help your database find data faster. When you search for something, the database looks at the index first. This makes your app answer more quickly. But if you add or change records a lot, indexes can slow things down. The database has to keep the index updated every time you change data.

• Indexes make finding rows faster for your queries.
• Composite indexes are good when you filter by more than one column. The order of columns in a composite index is important for speed.
• If your queries use special expressions, you can use persisted columns or expression indexes. These help with hard searches.

You need to have the right number of indexes. Too many indexes can make updates slow. Not enough indexes can make searches slow. Always check your queries and change indexes to get the best speed.

Managing Indexes in Migrations

When you change your database with migrations, you should watch your indexes. Add indexes to columns you search a lot. This helps your database work faster and keeps your app smooth. You can set up indexes in your ef model so they are made in the database for you.

You can add an index in your ef model like this:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Book>()
        .HasIndex(b => b.Title)
        .HasDatabaseName("Index_Title");
}

Check your database every time you do a migration. Make sure you add indexes to columns people search or filter. Take away indexes you do not need. This keeps your database neat and fast. You can use tools to find slow queries and add indexes where they help most.

If you plan your indexes well, your database will do searches and updates better. Your ef apps will run faster and work better.

Context Lifetime and Connection Management

DbContext Lifetime Best Practices

You must watch how long you use DbContext. If you use it too long, your app can slow down. It is best to make a new DbContext for each job. For example, make one for each web request or background task. This stops memory leaks and keeps your data up to date.

Here is a table with tips for using DbContext:

Use AsNoTracking if you just want to look at data. This makes your queries run faster and saves memory. Try not to use lazy loading. It can make your app send extra calls to the database and slow things down.

Tip: Always get rid of your DbContext when you are done. This keeps your app working well and stops memory leaks.

Efficient Connection Handling

You should open a database connection only when you need it. Close it right after you finish. This helps your database not run out of connections.

DbContext pooling can help if your app is very busy. Pooling saves time by reusing DbContext objects. This can make your app faster, but you must be careful. Do not use the same DbContext in more than one thread.

Never keep a DbContext for too long. Use it for one job, then let it go. This keeps your app quick and your data safe. Good connection habits help your ef app work well and handle more users.

You can make ef faster by using smart methods. Use Include or projection so you do not get N+1 queries. Add AsNoTracking when you only read data. Pick just the columns you need. Make sure your filters turn into SQL. Group your changes and save them all at once. Put indexes on columns you filter for quicker searches. Use IDbContextFactory for background jobs. Compiled queries are good for requests that happen a lot.

Check your app often with tools like Visual Studio Profiler or dotTrace. Look at your database and how you write queries. This helps your app stay quick and work well.

Optimizing EF Core Query Speed — Checklist

Focus: entity framework performance issues and practical steps to speed up EF Core queries.

• Measure baseline: capture query execution time and SQL generated using logging (EnableSensitiveDataLogging, LogTo) and aprofiler before making changes.
• Use asynchronous queries: prefer ToListAsync/FirstOrDefaultAsync/SingleOrDefaultAsync to avoid blocking threads.
• Project only needed columns: use Select to return DTOs or anonymous types instead of entire entities.
• Avoid unnecessary tracking: use AsNoTracking for read-only queries to reduce change-tracking overhead.
• Filter early: apply Where clauses before Select/Include to reduce data transferred from database.
• Limit results: use Take/Skip for pagination and avoid loading full tables.
• Avoid N+1 problem: use Include/ThenInclude or explicit batch queries to load related data efficiently.
• Prefer explicit joins or Select with navigation access when Include causes excess data duplication in SQL.
• Use compiled queries for frequently executed parameterized queries to reduce LINQ-to-SQL translation cost.
• Optimize query translation: simplify complex client-side expressions that force client evaluation; keep operations translatable to SQL.
• Check generated SQL: inspect queries for unnecessary DISTINCT, subqueries, or CROSS JOINs and refactor LINQ accordingly.
• Use proper indexes: ensure database has indexes that match query predicates and sort orders used by EF Core queries.
• Avoid loading large result sets into memory: stream results or use pagination and server-side projections.
• Batch database calls: use ExecuteUpdate/ExecuteDelete where appropriate and combine multiple operations when safe.
• Use connection pooling and efficient DbContext lifetime: keep DbContext short-lived and avoid creating per-operation overhead.
• Cache static data: use memory cache or distributed cache for rarely changing lookup data instead of querying DB each time.
• Be careful with eager loading depth: limit Include chains to necessary relationships to avoid overly complex joins.
• Use raw SQL or stored procedures for highly complex or performance-critical queries when LINQ cannot generate optimal SQL.
• Avoid heavy client-side evaluation: ensure computed operations are translated to SQL or moved to the database via SQL functions.
• Monitor and tune EF Core change tracking: use ChangeTracker.AutoDetectChangesEnabled = false during bulk operations and re-enable afterward.
• Use bulk extensions for mass inserts/updates/deletes to avoid thousands of individual commands.
• Profile and load-test after each change: confirm fixes reduce latency and throughput issues related to entity framework performance issues.
• Keep EF Core and database provider up to date: apply performance-related fixes and improvements from newer versions.

FAQ

What is the N+1 query problem in Entity Framework?

You see the N+1 problem when your app sends many small queries instead of one big query. This happens when you load related data inside a loop. Use eager loading to fix it.

How can you speed up read-only queries in EF Core?

You can use AsNoTracking() for read-only queries. This skips change tracking and makes your queries faster. Your app uses less memory and responds quicker.

When should you use bulk operations in EF Core?

Bulk operations work best when you need to insert, update, or delete thousands of records. You save time and reduce database load. Use tools like EFCore.BulkExtensions for big jobs.

Why do indexes matter for EF Core performance?

Indexes help your database find data faster. You should add indexes to columns you filter or search often. This makes your queries run quickly and keeps your app responsive.

What tools help you find EF Core performance issues?

You can use EF Core logging, MiniProfiler, and SQL Server Profiler. These tools show slow queries and help you spot bottlenecks. Check logs often to keep your app running well.

Why are my EF Core queries slow compared to raw SQL?

EF Core can be slower because an ORM generates SQL queries, tracks net objects and materializes results which adds overhead compared to hand-written sql query or ADO.NET; EF Core may also produce different queries than you expect, or include unnecessary joins and selects. To improve performance, inspect the actual query EF uses, profile the database server, cache queries where appropriate, and consider using compiled queries or write a custom SQL or use dapper for critical paths.

How does the amount of data affect Entity Framework performance?

Large amount of data amplifies ORM overhead: tracking many entities consumes memory and CPU, and sending big result sets across the network stresses database access. Use pagination, projection to DTOs, AsNoTracking for read-only workloads, and avoid loading entire collections. If you need to insert a lot of data, use bulk operations or ADO.NET batching instead of inserting one entity at a time through an EF context.

Should I use Entity Framework Core or EF6 for better performance in a .NET Core app?

EF Core is optimized for the net core and offers modern improvements, but ef 6 has mature behaviors and optimizations for some scenarios. Benchmark your workload: ef core queries are slow in some complex queries but faster in others. Consider the net ecosystem, your existing codebase, and whether you can use dapper or ado.net for hotspots. Often using EF Core with tuned queries and compiled queries yields the best balance.

What common performance problems arise from using an EF context incorrectly?

Creating and disposing contexts too frequently or keeping a long-lived context that tracks many entities causes performance and memory issues. Opening and closing connections is handled by the context, but repeatedly creating contexts can add overhead. Use context per unit of work, avoid long tracking lifetimes, and when reading, use AsNoTracking to reduce the performance penalty of change tracking.

How can I diagnose slow queries generated by EF?

Look at an example by logging the actual query and parameters EF uses, enable database server profiling, and compare execution plans to your hand-written sql query. Use tools in asp.net core or EF logging to capture queries, and check whether EF caches queries or recompiles LINQ expressions; using compiled queries can avoid the first compile cost for repeated queries.

When should I use Dapper instead of Entity Framework?

Use dapper for simple high-performance data access scenarios where you want minimal ORM overhead and direct control of SQL. Dapper maps results to objects quickly and has less tracking overhead than ORMs. For complex queries, or when you need full ORM features like change tracking, EF is useful. Mixing EF and dapper is common: EF for domain modeling and dapper for performance-critical read paths.

How do complex queries impact EF performance and how can I optimize them?

Complex queries may produce inefficient SQL or multiple round-trips; EF may translate LINQ into several different queries or use subqueries that stress the database. Simplify LINQ, project only needed fields, or write raw SQL when necessary. Consider splitting queries, adding proper indexes on the database server, and measuring execution plans to improve performance.

Is there a performance penalty when using ORMs versus ADO.NET?

Yes, using an orm introduces overhead for change tracking, query generation, and materialization compared to manual ADO.NET. The penalty varies by scenario: small CRUD apps see negligible impact, while high-throughput systems may suffer. To mitigate, reduce tracking, use projections, avoid unnecessary queries, or use ADO.NET/dapper for tight loops and bulk operations.

How can I improve performance when inserting a lot of data with EF?

For bulk inserts, disable change tracking temporarily, batch saves (SaveChanges in groups), or use a bulk insert library that uses native database bulk APIs. Avoid inserting one entity and SaveChanges per row. If you must insert a lot of data regularly, consider using ADO.NET or write a custom bulk loader for the database which bypasses EF overhead.

Does EF cache queries and how does that affect performance?

EF Core compiles LINQ to an internal representation and can cache some query plans, but the first compile of a query has cost; repeated similar queries benefit from caching or using compiled queries explicitly. Caching the results at the application layer can also reduce database load. Be careful to cache based on parameters and invalidate when underlying data changes to avoid stale results.

What role does the database server play in EF performance?

The database server is often the bottleneck: slow disk, missing indexes, poor query plans, or resource contention will make ef core queries are slow regardless of ORM choice. Optimize indexes, update statistics, and tune queries at the server. Use execution plans to identify slow operations and adjust either the EF query or the database schema accordingly.

How can I profile and measure Entity Framework performance in ASP.NET Core?

Use EF logging, query tags, and performance profilers to capture the actual query and execution time. Tools like SQL Server Profiler, Query Store, or third-party profilers can show the database perspective. Measure end-to-end latency in the asp.net core app, identify hotspots, and test different approaches (AsNoTracking, compiled queries, dapper) to see measurable improvements.

Is it better to write a custom SQL query or rely on EF for complex reporting?

For complex reporting where the ORM produces inefficient SQL or you need specific optimizations, write a custom sql query or use dapper to execute the query and map results. Reporting often benefits from tuned, hand-crafted queries that the database server can optimize better than the generic SQL generated by EF.

How should I think about EF and the net objects lifecycle to avoid memory leaks?

Think EF in terms of unit of work: creating and disposing contexts per request or per transaction helps prevent accumulating tracked net objects. Avoid attaching large graphs unnecessarily, detach when appropriate, and monitor memory usage. Properly disposing the context and minimizing tracked entities reduces GC pressure and improves performance.

🚀 Want to be part of m365.fm?

Then stop just listening… and start showing up.

👉 Connect with me on LinkedIn and let’s make something happen:

• 🎙️ Be a podcast guest and share your story
• 🎧 Host your own episode (yes, seriously)
• 💡 Pitch topics the community actually wants to hear
• 🌍 Build your personal brand in the Microsoft 365 space

This isn’t just a podcast — it’s a platform for people who take action.

🔥 Most people wait. The best ones don’t.

👉 Connect with me on LinkedIn and send me a message:
"I want in"

Let’s build something awesome 👊