plane VS stan.go

One reason I'm excited about this is that it appears to let you write arbitrary routing logic into a layer 7 proxy. This is something we had to build for https://plane.dev and it would have been nicer to use something like this, but we couldn't find anything like it at the time.

Of course, as a user, I would prefer as much as possible to be under MIT or Apache. See for instance https://plane.dev/ for a similar project which is MIT licensed and https://jamsocket.com/ for the commercial version.

From an earlier blog post[1], the system for synchronizing file/document state lives independently for their database. As I understand it, their database is for metadata rather than actual document content.

> It’s worth noting that we only use multiplayer for syncing changes to Figma documents. We also sync changes to a lot of other data (comments, users, teams, projects, etc.) but that is stored in Postgres, not our multiplayer system, and is synced with clients using a completely separate system that won’t be discussed in this article. Although these two systems are similar, they have separate implementations because of different tradeoffs around certain properties such as performance, offline availability, and security.

This post[2] goes into more detail on how they spin up backend processes to serve as the source of truth while documents are open (we took heavy inspiration from it when building https://plane.dev, which aims to be an open-source implementation of that architecture.)

[1] https://www.figma.com/blog/how-figmas-multiplayer-technology...

We have been happily using Depot for months now to build https://plane.dev. Prior to finding Depot, we basically gave up on building an M1 image from a GitHub action.

(btw, I always get suspicious when a Show HN post has a lot of praise in the comments, but I swear the Depot folks did not ask me to post anything and I only saw the post because I was checking HN)

Congrats on the launch!

We've been using Depot with Plane (https://plane.dev/). Prior to depot, I had to disable arm64 builds because they slowed the build down so much (30m+) on GitHub's machines. With Depot, we get arm64 and amd64 images in ~2m.

Nats is not something I see as a competitor for external clients (browsers, mobile apps), primarily because it doesn't handle reconnections / message delivery / quality-of-service / at-least-once or exactly-once delivery (except for MQTT).

> When the connection is lost, your application would have to re-create it and all subscriptions if any. https://github.com/nats-io/stan.go#connection-status

Therefore, I don't see what it adds here. It seems designed for service communication, not client-server. They also don't list browsers as a use case https://docs.nats.io/nats-concepts/overview#use-cases. (though it is of course possible, it's just not ideal IMHO.)

They still have a js/browser client library though if you want to use them: https://github.com/nats-io/nats.ws. And yes, their servers "have websocket support".

Hi, in this article I've tried to make microservice using: 🚀 NATS as message broker gRPC Go implementation of gRPC PostgreSQL as database Jaeger open source, end-to-end distributed tracing Prometheus monitoring and alerting Grafana for to compose observability dashboards with everything from Prometheus MailHog Web and API based SMTP testing Redis Type-safe Redis client for Golang Nginx HTTP and reverse proxy server swag Swagger for Go