What does SDK-Dependent actually mean?

[JAForbes]

Quick question just looking for some disambiguation. Does "SDK dependent" on the docs mean a function will work everywhere except WASM (opa run + JS SDK), or only with the JS SDK?

[srenatus]

It means it'll only work in wasm if the used SDK provides that implementation. Which ones are there depends on the used SDK. For example, the JS SDK comes with some yaml and json bulletins.

[JAForbes]

Is there a table that specifies which SDK's support which functions?

[srenatus]

Not to my knowledge, sorry.

[JAForbes]

Ok great, last point of clarification

it'll only work in wasm if the used SDK provides that implementation.

So different SDK implementations provide different helper functions, makes sense. But if I am running opa server without WASM, just a tarball bundle, can I rely on all SDK functions always existing when those policies are executed via the opa binary server.

In other words: are there any functions that are SDK only, and won't work with the opa server out of the box?

[srenatus]

But if I am running opa server without WASM, just a tarball bundle, can I rely on all SDK functions always existing when those policies are executed via the opa binary server.

When using the opa binary, via opa eval -t wasm or opa run --server with a wasm bundle (i.e. built via opa build -t wasm), all the builtins that this OPA version knows about will be available: the Wasm SDK within OPA will use the default implementations for any built-in that isn't natively implemented in the Wasm module.

In other words: are there any functions that are SDK only, and won't work with the opa server out of the box?

SDKs can do what they want. You can have functions in an SDK that OPA doesn't know about, and that OPA wouldn't be providing. You can still use opa build -t wasm to build such wasm bundles, as long as you provide a capabilities file that declares the builtins' types.

[JAForbes]

I think we're working with different mental models which is definitely due to me not knowing OPA well enough yet. So I apologise for probably over-complicating things.

I'm still wondering about cross compatibility of wasm and non wasm bundles. I get SDK's can provide extra functionality not documented on the policy reference, but I want to know that if I use all / any of the functions on the policy reference page that I wil lget 100% cross compatibility in the following contexts:

• wasm bundle with JS SDK
• non-wasm (opa build -b .) bundle run with opa server

I'm sorry if this seems like I'm going round in circles, I just don't want to write some large sprawling policies and then find they don't run on the server (without wasm).

When using the opa binary, via opa eval -t wasm or opa run --server with a wasm bundle (i.e. built via opa build -t wasm), all the builtins that this OPA version knows about will be available: the Wasm SDK within OPA will use the default implementations for any built-in that isn't natively implemented in the Wasm module.

This makes complete sense to me, but I specifically want to know if all the "SDK-Dependent" functions will work fine with opa run --server with a normal opa build -b . bundle.

[srenatus]

I'm sorry if this seems like I'm going round in circles, I just don't want to write some large sprawling policies and then find they don't run on the server (without wasm).

SDK-dependent has no meaning for rego policies. They fall under the usual backwards and forwards compatibility regime.

The same is true for wasm bundles built and used with OPA. They can use any built-in they want, and be treated mentally just like a rego bundle.

The incompatibilities only arise when using a wasm SDK. If your policies work with an SDK depends on the (SDK-dependent) built-ins that the SDK provides.