Microservices - Overview

Beamable's Microservice Feature is custom-built to provide the best workflow and performance for game makers.

A microservice architecture, or "microservice", is a solution of developing software systems that focuses on building single-function modules with well-defined interfaces and operations. See Wikipedia for more info.

🚧

Microservcices DotNet requirements

Microservices now requires DotNet 6 to be installed locally on your machine for debugging. You can acquire this directly from Microsoft.

Beamables Microservices

Like never before, programming a server-authoritative feature feels like a natural extension of your favorite client-side tools and workflows — powered by Beamable Microservices.

Benefits

• Highly maintainable & testable
• Loosely coupled
• Independently deployable

The Microservice code is checked in alongside your client code to version control. With Beamable, there is less code since the system shares and serializes all client/server data structures.

Comparison

There are trade-offs as well. Games using server technology like Microservices must be connected to the internet, each server-side operation call is slower than a client-side operation due to network latency, and there are fees incurred to host or use servers.

Server-Authoritative Benefits

Typically in game development, game code is on the game client. This is a client-authoritative approach. Moving functionality to the back-end is a server-authoritative approach. There are pros and cons.

Comparison: Client vs Server Benefits

Compatible Beamable Features

Beamable provides an SDK that enables game makers to easily add social, commerce and content management Features.

The available features vary by context.

API Entry Points

• C# Client Code - Access via Beamable.API from a context outside of Microservices
• C# Server Code (Microservice) - Access via Services from a context inside of a Microservice

Feature Comparison

📘

Related Features

More details are covered in related feature page(s).

• Microservice Storage - Create and deploy a native Mongo database which we host

Advanced

This section contains any advanced configuration options and workflows.

Code Generation

The Microservice feature relies on automated code generation.

Each time the game maker edits and (re)saves any child class of Microservice (e.g. "MyMicroservice") an equivalent class is (re)generated as a child class of MicroserviceClient (e.g. "MyMicroserviceClient"). This workflow is provided for ease-of-use.

🚧

Gotchas

Here are hints to help explain some of the trickier concepts:
The code generation takes place in a separate Docker container, suffixed with the term, "_generator". If your code has a compilation error, then the code generator won't be able to produce a new client file. In Beamable 1.3+, the Microservice Log window will print a line saying, "Failed to generate client code", and if you click on it, you'll be able to see the compilation error. As soon as the compilation error is fixed, the generator should re run. If it doesn't you can restart the generator by using the dot-dot-dot/local menu.

Archiving a Service

Microservices and Microstorage objects can be archived by selecting the archive button within the service's dot-dot-dot menu. When a service is archived, it will be hidden from the main view of the Microservice Manager window. The services must be published for the archival to be committed to the realm. When a service is archived on a realm, it cannot be executed. Services may be unarchived to restore functionality.

CPU Architecture

Beamable Microservices are built as Docker images. Docker images must be built for a target CPU architecture, such as "linux/arm64" or "linux/amd64". In Beamable 1.3+, it is possible to control the Microservice CPU architecture for local development only. By default, the architecture will mirror the architecture of the machine it was built on. For example, a developer running an ARM CPU will produce a "linux/arm64" Microservice, and a developer running on a Windows machine will produce a "linux/amd64" Microservice.

Anytime Beamable Microservices are published, all of the services are re-built specifically for the publication. During publication, the CPU architecture will be forced to "linux/amd64". If a developer's computer cannot produce a "linux/amd64" image, then the publication will fail. With the latest version of Docker installed, support for "linux/amd64" can be added using https://docs.docker.com/desktop/multi-arch/

📘

CPU Architecture is an advanced feature

It is unlikely that developers will require the ability to specify the Microservice CPU architecture type.