Skip to content

Latest commit

 

History

History
104 lines (72 loc) · 4.57 KB

README.md

File metadata and controls

104 lines (72 loc) · 4.57 KB
Raw

hyper on Render

This is a recipe for deploying the hyper Service Framework to Render

Deploy to Render

Motivation

The hyper Service Framework api is built to be a consistent service boundary between your applications and the services tier that powers them, such that your apps and business logic do not become coupled or beholden to your services tier. This allows application devs to focus on business logic, and DevOps devs to focus on infra and network topology, all while discouraging vendor lock-in.

The hyper Service Framework itself is built such that it can be deployed to many different providers/platforms. hyper can even be self hosted on your own infrastructure or cloud.

If you're a small team, or would rather not manage infrastructure or dive into a Cloud Provider, you might choose to use a PaaS instead. A popular option is Render which offers near-turnkey hosting for containerized applications, as well as some managed service offerings.

How's It Work

This recipe uses Render's Infra as Code feature. Using the render.yaml file, 5 docker services are provisioned:

  • The hyper Service, using the RESTful app, so that you may consume your services over Http.
  • MongoDB to power hyper Data Services
  • Redis to power hyper Cache and Queue Services
  • Elasticsearch to power hyper Search Services
  • MinIO to power hyper Storage Services

Where needed a Render Disk is mounted on the service, for Persistent storage.

There is also a small middleware added to the hyper Server that enforces AuthN using an Authorization Bearer JWT token in the authorization header.

MongoDB, Redis, and Elasticsearch are all deployed as Private Services only accessible from your other Render services, and not from the internet.

The hyper service is deployed as a public Web Service, so that it can receive traffic from the internet.

If your application consuming hyper is also deployed on Render, you could also change the hyper Render Blueprint to be deployed as a Render Private Service, so that it is only accessible from your other Render services.

The MinIO service is made public, so that it may receive requests to presigned url retrieved via hyper Storage services.

You can also add the MinIO Console as public web service to your Render Blueprint!

Usage

Start by cloning the repo and connecting to your Render account. Render will start to deploy each of the services into your account.

Because the hyper service depends on the other services, more specifically the secret values generated by each of those services, Render will pause deploying the hyper service until the others are deployed.

Once all the services are deployed, navigate to the hyper service's Environment Variables, and obtain the SUB and SECRET. You will use these to create and sign JWTs to consume your hyper services.

You can also use the hyper-connect SDK to consume hyper, which creates and signs JWTs automatically for you.

Using hyper-connect

Once you have your SUB and SECRET that are generated by Render on the hyper service and its public Render url. You can use these as part of your connection string you pass to hyper-connect:

import { connect } from 'hyper-connect';

const { data, cache, storage, search, queue } = connect(
  `https://{SUB}:{SECRET}@{RENDER_HOST}/{DOMAIN}`,
);

hyper Services are created on a hyper Server, within a hyper Domain.

A Domain is simply a logical grouping of hyper Services hosted on a hyper Server.

hyper Domains are commonly used to distinguish sets of hyper Services across applications ie. a Foo App Domain and Bar App Domain.

Learn more here