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.
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.
- 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.
|Amazon AWS Lambda||GameSparks|
|C# Client Code||✔️||✔️||✔️||✔️|
|C# Server Code||✔️|
|Full Debugging Support|
(Debug.Log, Breakpoints, etc...)
|Source Control Integration||✔️|
|Runs Locally During Development||✔️|
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.
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
|Speed Of Development||✔️|
|Speed At Runtime||✔️|
|Speed To Release Updates||✔️|
|High Security (Anti-Cheat)||✔️|
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.APIfrom a context outside of Microservices
- C# Server Code (Microservice) - Access via
Servicesfrom a context inside of a Microservice
|Feature||C# Client Code||C# Server Code (Microservice)|
|A/B Testing||✔️ ||✔️ |
|Accounts||✔️ ||✔️ |
|Announcements||✔️ ||✔️ |
|Cloud Save||✔️ |
|Content||✔️ ||✔️ |
|Currency||✔️ ||✔️ |
|Events||✔️ ||✔️ |
|Groups||✔️ ||✔️ |
|Inventory||✔️ ||✔️ |
|Leaderboard||✔️ ||✔️ |
|✔️ ||✔️ |
|Stats||✔️ ||✔️ |
|Tournaments||✔️ ||✔️ |
More details are covered in related feature page(s).
• Microservice Storage - Create and deploy a native Mongo database which we host
This section contains any advanced configuration options and workflows.
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.
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.
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.
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.
Updated 4 months ago