I have a use case where a user will input some data in my WeWeb front end, click a submit button that will trigger a workflow to validate that data, run some custom javascript to process that data, then pass the result to a Supabase backend. This will trigger a backend function that will in turn return some data.
I have all of this working well so far, but I don’t know how to approach this next bit: I need to pass the data returned by my backend function back to WeWeb to run some more custom JS on the returned data before displaying a result to the user.
I have the ability to make an HTTP request in my backend function so my first idea for a solution would be to use that to send the data back to WeWeb and trigger a workflow with custom js but I don’t know if that’s possible/how to achieve that in WeWeb? Would I set something up to listen to those requests with custom js in a page workflow?
I’m sure the answer to this would be more obvious if I was a more experienced web dev but here we are! Any help will be appreciated
Are you making a request to your backend function? How long does it takes to process the data in the backend? if it is quick enough just return the data from the first request and it will be available as result of the http request action. if you can’t wait for the completion of the work on the backend and need to communicate with the client once it’s done then you have some other options:
write the result in a supabase table with realtime enabled, set it in the plugin too and get the realime data automatically
write the result in the db and poll requests to see if the data is there
use any third party solution for realtime messages
Thank you for your response! Currently I have a trigger in the backend on insert on a certain table. Function runs pretty fast. You’re right, I guess I could use the REST API action in WeWeb to call the function directly instead of using the Supabase plugin insert action, then I can get the function output in the response and hopefully that’s available in following steps of the workflow?
Otherwise I don’t think Supabase realtime helps here because again I need to pass the result through some JS before displaying to the user. I think polling should work for that but idk how to implement that in WeWeb. I’m open to a third party solution but I feel it shouldn’t be necessary here?
then you need to go with the realtime table or create a connection for realtime messages (third party service, your own websocket server or server sent events) before starting your logic.
If the processing time is reasonably short I would refactor it to send a request to the backend and waiting for the result.
Yep I agree, I think refactoring makes the most sense here, I’ll give that a shot! I’m still not convinced realtime would solve my issue anyway although I probably will set it up just for better UX.
Update: I just realized I can likely do everything I need in a single custom javascript module in my WeWeb workflow: take input, validate and pre-process, pass it as an argument in a remote procedure call to my backend function, get the result, process it some more, and spit out the result to display to the user.
Thanks @dorilama, your input really helped get this to click for me
This is an interesting thread. More of a philosophical question than a technical one. What do folks consider best practice for where this business logic lives? I have been running under the assumption that anything in the front-end (WeWeb) is viewable by the user and so have been working to keep all proprietary business logic in my back-end. Is this the right approach?
How are others thinking about where business logic should go?
Thanks,
Aaron
PS: This was sparked by this thread so posting it here, but unsure if this should be it’s own post.
Well I was in search of a technical solution to my problem haha but I get what you mean, it does lead to more open-ended questions.
I’m also curious to hear from others on this. I am by no means an expert but from what I understand the “best” approach is highly dependent on your particular use case. That’s where systems architecture comes in, right?
I think you’re right that we should assume everything in the front-end is exposed. I have a good reason for wanting to do what I described in this thread the way I’m describing it, that has to do with performance and latency.
I also know there’s a school of thought that says absolutely no logic should happen in your backend (database). I’m not sure where logic you don’t want exposed should live in that case, some intermediate layer?
Honestly this might warrant its own thread, it would be great to hear from more seasoned devs on this topic.
Yes. proprietary code should be either obfuscated or ram in the cloud on a vps or in edge functions or the like.
Xano for example is part database. Part backend server meant to execute business logic.
Most apps have a mix of both things. Particularly anything that requires “super admin” privileges should probably occur on the backend. Anything that requires private keys like Algolia write/edit/delete keys for example.
You just want to make your backend return a JSON response, set up a REST API plugin collection and fetch that collection in your workflow, then use the returned data in the next workflow action. Unless I misunderstood you.
