[Draft]: NEX Service

[jonbarrow]

Resolves #XXX

Changes:

This is the start of a generic NEX service. Anything that we may want to do with, or get from, a game server should be implemented here. Currently using a PID size of uint64 because there's no reason not to in this case, it won't break anything and makes it forwards-compatible

Marked as a draft because this is very WIP. I'm not sure what all we think we might need out of this, and the design is subject to change at any time

• I have read and agreed to the Code of Conduct.
• I have read and complied with the contributing guidelines.
• What I'm implementing was an approved issue.
• I have tested all of my changes.

[github-actions]

The latest Buf updates on your PR. Results from workflow Validate Pull Request / check_buf (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	⏩ skipped	❌ failed (1)	✅ passed	Jun 18, 2025, 10:40 PM

[jonbarrow]

Should we add protocol-specific methods here as well? Such as methods to get DataStore objects, and match session data, and rankings, etc?

[DaniElectra]

I think there should be services for each protocol, we'll probably have various methods on each protocol so I believe it's best to separate them to keep them organized

[DaniElectra]

It isn't necessary to add the V1 suffix to the service name since that is already handled by the package name nex.v1

[jonbarrow]

It is, gRPC differentiates services by their name. We just got lucky in the other services that we happened to rename them in their respective v2 updates

[DaniElectra]

The service name isn't relevant here, so long as the package name is updated. Let's look at an example from the Go account service:

The "v1" version (with package name account) is located on "github.com/PretendoNetwork/grpc/go/account", and the server and client interfaces are prefixed with the service name: AccountClient

The v2 version (with package name account.v2), however, is located on "github.com/PretendoNetwork/grpc/go/account/v2" and the server and client interfaces are prefixed with the new service name: AccountServiceClient

Even if the service names were the same, they are still located at different scopes in code, so there isn't any issues with keeping the name as NEXService across versions, since the code for them would be stored at different locations and therefore they can't collision.

In this case, the package name is the following:

grpc/protobufs/nex/v1/nex_service.proto

Line 3 in a312e2c

package nex.v1;

So there won't be any issues with keeping the service name the same as long as the package name is updated to v2 accordingly when needed

[jonbarrow]

I was partially mistaken. gRPC uses both the service name and package name to create the identifiers (this can be seen in the account server, where our middleware checks path names and these path names include the service identifier. Examples being /api.API/GetUserData and /api.v2.ApiService/GetUserData), so the service name is still relevant, since it means we could keep everything under the same package but with different service names, or we could use different packages (like what we do now) with the same package names

That being said, I still believe it's good to version the service name as well for cases where we need to support multiple versions at the same time. The account server is a good recent example of that, where because we didn't version the service names and the names look so similar (AccountDefinition vs AccountServiceDefinition) it's hard to see at a glance what version each service is, resulting in code like:

import { AccountDefinition as AccountServiceDefinitionV1 } from '@pretendonetwork/grpc/account/account_service';
import { AccountServiceDefinition as AccountServiceDefinitionV2 } from '@pretendonetwork/grpc/account/v2/account_service';

But if instead we had versioned the service names, we would not need for a namespace import:

import { AccountServiceDefinitionV1 } from '@pretendonetwork/grpc/account/account_service';
import { AccountServiceDefinitionV2 } from '@pretendonetwork/grpc/account/v2/account_service';

[jonbarrow]

I think there should be services for each protocol, we'll probably have various methods on each protocol so I believe it's best to separate them to keep them organized

That's fair, I agree. Do we want them in separate services entirely (IE, putting them at the top level of the protobufs protobufs/datastore) or do we want to put them inside the nex folder (IE, protobufs/nex/datastore)

Personally I'm leaning towards putting them inside the nex folder

So we could have it structured like:

• protobufs/nex/v1
• protobufs/nex/datastore/v1
• etc.

[DaniElectra]

Personally I'm leaning towards putting them inside the nex folder

That sounds good to me!