Ingest, store, & analyze all types of time series data in a fully-managed, purpose-built database. Keep data forever with low-cost storage and superior data compression. Learn more →
Plane Alternatives
Similar projects and alternatives to plane
-
-
-
SonarLint
Clean code begins in your IDE with SonarLint. Up your coding game and discover issues early. SonarLint is a free plugin that helps you find & fix bugs and security issues from the moment you start writing code. Install from your favorite IDE marketplace today.
-
-
-
Centrifugo
Scalable real-time messaging server in a language-agnostic way. Set up once and forever.
-
-
windmill
Open-source developer platform to turn scripts into workflows and UIs. Open-source alternative to Airplane and Retool.
-
InfluxDB
Access the most powerful time series database as a service. Ingest, store, & analyze all types of time series data in a fully-managed, purpose-built database. Keep data forever with low-cost storage and superior data compression.
-
-
-
-
-
peritext
A CRDT for asynchronous rich-text collaboration, where authors can work independently and then merge their changes.
-
-
pigeon
Diff, patch, merge, and synchronize JSON documents with an Automerge-compatible interface (by frameable)
-
statebox_riak
Convenience library that makes it easier to use statebox with riak, extracted from best practices in our production code at Mochi Media.
-
-
mqtt-to-kafka-bridge
Move your messages from MQTT to Apache Kafka in real-time :rocket:
-
-
build-push-action
GitHub Action to build and push Docker images with Depot (by depot)
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
NOTE:
The number of mentions on this list indicates mentions on common posts plus user suggested alternatives.
Hence, a higher number means a better plane alternative or higher similarity.
plane reviews and mentions
Posts with mentions or reviews of plane.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2023-02-22.
-
Launch HN: Depot (YC W23) – Fast Docker Images in the Cloud
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.
-
Show HN: DriftDB is an open source WebSocket back end for real-time apps
I see you also created Plane https://plane.dev/ - what's the relationship between driftdb and plane? Can they be used together? Does one depend on another?
NATS is great, we use it in another project, Plane (https://plane.dev). The reasons I didn’t use it instead of making DriftDB:
- In NATS, unless you set up authentication, any user can subscribe to “>” and get a firehose of every message, even if they don’t know the room IDs.
- NATS Jetstream supports rollups, but they roll up the entire stream, rather than up to a certain sequence number. This would break our ability to do leaderless compaction.
Seems expensive no? To start a http container per request? But I suppose it does solve many server side persistence issues. And I love the power it affords you in creating virtual worlds. Awesome stuff ;)
> What does "on the edge" mean in this context?
DriftDB has a concept of “rooms”, which are essentially broadcast channels. By “on the edge”, what I mean is that the authoritative server for each room can be geographically located near the participants in that room. In practice, today that means that it can be compiled to WebAssembly and run as a Cloudflare Worker.
> Can I just run the server part on my own infrastructure?
Kinda. It includes a server that runs locally, but it’s only useful as a development server at this point. Your question about multiple pods is exactly the reason -- unless you have a routing layer that is aware of DriftDB’s “rooms”, it won’t work if you scale it up. We also make https://plane.dev which provides the routing layer, but it might be overkill for a DriftDB use case.
-
Aper: a Rust library for data synchronization using state machines.
https://plane.dev is a lightweight orchestrator that routes traffic intended for the same document/game instance/chatroom etc. to the same server process. Each one gets an ephemeral hostname and the routing is done over DNS.
-
You might not need a CRDT
> I wonder what web development could learn from online game development when it comes to "multiplayer" apps - I mean it's right there in the name.
100%. The architecture we used for https://plane.dev takes a lot of inspiration from how game servers work, but using HTTP/WebSocket instead of UDP.
A lot of state sharing techniques that people are now using on the web (like cursor position smoothing and optimistic updates) have decades of precedent in multiplayer games.
We’ve also seen more apps start to use an approach to pixel streaming which more closely resembles stadia than traditional VNC. https://digest.browsertech.com/archive/browsertech-digest-wo...
-
Plane: Per-user back ends for ambitious web apps
Hey HN!
Plane came from our desire to build tools that have the low friction to use of running in the browser, but can use more memory and compute than the browser will allocate. The idea is to run a remote background process, connect to it over WebSocket, and stream data.
This ends up being a surprisingly useful primitive to have, and it's been used to:
- Pixel-stream X11 applications to the browser over WebRTC[1]
- Run IDEs and notebooks
- Power Figma-style realtime collaboration backends (including https://rayon.design).
Here's a direct link to our repo: https://github.com/drifting-in-space/plane and docs: https://plane.dev/
[1] https://twitter.com/drifting_corp/status/1552773567649091584
Re. handling failure, we leave that up to an application/framework layer decision. When the backend is used for program state, the common approach is an auto-save loop that persists state externally (asynchronously) on a loop. If the backend is only used in a read-only way, the approach is to just recreate it on failure with the same parameters.
In general, Plane backends are meant to be used with thick clients, so there’s also the option to treat clients as nodes in a distributed system for the purpose of failure. If the server goes down and is replaced, when it comes back up, the nodes could buffer and replay any messages that may have been lost during the failure. Over time as we see patterns emerge, we may create frameworks from them (like aper.dev) to abstract the burden away from the application layer.
Time series metrics are exposed through Docker’s API, collectors for it already exist for various sinks. We will soon be sending some time series metrics over NATS to use internally for scheduling, but the Docker API will be better for external consumption because the collector ecosystem is already robust.
Resource caps can be defined at “spawn time”. They are not expected to have similar consumption, but the scheduler is not yet very smart, our approach currently is admittedly to overprovision. The scheduler is a big Q4 priority for us.
Draining currently involves terminating the “agent” process on the node, which stops the drone from advertising itself to the controller. Traffic still gets routed to backends running on that drone. We have an open issue[1] to implement a message to do this automatically.
Thanks for taking the time to look through the architecture. There are definitely some choices that would have seemed weird to me when we set out to build this, but that we did not make lightly.
We actually initially built this on Kubernetes, twice. The MVP was Kubernetes + nginx where we created pods through the API and used the built-in DNS resolver. The post-MVP attempt fully embraced k8s, with our own CRD and operator pattern. It still exists in another branch of the repo[1].
Our decision to move off came because we realized we cared about a different set of things than Kubernetes did. For example, cold start time generally doesn’t matter that much to a stateless server architecture, but is vital for us because a user is actively waiting on each cold start. Moving away from k8s let us own the scheduling process, which helped us reduce cold start times significantly. There are other things we gain from it, some of which I’ve talked about in this comment tree[2]. I will say, it seemed like a crazy decision when I proposed it, but I have no regrets about it.
The point of sqlite was to allow the “drone” version to be updated in place without killing running backends. It also allows (but does not require) the components of the drone to run as separate containers. I originally wanted to use LLVM, but landed on sqlite. It’s a pretty lightweight dependency, it provides another point of introspection for a running system (the sqlite cli), and it’s not something people otherwise have to interact with. I wrote up my thought process for it at the time in this design doc[3].
You’re right about per-user being supported by Plane. I use per-user to convey that we treat container creation as so cheap and ephemeral you could give one to every user, but users can certainly share one and we’ve done that for exactly the data sync use case you describe.
[1] https://github.com/drifting-in-space/plane/tree/original-kub...
[2] https://news.ycombinator.com/item?id=32305234
[3] https://docs.google.com/document/d/1CSoF5Fgge_t1vY0rKQX--dWu...
-
A note from our sponsor - InfluxDB
www.influxdata.com | 28 Mar 2023
Stats
Basic plane repo stats
14
1,114
10.0
15 days ago
drifting-in-space/plane is an open source project licensed under MIT License which is an OSI approved license.
Popular Comparisons
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com