Brief: I am rewriting my Connect apps and going pure Forge instead of using the conversion tool. I have a working 0.1 version using back-end API calling–so invokes, routes, resolvers, etc.
Question: I’ve seen both recommended, but nothing that concretely says one way or the other regarding front-end vs back-end product API calls. So before I get too far on the Forge coding, I’d like to make sure I am doing it properly as it could be back-end was the initial way, but now front-end is the better approach (or vise-versa) and that’s why I am seeing recommendations for both.
So my question is should I be making the product API calls from the back-end of front-end of my Forge app? Or does it even matter (i.e., preference).
1 Like
I prefer whichever approach works with the least amount of code. So go for frontend calls like import { requestConfluence } from '@forge/bridge' where available.
I also structure my folder naming like src/frontend and src/backend to make things clearer.
If I was running the show there wouldn’t be terms like “invoke” and “resolver”. They are meaningless and confusing jargon. Atlassian only lazily adopted them because that’s what AWS Lambda uses.
1 Like
If you need product data in your app UI, and don’t need to process this, then I would use call the APIs directly from the frontend.
Added bonus would be that this ay you don’t use Forge Compute and will thus not be billed for the API calls.
If you need to process the data from the product before rendering the UI then it may make sense to use the back-end, but you will see Forge Compute usage for this.
2 Likes
Both are excellent responses and I will be using both. Too bad I could only mark one as the solution, but hopefully this post will let others know that both were solutions for me. 
@markrekveld quick follow up question, would archiving or deleting projects be considered “processing”? Based on your description, I don’t think it is, but I want to be sure that I understand what is meant by “processing” in the Forge world.
Sorry I didn’t mean to suggest Forge has a “processing” meaning or understanding when it comes to picking back-end over front-end.
What I meant with “processing” in this case is,
- “do you use the response of the API call as is” then I would not see this as processing, like getting all the projects a user has access to and list them on a page.
- “you use the response from one API to call other APIs, combine the results and do more with it”, then it would be more likely that I would see this as processing.
Also, you can ask yourself this question, “should the work be done in the browser of the user”, collecting data to show is a ‘easy’ yes so no need for a back-end function call (aka resolver), but more complex work may not be an easy ‘yes’ or a definite ‘no’ then a back-end is the way to go. You would still have the front-end call it through a resolver to kickstart the work, but then the browser is done and the back-end can take over.
@markrekveld Roger that. So currently, I am using resolvers to get “all projects”. Based on your feedback, that is unnecessary and I can do it from the front-end and save on Forge Computes.
Where it gets slightly gray for me is when I archive or delete projects. But I’m thinking this can still be front-end as I’m just collecting the admin’s selection and sending it to the API endpoint.
I’m glad I asked before I got too far as my Forge Compute costs would have been crazy expensive. Lol. Thanks again for the assist @markrekveld and @nathanwaters!!!
1 Like