Distributing Nakama Binaries via Nx Plugin

Local Setup
1

I’m currently developing an Nx plugin for Nakama and have a question regarding distribution. My plugin aims to streamline the installation process by allowing users to download Nakama releases directly from GitHub via the plugin’s CLI. Additionally, it will feature a public API that lists all Nakama releases, enabling users to choose their preferred version.

Before proceeding, I want to ensure this aligns with the community’s guidelines and Nakama’s distribution policies. Is it permissible to offer Nakama binaries in this manner?

2

Hi there; Thanks for working on this; I had a light look at Nx and it looks like it is used for compiling/packaging monorepos. Can you tell me more about what the developer life using Nx with Nakama would be like? What’s the purpose of this and where is the existing pain you are trying to solve? Thanks much!

3

Hi Mo, thank you for the appreciation!

The primary goal of this plugin is to enhance the developer experience for those using Nx by streamlining the integration of Nakama projects into Nx workspaces. This is particularly relevant for my current work, where I am developing two similar multiplayer games that include both Nakama servers and Unity clients, all within a single repository.

Key features of the plugin include:

  • Scaffolding: It simplifies the setup of new Nakama projects, offering options like the choice of programming languages, which helps in quickly starting new projects.
  • Unified CLI: Most Nx plugins naturally enhance the developer experience by offering a consistent CLI for various tasks such as compiling (nx build <project>), serving (nx serve <project>), and creating Docker images (nx docker-build <project>).
  • Dependency Management: It simplifies the inclusion of packages within the same repository.
  • Selective CI/CD: The plugin plays a crucial role for the continuous integration and deployment of monorepos. It ensures that only the affected Nakama projects are built, tested, and deployed. This means that modifications in one part of the repository only trigger actions for the Nakama project, if the project itself or its dependencies have been modified.

Once the key features are implemented and tested, I plan to publish the project and release it as open-source.

4

I am very interested in this! The binaries Heroic Labs releases are just hard to manage. I had nothing but trouble with them. They need to release better quality packages for distros, what they have is lowest level bare bones stuff. Not recommended.

5

Hey @Glowdragon just two further questions so we can fully understand:

(1) How would nx build work with the Unity projects in your monorepo?
(2) What would the benefits of an nx serve facade give over a docker compose up?

6

Hi @kragil - I share the same feelings in regards to the distribution but so far every professional studios we speak to have opted for Docker as their way to running the game server. I’d be more than happy for the community to open PRs that enabls support for Chocoloty (or whatever the latest package manager on Windows is) as well as Homebrew and other Linux distribution platforms.

7

Hi @lugehorsam - Thank you for your questions and interest. To answer your questions, I will expand a little.

(1) The plugin determines the Unity installation path based on the default installation directory or a configured path. The Unity version is identified by reading the ProjectVersion.txt. Based on this information, the plugin can localize the Unity binary and thus use the Unity CLI to create builds.

(2) Please note that the main target group for this plugin are Nx users. With that being said, there are several reasons why it should be possible to use nx serve to run the server:

  • It does not require Docker to be installed.
  • There is no need for a docker-compose.yml in the repository, which reduces the configuration effort.
  • Using Docker for serving is atypical within the Nx ecosystem.

Moreover, the task runners of the Nx plugin enable Nx to build, test, and deploy projects selectively. For example, the command nx affected:build smartly identifies and builds only those projects that have undergone changes, while also taking dependencies into account. This feature is particularly useful for the CI/CD pipeline of a monorepo, ensuring efficiency and resource optimization.

Additionally, integrating Nakama into an Nx monorepo allows for uniform project configurations. You can set up different environments, such as development and production, with each project having tailored options. For example, nx serve nakama-server -c development could use development.yml, while nx serve nakama-server -c production would use production.yml. This functionality extends to build tasks and the affected command. For instance, executing nx affected:build -c production not only compiles the source but also automatically copies the production.yml file to the distribution folder.

To @mofirouz - I appreciate your openness to community contributions. What do you think about providing the Nakama binaries via NPM? Since Nx is also provided via NPM, this could significantly simplify Nakama’s installation for Nx users, but also for TypeScript developers.

Upon further reflection, I think automatically downloading the Nakama is not that essential. As an alternative, the plugin could prompt the user to provide the path to the Nakama binary and direct the user to the releases page. The obvious downside is that this approach would require either including the binary in the repository or ensuring it’s installed on each developer’s machine at a consistent path or configured individually. However, this won’t be a deal breaker for the plugin.

Looking forward to your thoughts and feedback.

8

Thanks for the details @Glowdragon. We are happy for a community-contributed plugin for users of NX to more easily integrate Nakama. We would prefer that you do not host Nakama on npm and use the local path approach you outlined.

We know there are a few different moving pieces when it comes to using Nakama (the server binary, the server Go plugin or Javascript/Lua, and the client) so we are interested in seeing whether NX and your plugin can be used to simplify our workflow.