# Designing Activities

**URL:** <https://community.temporal.io/t/designing-activities/4575>\
**Category:** Community Support\
**Tags:** java-sdk\
**Created:** [April 28, 2022, 9:45pm UTC](https://community.temporal.io/t/designing-activities/4575 "2022-04-28T21:45:05Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![sgrmgj](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/sgrmgj/32/1983_2.png) [@sgrmgj](https://community.temporal.io/u/sgrmgj)\
**Post date:** [April 28, 2022, 9:45pm UTC](https://community.temporal.io/t/designing-activities/4575/1 "2022-04-28T21:45:06Z")

</div>

We are getting started with Temporal to do a major rewrite - I had a question regarding designing activities (which are executed by the workers). Most of the documentation I have seen points to the fact that these activities always call an http or a grpc microservice.  
I assume that technically it is also possible for the activity to directly access a db or any store to mutate a state but is it a recommended approach or is it recommended to execute all logic in a microservice and let the temporal activity orchestrate it ?  
Any guidance or best practices recommendations would help.

---

<div class="post-metadata">

**Author:** ![sgrmgj](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/sgrmgj/32/1983_2.png) [@sgrmgj](https://community.temporal.io/u/sgrmgj)\
**Post date:** [April 28, 2022, 10:22pm UTC](https://community.temporal.io/t/designing-activities/4575/2 "2022-04-28T22:22:51Z")

</div>

I got this answered in the slack conversation - posting the link here for others’ benefit

> **[Slack is where the future works](https://temporalio.slack.com/?redir=%2Farchives%2FCTRCR8RBP%2Fp1651183085281699)**
>
> Slack is a new way to communicate with your team. It’s faster, better organized, and more secure than email.

---

<div class="post-metadata">

**Author:** ![sgrmgj](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/sgrmgj/32/1983_2.png) [@sgrmgj](https://community.temporal.io/u/sgrmgj)\
**Post date:** [April 28, 2022, 10:41pm UTC](https://community.temporal.io/t/designing-activities/4575/3 "2022-04-28T22:41:58Z")

</div>

Capturing all the replies here in text -  
 ![](https://us1.discourse-cdn.com/flex016/uploads/temporal/original/2X/c/ca7525752f5133cdd4c71e742884beeaaef3c9c3.jpeg)

[Rob Zienert]  
Activities can do whatever you like.

[Balchu]  
IMHO plus the fact that one can have an activity instance separate from the workflow instance, having the activity actually do the work, say CRUD actions will be a better approach.  
First and foremost it doesn’t incur extra network hop of calling that other microservice. (edited)

[Sagar Jadhav]  
Thank you [@Rob Zienert] & [@Balchu]- just one followup question - of course every choice is a tradeoff - but curious to know how db connections and cache operations are managed when all the workflow and activity code is structured together

[Sagar Jadhav]  
Ofcourse Connection Pooling and Transaction Mgmt will come in to play in order to productionalize it in case we execute all those actions from the activity itself (edited)

[Rob Zienert]  
Do you mean db connections & caching of Temporal itself, or of application space code? (edited)

[Sagar Jadhav]  
No I mean - let’s say for example - there are three activities in a workflow which basically update some sort of application state (not the temporal ecosystem)

[Sagar Jadhav]  
so yes application space code

[Rob Zienert]  
In that case, the answer there is completely dependent on the needs of your application(s). Temporal isn’t a factor.

[Rob Zienert]  
You can think of an activity as an endpoint in a microservice. In fact, we have entire services that _only_ expose their functionality via activities.

okay cool - thank you [@Rob Zienert] that helps