mwitkow

We use Thanos to provide the observability features (monitoring in particular) to Workers (i.e. user processes we run on our Cloud) that perform the simulation. You can have multiple Workers collaborating on a simulation of the economics or ecology that export monitoring variables that you want to track.

Since the simulation is inherently dynamic, and the number of Workers can change, Thanos helps us with achieving the necessary scale and retention for a hosted platform that is SpatialOS.

(disclaimer: I work at Improbable)

The reason why we built Thanos was to enable monitoring of large scale simulation systems, which are inherently stateful, such as the Survival demo (link https://youtu.be/lGWON5TtS04).

That sounds very much what we're doing, except our microservice stack is in Go. For nodeJS you probably want to front your pods with grpcwebproxy (https://github.com/improbable-eng/grpc-web/tree/master/go/gr...)

If you hit any snafus, please file bug reports in https://github.com/improbable-eng/grpc-web We're happy to help :)

Totally agreed. There are cases where you basically want to deal with well structured web resources: HTML, images etc. For these, HTTP is a perfect fit.

What we're replacing with gRPC is usage of REST (URL-encoded resources) + JSON for application APIs, not really Web-resources.

What we found is that gRPC is really good at capturing both a resource-oriented API (we use similar conventions to Google's excellent API Design handbook https://cloud.google.com/apis/design/resource_names#resource...) and imperative ones. The major difference we no longer have a weird POST method with `/books/do_recalculation` that breaks the RESTfulness of the API.

There's actually a stand-alone proxy that translates the REST mappings of `google.api.http` into gRPC requests. It relies on code-generation: https://github.com/grpc-ecosystem/grpc-gateway

This has been the way we've been shipping our REST services until now, but the need to recompile the proxy was a major hinderence to our development speed. Hence gRPC-Web implementation.

We haven't tried using gRPC in Python, as we have completely migrated from Python away towards Go.

Our experience of using gRPC in Java, C++ and Golang is pretty good. While it had some initial teething issues (when it was first released), the libraries have generally been a non-issue since the gRPC General Availability (GA-1.0 version).

If you're considering using it in Go, check out the https://github.com/grpc-ecosystem/go-grpc-middleware helper libraries that we've contributed back to gRPC Ecosystem.

Yea, we actually work closely with the gRPC-Web team at Google to make sure our implementations are interoperable and we have plans for cross-integration-testing.

One of the authors here.

This is indeed our own implementation of the pending spec. We are in touch with the gRPC team to make sure that their (still unreleased) implementation is cross-tested with ours.

The benefit of our implementaiton is a relatively light-weight client-side lib for Typescript and >=ES5, and a "ready-to-go" Go middleware.

That's interesting, we have a slightly related architecture. SpatialOS Runtime, itself distributed across many machines, acts as your "Master Control Process". It orchestrates Workers, both managed (running in the cloud), and external (remotely connected game clients), to perform the co-simulation of the world.

The key feature of the stack is that you can integrate various Workers to act together, leveraging existing game engines in multiple languages. Checkout https://spatialos.improbable.io/docs/reference/9.0-alpha/wor... if you're interested in trying to port your stuff onto our stack.

Seems like an issue with skillsmatter/vimeo :(

If you're interested, we also went to CoreOS Fest Berlin this year, where I presented how we dynamically reconfigure our SpatialOS simulations and our Platform microservices: https://youtu.be/zo_Hv0WyNTo?list=PLlh6TqkU8kg_3FpXLlHMnoVqK...

Our Platform team uses Golang extensively. We use it together with gRPC to form our microservice stack that orchestrates the SpatialOS simulations. The TL of our Platform API team did a cool talk at the Go London User Group meetup in October: https://skillsmatter.com/skillscasts/9259-a-debuggable-base-...