Skip to content

Welcome to Hlambda

Meta API - ECMAScript code as metadata!

Hlambda is easy to manage, meta API server, with rich console UI and CLI tool.

Image title

Benefits of hlambda server

  • CLI to manage your server
  • Web UI to manage your server
  • Less boilerplate. Your code is smaller and only handles custom business logic
  • No build scripts or pipelines needed to build your code from the source (build pipeline is optional)
  • Link your server to auto sync with the git repository, provide access and just refresh the metadata (In the roadmap, soon™)
  • API is aware of the logs, (list the logs with the CLI/UI)
  • Export all your constants
  • Export all your errors
  • Faster prototyping
  • Less DevOps
  • Resilient to errors
  • Dependency injection
  • Can be used/deployed without docker
  • Environment variable injection and override (Developer can debug and manage API by overriding its deployed env state).

But why Hlambda?

Well if you need easy to setup, out of the box express server to host your routes and manage just the metadata (your code, environments, logs, etc.), while having console to edit the metadata, executing requests, reading logs and manage API via CLI or UI. Hlambda is something that can help you a lot, and speed up your development process.

The main use case for hlambda and for what it was designed for is to easily add additional business logic for Hasura GraphQL API (Custom actions). In short Lambda's for Hasura, thus the name: hlambda

If you are having trouble with remembering the project name: "The momentum of a photon, p, measured in kilogram meters per second, is equal to Planck's constant, h, divided by the de Broglie wavelength of the light, lambda, measured in meters (p = h / lambda)"

...a friend told me this is the way he remembers. 😄

Manifesto

  • Development should be easy.
  • All useless boilerplate should go away.
  • Your code and dependencies can be just the configuration of the server instance.
  • Your API can manage itself.
  • Your API should be error Resilient as much as it can be.
  • In development environment deployment of single broken REST route should never stop other healthy routes from working.
  • In production you can freeze/bake the metadata state and disable all the meta API routes.
  • Your API can be aware of the logs it created.
  • API should export all the errors that can happen.
  • API should export all the constants and environment variables that it is aware of.
  • API can manage and override its own env state.
Back to top