Is there a way to serve nested json objects?

Help
#1

Greetings!

The title says it all, but just to give more context: we already have some messages that we use today that we want to serve via Resgate. The problem is that Resgate doesn’t seem to like nested JSON objects very much [1]. Is there a way to bypass this limitation?

Thanks in advance.

[1] - {"code":"system.internalError","message":"Internal error: Internal error: invalid value"}

#2

Hi! And welcome to the forum :partying_face:

The subject is explained in Nested Resources • resgate.io

If you wonder how to make nested resource/resource references using a specific service library (like .NET RES service or go-res), then I could help with that too. Are you using any library?

But nesting can only be done through resource references.

To bypass it and allow a single resource to contain nested data? No, that is not possible
It will raise issues on how to solve updates and synchronization of nested data, like how to tell what part of a nested structure was changed and what parts were added/removed.

Best regards,
Samuel

#3

A side note:

It is possible to do an ugly hack where you encode a nested structure into a string, which you then decode on the client side:

Eg:

{ "foo": "{\"nested\":\"bar\"}" }

But I would strongly recommend against it :grimacing: . Resource reference is the way to go.

#4

Yeah, I’m aware of nested resources (sorry to not mention it earlier) on resgate, but I was hoping that did’t meant to be such a strict rule. I mean, it is completely impossible to use resgate for complex resources just because they are not plain (and the sub-objects don’t ever change).

I’m being forced to use the ugly hack for now :sweat_smile:

Thanks for the reply.

#5

I thought that might have been the case :slight_smile:

Yes, the restriction makes large nested structures more cumbersome to create, and it is therefor encourage to try keeping the data in smaller flatter units that represents the UI components which they are used for when rendering.

Maybe I could help better if I knew what your data structure looks like.

During protocol design, different ideas were discussed, but none that would solve this issue well without adding quite a lot of complexity.

If you have ideas, we’d be happy to discuss them! Would be a great thing if we found a good solution for it. If you are interested, I could describe the different ideas we’ve considered already :thinking:.

Best regards,
Samuel

#6

Hello again!

I had a chat with one of mine coworkers and your approach seems to have more sense. No need to worry about our specific case :slight_smile:

Thanks again and keep up your good work!

1 Like