Rust Diesel Questions on data insertion and caching

[vocal remnant]

Hi, I'm not very seasoned with Rust so I have a few questions about general techniques and methods.

1. In Rust, it seems that I would need to clone string to re-use them later, is that a appropriate approach ?
2. For Diesel, what is the proper way to handle data insertion and data updating ? (Additionally, data upserting)
3. For caching, what is the suitable approach for it, for this specifically, it is for situation where the data is shown on a front-end html table, which currently fetches data from database directly on HTTP API call, which on further observation, successfully soft-locks the database access pool one or two times already. Thus, what should I do to replace direct database fetch?

[eager prairie]

For Diesel, what is the proper way to handle data insertion and data updating ? (Additionally, data upserting)

Checkout the relevant guides: https://diesel.rs/guides/all-about-inserts/ and
https://diesel.rs/guides/all-about-updates/.
Additionally there are some more details in the published workshop material from last years RustWeek Diesel workshop: https://blog.weiznich.de/rustweek_2025.html#/insert-statements (Press s to get the speaker notes with more details)

For caching, what is the suitable approach for it, for this specifically, it is for situation where the data is shown on a front-end html table, which currently fetches data from database directly on HTTP API call, which on further observation, successfully soft-locks the database access pool one or two times already. Thus, what should I do to replace direct database fetch?

That rather sounds like an issue with the connection pool to me. How many concurrent requests are you expecting to deal? Which pool, which database backend do you use?

[vocal remnant]

postgresql backend, bb8 pool via diesel-async
there would be two types, one to write data into the database (updating data), while the other is for front end display (expected to update every 2 update for EVERY potentially connected client interface)

[vocal remnant]

much appreciated for the guides

[eager prairie]

How did you configure the pool? I'm asking because crates.io is using a similar setup (deadpool instead of bb8 as far as I remember), and they don't run into any soft-locks in the database pool.

[vocal remnant]

pool built in main function, and handed over to actix/tokio through cloning the object in web::Data
also, from what I am seeing before, the soft-lock were caused by a single client spamming the API to fetch data (which directly get from database)

the spamming is probably caused by my awful javascript logic (which handles the 1 request cycle every 2 minute thing), but that probably shouldn't be able to get the database request stuck

[eager prairie]

It might be a good idea to verify your connection pool size and the timeout settings for the pool. Also you want to make sure that each request to the "backend" checks out exactly one database connection from the pool and hands that connection down to all relevant database calls. That ensures you don't run out of connection that quickly.
And yes, also optimizing your frontend to not perform that many individual calls to the backend might be an option.

[vocal remnant]

for the frontend optimization, any recommended approach for setup scenarios where the software would be expected to be accessible by public?

[eager prairie]

Measure and see where it breaks 🙈
Honestly, I wouldn't start optimizing much until I see a bottleneck anywhere. Yes breaking is not great, but there is no need to put in work for optimizations that wouldn't be required in the first place. You only learn what's actually required for your use-case if you observer where it is breaking. Thats then the point that needs additional optimizations. And those are often much better scoped than a general "I need to have this thing as fast as possible" statement.