I first showed Compose to HN about 6 months ago (https://news.ycombinator.com/item?id=41722189).
Back then, I was really interested in the idea of Retool, but with code. Retool proved that you can save a bunch of time by giving people high-level primitives to build internal tools. What if there was something that gave you all the same primitives and conveniences of a hosted platform, but packaged inside an SDK that let you build in your own IDE and benefitted from the power of code.
Since then, I’ve talked to a lot of developers and developed Compose into a platform that actual startups are using!
Basically, Compose has two parts:
- Build internal tools in your backend using our SDKs for Python and TypeScript.
- Use/share those tools via your Compose web dashboard.
The Compose SDK includes primitives like tables, forms, charts, file uploads, and a bunch more to build useful tools in just a few lines of code. Since the SDK is installed into your backend, connecting these primitives to your own data and logic is as easy as importing functions and calling them within the Compose Apps that you define.
The Compose web dashboard renders UIs for your tools and enables you to share them with your entire team. It also includes audit logs, RBAC, and other useful features to manage your tools without any configuration on your end.
Under the hood, the web dashboard maintains a secure, proxied websocket connection to the Compose SDK to run the tools you build.
Here’s a super basic Node.js example that lets you turn a SQL query into a simple table dashboard (there’s also a python SDK).
import { Compose } from "@composehq/sdk";
import { database } from "../database";
const viewUsersApp = new Compose.App({
route: "view-users",
handler: async ({ page, ui }) => {
const users = await database.selectUsers() // query your database
page.add(() => ui.header(`Total: ${users.length} users`)
page.add(() => ui.table("users-table", users)); // display results in a table
}
})
Please let me know what you think!Website: https://composehq.com
It's a good idea for short-lived HTTP requests, but will cause problems for a persistent connection.
some of the complexity is self-inflected by ignoring KISS principle
What? How would public network even know you’re running a websocket if you’re using TLS? I dont think it’s really possible in general case
> Since SSE is HTTP-based, it's much less likely to be blocked, providing a reliable alternative in restricted environments.
And websockets are not http-based?
What article describes as challenges seems like very pedestrian things that any rpc-based backend needs to solve.
The real reason websockets are hard to scale is because they pin state to a particular backend replica so if the whole bunch of them disconnect at scale the system might run out of resources trying to re-load all that state
send(payload).then(reply => ...)
But client and server use it to maintain a record of events.
I imagine the way it might go is that the client would first send an HTTP request to an endpoint that returns routing instructions, and then use that in the custom headers it sends when initiating the WebSocket connection.
Haven't tried this myself though.