Claas Meints (Oct 03 2026 at 19:54): Claas Meints (Oct 03 2026 at 19:54):Hi,
I was wondering whether Roc’s type inference and platform model could support a higher-level abstraction for communication between separately deployed Roc services.
Roughly:
user = Users.get!(id)?
Stdout.line!(user.name)
Stdout.line!(user.profile.avatar)
Users.get! would explicitly be an effectful remote operation to another Roc service, but the application would not define a separate request/response schema. The result type would be inferred from how it is used, so the remote layer could request/decode only the required structural fields, conceptually similar to GraphQL selection, but derived from the Roc program itself.
The platform/package would handle transport, serialization and failures. Only structurally serializable values would be allowed across the boundary.
A first version might not require compiler changes at all.
Something like:
Remote.query! : Request => Result(a, RemoteError)
where [a.Parseable(...)]
could potentially use Roc’s existing type-directed codec machinery to infer/decode a, and perhaps derive a field-selection description from the same inferred structure.
A later extension could statically check the inferred client requirements against another Roc service’s inferred interface, but that would likely need compiler/build-system support.
I’m mainly curious whether this fits Roc’s model and whether the existing codec/platform machinery is expressive enough for a prototype, or if there are fundamental issues I’m overlooking. If this has already been discussed somewhere, a pointer would also be appreciated.
Karl (Oct 03 2026 at 20:06):Last I checked the decoder API wouldn't compile without an explicit type declaration. Richard has said that this is a bug but I haven't noticed the fix if one has come in.
As for the codec part, I think this should be doable. I have similar things with SQL queries in https://github.com/grayrest/roc-tower-platform
Last updated: Oct 15 2026 at 17:56 UTC