SG-VR: Supporting Backend Microservices
In anticipation of future backend needs for the SG-VR project, I started by building out a contemporary back-end web service to process HTTP requests and enable game-data persistence across play sessions. This is essentially a .NET microservice, that exposes a small support-api that can be hit from within Unity, and fulfill requests on behalf of game objects, prefabs, etc.
To help future devs work on the project(aka future me) I have used a little bash scripting to let simple JSON objects files be sourced to create new event/commands. They also allow for generating versioned JSON schemas based on those objects. Once the JSON & their corresponding schemas are defined & made available, any service can easily reference a message-type at a semVer, and validate whatever message they receive via the api or bus. Performing message validation in a standardized space(schema validation) enables the writing of simple, cross-concern oriented filters to handle corruption without the developer(also future me) wasting time writing validators!
Maecenas id finibus felis. Etiam vitae nibh et felis efficitur pellentesque. Mauris suscipit sapien nunc, a lacinia nibh feugiat ut. In hac habitasse platea dictumst.
Description
SG-VR: Backend Api
1.12.2019
The backend exposes a JSON-centric API, that when hit triggers a sequence of filters and middleware to process the event. While processing, an initial filter takes the event and runs it through a JSON-schema validation tool, enabling the top-level controller to act as an 'anti-corruption' layer. After validating the JSON per the versioned schema(or appending each violation to the response body so the caller can fix & retry, or notify) a subsequent filter handles to-entity deserialization. Once the filters are all 'green', and the request has walked 'up' the action-execution chain the Middleware can decide to hand a new message to the service bus(RabbitMQ) or pop a new document into MongoDb for later use, whatever the case may necessitate.