Is it good practice to call an action in a job in wasp?
I have several processes in my app that normally run on cron jobs, but sometimes I want to click a button to run them manually via an admin dashboard (both for testing and for their actual functionality). Is it good practice to just create an action, and call it both from the front end and in a job?
14 Replies
Hi @CamBlackwood. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Yes, it is possible to call an action from a job in Wasp, but there are some considerations to keep in mind.
Actions in Wasp are designed to be called from anywhere in your code, either client or server, and they are typically used to modify the server's state. However, when calling an action from a job, you need to manually provide the context argument, which can be a bit involved. For example, if your action requires user context, you might not have that readily available in a job that is being run by Wasp itself, not by a user.
A suggested approach to reuse logic between actions and jobs is to create a normal JavaScript function (let's call it function X) that contains the logic you want to reuse. Then, both your action and your job can call this function X. This way, you can share as much logic as you want between actions and jobs.
As for the UI update on the client side, if your job edits the database directly, that change won't be automatically picked up by the client. You might want to use websockets to send a message from the server to the client, and then react to that message on the client and update the UI if you wish. Wasp does provide some support for websockets.
For your use case of running processes manually via an admin dashboard, you can certainly create an action that triggers these processes and call this action from the front end. For running these processes on a schedule, Wasp is planning to add support for cron/scheduled jobs in the future.
Here are the relevant knowledge sources:
- Discord support thread: Using actions inside workers - is it possible? (https://discord.com/channels/686873244791210014/1208036265308586034)
- Working with Actions (https://wasp-lang.dev/docs/data-model/operations/actions#working-with-actions)
- Github Issue (closed): Add support for cron/scheduled jobs (https://github.com/wasp-lang/wasp/issues/200)
- RFC: Support for background jobs (https://github.com/wasp-lang/wasp/issues/530)
- Recurring Jobs (https://wasp-lang.dev/docs/advanced/jobs)
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @CamBlackwood, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?
Thanks @kapa.ai , I think I'll keep it seperate for now
Let me check the knowledge base for you. One moment! :books:
----------------------
You're welcome! That sounds like a good plan. Keeping your actions and jobs separate can help maintain clarity in your codebase. If you have any more questions or need further assistance with Wasp, feel free to ask. Happy coding!
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @CamBlackwood, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?
Admin click -> action -> call service to do something
Job -> call service to do something
if an action is an api call you probably dont' want to call your own api from a job jsut ot do something :be:
@Fecony just to give you a bit more context here - I'm introducing some more powerful stats into microinfluencer, but it involves querying those stats on quite an expensive API so I want to just do it in one go at midnight every night, but want to be able to manually call it from an admin dashboard if I want to. Have you done anything like that before?
yeah, tradeoff is if it's expensive to call that API you would prefer to let user run it manually, BUT run it in a queue and then notify user that data/report/whatever is ready
you don't want to let user click it more and more to drain out your limits 😸
it depends ofc.... what is that api and how frequently you want user to let it run, like maybe you can run it manually but then it won't be queried at night?
or can query it once a day + at midnight
anyway in terms of code your job doesn't have to call your own api via action, logic should be extracted from it and called in job, or action
Ah sorry, when I mean admin I mean literally me 🙂 I am the site admin. It's actually a third party api I use (as it is more economical than building my own api for it), which is why I try and limit it. So in the job is:
Query my db => run an api call on the results of the query => clean up the response and format it => write to my db
if it's only you then you don't really need to limit it then, but code wise logic is the same, to extract parts that actually do what you need. like imagine updating react state with api call and not local useState 😸
Yeah that's true, thanks
Aha, it is an action because you query it and store it in the database then? So actino in the sense that it stores stuff in your db?
I think it should be fine to put this logic into action and then call it from the job. I can't remember at this moment i fyou can all an action from the job directly, or if you should extract this logic into a function that then both action and job will call, but as a direction yeah sounds good to me.
gpt answer
My 2 cents: create a common function "calculateStats" which does all the heavy lifting. Use that function in both an action and a job. All they do is just call the function. This way you are keeping this nicely separated but still reusing 99% of the logic.
That makes sense, thanks Miho