Recent submissions

Comment · 1 year ago
Looks interesting. Don't see any info on pricing though?
Comment · 1 year ago
Hey HN! I’m Atul, and today I’m super excited to open-source Compose: a server-side SDK for building internal tools faster, without leaving your codebase.

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

Docs: https://docs.composehq.com

Code: https://github.com/compose-dev/compose

Comment · 1 year ago
It does, but it will generally give a grace period for outstanding requests to resolve prior to killing the service.

It's a good idea for short-lived HTTP requests, but will cause problems for a persistent connection.

Comment · 1 year ago
How would you make it simpler?
Comment · 1 year ago
The initial handshake will usually include an `Upgrade: websocket` header, which can be inspected by networks.
Comment · 1 year ago
Yep, for our application, we have an `executionId` that is sent in essentially every single WebSocket message.

But client and server use it to maintain a record of events.

Comment · 1 year ago
I think there is a way to do it, but it likely involves custom headers on the initial connection that the load balancer can read to route to the correct origin server.

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.

Comment · 1 year ago
Node has similar libraries like Socket.IO too, but it over-abstracts it a bit in my opinion.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton