[Question] How to globally add context (e.g., user locale) to all requests?

[aleksolutions]

Hi team,

First off, thanks for the great work on forge-trpc - it's significantly improved our development experience!

I have a question regarding requests: Is there a recommended way to automatically include additional context, specifically the user's locale, with every request? The goal is to access this locale within the server-side context/handler for each mutation.

Currently, I'm passing the locale manually with each call. I'm wondering if there's a cleaner, global approach, perhaps by extending a shared context or using some form of middleware provided by the adapter.

Thanks for any guidance!

[tbinna]

Hey @aleksolutions,

Currently, forge-trpc does not provide anything beyond the basics. The main reason is that this may introduce opinions on technology choices incompatible with everyone's stack.

I assume you want to pass the locale along because you do not get this from the Forge resolver context.

I think, if this is a common use case, we can consider adding a package to provide helpers. However, I would only do this if there is a strong indication that many library users will use it.

In our Forge code, we have a few validation helpers for the Forge resolver context and further tRPC middleware to filter requests based on what the RPC route is supposed to allow or block. For example, we have middleware to whitelist the Forge modules from which an RPC route can be called, or a middleware to validate permissions against the user associated with the request.

Some of these middlewares could be published as a separate package, provided they remain mostly technology-neutral (apart from what we already have). For example, Forge context validation middleware could be implemented with Standard Schema, which seems to be becoming the go-to abstraction for schema validation libraries.

I would be curious to hear from others if you have similar use cases. What's the general opinion on this? Would this be useful, or should this project remain focused on just offering the basics?

[aleksolutions]

Hi @tbinna,

Thanks a lot for the quick and detailed response! I really appreciate you taking the time to explain the reasoning behind the current design.

You are exactly right in your assumption – the need to pass the locale arises because, for reasons we haven't quite figured out on the Atlassian side, it's unfortunately not included in the standard Forge resolver context. This feels particularly relevant now with the rollout of the official Forge i18n system, as having the user's locale readily available on the backend is crucial for returning properly localized responses, especially error messages. Ideally, this would be part of the standard Forge context, but in its absence, we need a way to bridge that gap.

We did consider the alternative of fetching the locale from a backend API call impersonating the user, but as you might expect, the added latency makes it impractical for many use cases, so we discarded that option.

Regarding your point about keeping the adapter minimal and avoiding opinionated technology choices, I completely understand and agree with the principle. With that in mind, perhaps a more technology-neutral approach could be considered? I was wondering if it might be feasible to add an option to the adapter's configuration that allows users to provide a function or mechanism to inject additional, arbitrary properties into the tRPC context globally for all requests originating from the client. This wouldn't be specifically tied to the locale, but could serve that purpose among others (like passing specific frontend state, user preferences not in Forge context, etc.).

I understand that forge-trpc ultimately wraps Atlassian's invoke function. However, from my understanding of the implementation, the backend integration does handle and process the context derived from the request. It seems potentially feasible that these "extra args" provided via configuration could be merged into the context on the backend side before the procedures are executed. I'm not sure about the internals, but wanted to propose it as a potentially flexible and unopinionated solution.

On the topic of middlewares, thanks for sharing your team's approach! We employ very similar patterns for permission validation. The idea of whitelisting specific Forge modules per route is excellent – definitely something valuable to consider implementing.

Thanks again for your openness to discussion and for maintaining this useful adapter! I'm happy to hear thoughts from others in the community as well.