DEV Community: hyper

Introducing Hyper {Nano}: Hyper Cloud in a Bottle ⚡️

hyper — Mon, 02 May 2022 13:00:02 +0000

In my previous post about Clean Architecture at Hyper, I briefly mentioned Hyper Nano.

In this post, i’d like to focus on Hyper Nano, and how you can use it to build awesome applications using the Hyper Service Framework and Hyper Cloud.

We are currently offering hyper cloud tours and a free Architecture Consultation, If you think we could help you build your next great project, let us know!

What is Hyper Nano

At discussed in my previous post, Hyper Nano is the compiled Hyper Service Framework using a set of “local development” adapters, that allows Hyper to be run locally, is simple to spin up and simple to blow away.

It currently is running the following Hyper Services:

data (powered by PouchDB)
cache (powered by Sqlite)
storage (powered by your local file system)
search (powered by Sqlite and Minisearch)
queue (powered by DnDB and an in-memory queue)

Usage

You can find usage documentation in the README, but I wanted to highlight some key features here.

Hyper Nano supports “bootstrap” and “purge” options. Bootstrap can be used to create hyper services on startup. Purge can be used to destroy services on startup.

This will require the --experimental flag to be set.

You can read about how to use these features here

Given this, here are some common workflows you can enable with Hyper Nano.

Workflows

Here are some common workflows you can enable with Hyper Nano when building applications with Hyper. I will assume the Hyper Nano binary was downloaded and named hyper-nano and your application domain is named foo-app

I will also list some pros and cons of each approach (Tyler’s opinion), and share the workflow we use at hyper every day, to build hyper.

Local Development with Persistent Services

This is the the most common workflow. You are developing your app, using Hyper as a services tier, on your own machine using localhost, and you'd like to have a persistent set of services. This would be like running Postgres, Redis, Elasticsearch, etc. using docker-compose and mounting volumes onto each, so that the data persist across containers.

First you would download a hyper binary.

You would most likely not include the hyper binary or it’s files in __hyper__ under source control, just like you wouldn't commit a local database to source control.

You would start Hyper Nano using ./hyper-nano which would start it listening on port 6363. As a one time setup, you would create the Hyper Services you needed, either using the REST api or hyper-connect. Then your application would consume those services using hyper-connect passing http://localhost:6363/foo-app.

Alternatively you could pass flags to bootstrap those services ie. ./hyper-nano --experimental --data --cache --domain=foo-app which will create the database and cache service, and noop if they already exist.

After the initial setup any time you wanted to start developing, you would just start Hyper Nano with ./hyper-nano and develop away.

If you ever wanted to wipe all the data, you could either use the REST api, hyper-connect, or just simply delete the __hyper__ folder used to store data in Hyper Nano. You would then need to recreate those services again, just like if you deleted a database, and had to recreate it.

For data, You would either seed the services or gradually build data up in the persistent services aka. no local seed data required

Pros:

Is most familiar development workflow for most folks
Sandboxed to localhost
Doesn’t require internet connection

Cons:

Manual steps to create and remove services that aren’t needed when using Hyper Cloud
If the data in the services becomes corrupted, a common occurrence during feature development, and there is no seed data being used. You have to manually correct it, or wipe the data away and build it up again.
Each new feature uses the same Hyper service instances aka. No feature sandbox
Must maintain a runtime on local ie. Node, Yarn, Deno, installing dependencies, cross versions, etc.
Each developer must do these steps to set up a local environment, which could cause divergence aka. “it works on my machine” scenarios

Local Development Using Ephemeral Services

This workflow is similar to above, but the idea is that you blow away and recreate the services each time you start work on a new feature.

You would start Hyper Nano with ./hyper-nano --experimental --data --cache --purge --domain=foo-app, which would destroy any old data and cache service, and then recreate them. Then you would develop as normal.

For data, since the services are deleted and recreated every time, you would need some sort of seeding mechanism. hyper.data.bulk on hyper-connect is a great option for performing this.

Pros:

No manual steps to create and delete servcies
Sandboxed to localhost
Feature development is sandboxed
Doesn’t require internet connection

Cons:

You must have a seeding mechanism (I personally see this as a pro which I will cover in the next workflow)
Must maintain a runtime on local ie. Node, Yarn, Deno, installing dependencies, cross versions, etc.

Cloud Development using Ephemeral Services

This workflow uses Ephemeral Hyper Services, but also an Ephemeral development environment as well. Using services like GitPod or GitHub Workspaces, you would spin up a new environment for each new piece of work being done. This environment setup should download ./hyper-nano and start it, using bootstrapping and purging to create services. As part of environment set up, you would also run your seed script to bulk load your services with data.

When you were done developing, you would push up your code to the remote, and then simply close the Cloud Environment. For the next piece of work, rinse and repeat.

Pros:

No manual steps to create and delete services
Sandboxed to Cloud Environment
Feature development is sandboxed
All are other dependencies are sandboxed ie. Runtime, dependencies, are sandboxed (no nvm!)
Encourage trunk based development
This becomes your onboarding flow for new developers, so your onboarding flow always stays up to date and lean
Less likely for environment divergence to occur aka. no more “it works on my machine”.

Cons:

Environment setup must be codified for something like GitPod to execute.
Needs an internet connection
You must have a seeding mechanism (I personally see this as a pro in this setup)

What Hyper Does

You can probably guess that we use the “Cloud Development using Ephemeral Services” workflow at hyper. We develop exclusively in Cloud Environments, and spin up new services and seed data for each new feature or bug.

When we are done with the feature, we simply close and forget that environment and then spin up a new one.

We use a .gitpod.yml file to configure our Cloud Environment with everything to start developing.

This means our seed data must be kept up to date, which requires some work, but I personally think this is a good thing. It keeps our seed data from becoming stale tech debt, and keeps onboarding new team members lean. It also means that we can tune our seed data to include more and more data sets to support feature development, as more features become part of the application.

Suppose you had a subscription based platform. You could seed data where one customer is in a “paid” subscription state, another customer is “overdue” subscription state, and another customer is “no subscription” state. It becomes easy to build features for each of those customer states with your set of seed data

Deploying your Application

Eventually you’re going to need to deploy your application, where your application consumes your actual services in your Hyper Cloud Application.

If you’re using hyper-connect to consume your Hyper Services, all you have to do swap out your connection string that you pass to hyper-connect and that's it! From local development to using actual services without any code changes 😎, for all of your Services.

Conclusion

Hyper Nano has been a huge boon for us at hyper developing products like Hyper Cloud. Consider trying Hyper Nano in your development workflow and let us know what you think!

We are currently offering hyper cloud tours and a free Architecture Consultation, If you think we could help you build your next great project, let us know!

Clean Architecture At Hyper ⚡️

hyper — Wed, 27 Apr 2022 13:00:05 +0000

With the beta launch of hyper cloud, I want to share a little bit about how hyper itself works under the hood, and how we leveraged the architecture to build tools that we use to build hyper, with hyper.

We are currently offering hyper cloud tours and a free Architecture Consultation, If you think we could help you build your next great project, let us know!

Clean Architecture 🧼🛠

At Hyper, we embrace the Clean Architecture approach to building software. This means separating side effects from business logic and working hard to keep business logic separated from other components.

What is business logic? It’s your secret sauce; the data models that may interact with each other, and the rules that govern how those models interact with each other. It is not a database, and it is not a frontend framework. Those pieces are side effects that tie into your business logic. As Robert C. Martin, author of Clean Architecture put it:

there is nothing architecturally significant about arranging data in rows within tables

Source: https://en.wikipedia.org/wiki/Business_logic

I won’t go into great detail here, there are tons of material on this topic. We encourage teams to build software using the tenants of “Clean Architecture” and we’ve built hyper to encourage doing just that. And not only do we encourage teams to build software using the tenants of Clean Architecture, but this is also how we architected hyper, internally.

Under The Hood 🚘

Hyper is built using a “Ports and Adapters” approach.

The general idea with Ports and Adapters is that the business logic layer defines the models and rules on how they interact with each other, and also a set of consumer-agnostic entry and exit points to and from the business layer. These entry and exit points are called “Ports”. All components external to the business layer, interact by way and are interacted with, the Ports. A Port defines an api but knows nothing about the mechanism or the impetus. Those two things are an Adapter’s job.

Adapters perform the actual communication between external actors and the business layer. There are generally two types of Adapters: “Driving Adapters” and “Driven Adapters”.

A driving adapter calls into the business layer, by way of a Port. The driving adapters can generally be thought of as the “presentation layer”. It could be a web application, a desktop application, a CLI, anything that initiates some action on the business domain.

A driven adapter is called by the business layer, to interact with some backend tool, ie. a database, storage bucket, cache, etc. The business layer calls into the driven adapter by way of the Port. Driven adapters implement the Port defined by the business layer.

So the flow generally looks like

Driving Adapter <--> Port <--> Business Layer <--> Port <--> Driven Adapter

Source: https://betterprogramming.pub/hexagonal-architecture-for-ios-part-1-600441c186b7

Benefits

Because the business layer enforces the Ports, and all external interactions with external components happens through the Ports, the business layer is encapsulated. The benefits of this for the system cannot be overstated.

It means the business layer, the models and the rules governing them, can be developed before choosing things like a database, or a frontend framework. Better yet, the business layer can be tested before choosing any of those things. Covering business logic almost entirely with unit tests is a boon for confidence in the system.

When building software, a decision is a set of constraints, and ideally the pros of accepting those constraints outweigh the cons. So we ought to defer accepting constraints until we have as much information as possible to inform that decision. Clean Architecture enables us to do just that.

It also allows for the separation of concerns. Each tier of the architecture can change without requiring changes in the other tiers. This is important because some tiers are more volatile than others; typically the UI of an application changes faster than business rules for example.

The only time we must touch multiple tiers is if a Port is changed. And that is usually a find and replace

Hyper Clean Architecture Lingua Franca 📚

Hyper Apps 🎮

The Driving Adapters in the Hyper Service Framework are called “Apps” or “Apis”. We currently have two Apps available shown here. The GraphQL app will need to be overhauled eventually, but the Opine app is up to date and provides a RESTful api.

In the future, we would like to see more app offerings. A CLI app, a GRPC app, we’ve even discussed a Service Worker app, so that Hyper could be run entirely in the browser, on a Service Worker 😎.

Hyper Core 🪨

The business layer in Hyper is called core which contains all of the business logic and enforces each Port. Core also defines the Port that a Hyper App calls.

Hyper Ports 🔌

There are multiple Ports defined in the Hyper Service Framework. You can see them all here.

Hyper Adapters 🛠

The Driven Adapters in the Hyper Service Framework are simply called “Adapters”. You can see many of them here. Each adapter implements a Port api and does the heavy lifting of communicating with an underlying component.

Hyper Services

A Hyper Service is combination of the components described above:

A Hyper App
Hyper Core
An Adapter Port
A Hyper Adapter

For example, a Hyper Data Service might be:

RESTful api -> Core -> Data Port -> CouchDB Adapter
// or
GraphQL api -> Core -> Data Port -> Postgres Adapter
// or
CLI -> Core -> Data Port -> DynamoDB Adapter

A Hyper Cache Service might be:

GRPC api -> Core -> Cache Port -> Redis Adapter
// or
GraphQL api -> Core -> Cache Port -> Sqlite Adapter
// or
CLI -> Core -> Cache Port -> FlatFile Adapter

A Hyper Search Service might:

GRPC api -> Core -> Search Port -> Elasticsearch Adapter
// or
RESTful api -> Core -> Search Port -> Minisearch Adapter
// or
CLI -> Core -> Search Port -> Algolia Adapter

I hope you’re noticing something:

Adapters and Apps are interchangeable. This is how we can test our business layer without choosing a database, for example. We just mock the Adapter that communicates with the database.

This also means we can run the Hyper Service Framework using a set of “local development” adapters.

Hyper {Nano} 🍷

Hyper Nano is the compiled Hyper Service Framework using a set of “local development” adapters. It’s the same Hyper RESTful app, and the same Hyper Core, but with a set of adapters that allow it to run locally sandboxed, and simple to quickly spin up and then blow away.

data (powered by PouchDB)
cache (powered by Sqlite)
storage (powered by your local file system)
search (powered by Sqlite and Minisearch)
queue (powered by DnDB and an in-memory queue)

Hyper Nano is great for development or sandboxed short-lived environments ie. GitHub Workspaces or GitPod.

Hyper Nano has some other features that we will cover in another blog post.

At hyper, we use Hyper Nano to develop hyper products. When building hyper cloud, we simply spin up a Gitpod Workspace, which installs our dependencies, starts Hyper Nano, and bootstraps our services. The result is a completely sandboxed local development environment in Cloud 😎 ☁️⚡️. Yes, we use hyper to build hyper.

Then in deployed environments, we use the Hyper Service Framework, but with actual Adapters to actual external services. Our interactions with Hyper does not change between Hyper Cloud and Hyper Nano

Conclusion

We try to practice what we preach, we dogfood practically everything we build, and hopefully, this provides some insights on how Hyper works internally and why you might consider trying Clean Architecture and Hyper.

We are currently offering hyper cloud tours and a free Architecture Consultation, If you think we could help you build your next great project, let us know!

Acknowledgements

https://en.wikipedia.org/wiki/Business_logic for the 3 tier architecture graphic
Oleksandr Stepanov’s awesome post on Hexagonal Architecture, which provides some great visualizations of the architecture

Introducing the Remix Hyper Stack ⚡️+=✨

hyper — Fri, 22 Apr 2022 13:00:05 +0000

At hyper, we love web standards. Web Standards are rules established by international standards bodies that define how the web works. These bodies put a lot of effort into ensuring the Web is maximally usable and accessible.

If you’ve ever ended up on MDN Web Docs then you’re probably familiar with some of these Web Standards (fetch anyone?).

Our love of Web Standards is why we have embraced tools like Deno 🦕 to build hyper.

So whenever we see another framework or tool that is embracing Web Standards, that get’s us excited! One of these frameworks is Remix

Remix run (the web 🌎)

Hyper is a sponsor of Remix Conf.. Consider coming to Remix Conf. to learn more about Remix. If you see a hyper shirt, come say hi!

Remix is a full stack web framework.

Remix is a full stack web framework that lets you focus on the user interface and work back through web standards to deliver a fast, slick, and resilient user experience.

Like other frameworks such as NextJS, NuxtJS, and SvelteKit, Remix blurs the lines between client and server, providing a unified development experience that embraces the emerging “full stack developer” role.

With Remix, you write frontend (React) and backend code in routes files. Your frontend code sits right next to the server code that handles input submitted from that UI. You use Web Standards like fetch, Request, and Response to integrate your frontend and backend handlers. It supports TypeScript, bundling, accessibility, and route optimization, right out of the box. So far, building apps with Remix feels very ergonomic and easy to reason about.

Remix does a ton for you. If you’d like to learn more, consider checking out their docs.

Remix Stacks

One of the new features in Remix, that we are really excited about, is Remix Stacks. Remix Stacks is a feature of the Remix CLI that allows you to generate a Remix project quickly and easily. There are some official stacks described in their docs that come with:

Database
Automatic deployment pipelines
Authentication
Testing
Linting/Formatting/TypeScript

Remix Stacks also supports custom templates, where you can build your own Stacks and then use the Remix CLI to spin up those stacks!

We were wanting to build a starter project for hyper cloud and Remix. So when Remix Stacks were released, it seemed like a perfect opportunity.

Introducing the Remix Hyper Stack ⚡️💿

We are happy to introduce the Remix Hyper Stack, a custom Remix Stack that comes with everything you need to start building 🛠, and shipping 🚀 with Hyper Cloud and Remix.

Out of the box, the Remix Hyper Stack comes with:

AWS deployment with Architect
Hyper Cloud integration via hyper-connect
Zero-setup ⚡️ local development using hyper nano
GitHub Actions for deploy on merge to production and staging environments
Email/Password Authentication with cookie-based sessions
Styling with Tailwind
End-to-end testing with Cypress
Local third party request mocking with MSW
Unit testing with Vitest and Testing Library
Code formatting with Prettier
Linting with ESLint
Static Types with TypeScript

Everything that you need to start developing locally. Then once you’re ready, just add some GitHub repo’s secrets and start deploying on AWS, consuming hyper cloud as your services tier 😎 💸.

Usage

To use the Remix Hyper Stack, simply use the Remix CLI:

npx create-remix --template hyper63/remix-hyper-stack

The CLI will prompty you for some questions, pull down the stack, and set it up for you. Then just run npm run dev and start building!

What’s it doing?

So what are each of the parts of the stack doing? Let’s go through it.

The cool thing about Remix Stacks is that they are completely customizable. If you don’t like a piece, simply change it after setup, or even fork the original stack and create your own!

AWS Deployment via Github Actions

The Hyper Remix Stack comes with a Github Workflow that will deploy your application to AWS using Architect. Architect handles setting up ApiGateway, S3, and Lambda together, so that your application can scale to meet production demand.

The workflow will run all your quality checks: Linting, Type checking, Testing, and Building. If all goes well, the the workflow will deploy your applciation. Out of the box, the workflow will deploy the main branch to a production environment and the dev branch to a staging environment. You can even setup separate credentials between production and staging in cases where you have a separate AWS account for each environment.

Hyper Cloud Integration with hyper-connect

hyper cloud is a scalable, backend cloud-based service that you can use to spin up databases, caches, storage buckets, search engines, and persistent queues, no dev-ops required.

Instead of figuring out how to deploy services in the cloud, securely, and to scale, just use hyper cloud and then consume your services using the hyper-connect SDK or REST. Focus on building features ⚡️, not cloud plumbing 🪠.

Learn more at our docs

Local Development using hyper nano

Although you can use a hyper cloud application to develop, the Remix Hyper Stack also comes integrated with hyper nano. hyper nano is an instance of hyper that runs all of your hyper services locally, using local hyper service adapters! It works great for local development, and short-lived ephemeral environments like GitHub Workspaces or Gitpod

At hyper, we exclusively develop using short-lived, cloud-based, environments. And we use hyper nano to do it. In short, we build hyper using hyper.

hyper-connect works seamlessly with both hyper cloud and hyper nano. Consume hyper nano for local development, then your deployed application consumes hyper cloud with no code changes. hyper connect handles that for you.

Styling, Type Checking, Linting, Testing, Oh My! 🐯

The Remix Hyper Stack comes with linting using EsLint, type checking using TypeScript, testing using Vitest, and end to end testing using Cypress.

All of this is integrated with Github Workflow, so all your quality checks pass before deploying your application.

Clean Architecture With Hyper

Hyper embraces the Clean Architecture approach to building software. This means separating side effects from business logic and striving to keep business logic separated from other details of the application.

This has lots of benefits:

Business logic is framework agnostic and can be reused
Remix/NextJS/CRA/Preact
Vue
Svelte
CLI (The framework doesn’t even need to be web based!)
Mobile app
Business logic is infrastructure agnostic:
Database
Cloud Provider
Deployment configuration ie. lambda, Docker, K8s, etc.
Easier to test business logic (unit tests and TypeScript cover most of it!)
Separation of concerns

All of the business logic for this application can be found in

app/services. Each service receives its side effects via dependency injection which are then easy to stub during unit testing.

Our business models are simple schemas built on zod used to validate the correctness of data flowing in and out of our business logic layer. You could use anything to validate the contracts with your business logic, I chose zod because it's what we use at hyper. Joi, Yup, there are tons of options out there.

The important part of these schemas is that it puts enforcing our business logic contracts in the layer we control, not buried deep within a database schema, or a managed service where we have limited to no control. Doing that can cause coupling and unintended technical debt.

Because all side effects are injected via dependency injection, the business logic is incredibly easy to test. The business logic is practically fully tested using just unit tests.

The rest of the code in the project is all effectively glue code if you will, into our business logic, based on what our Remix app wants to do, in this case, a note taking app.

Perhaps we have another application that will run NLP across notes, or an administrator application with separate authentication needs. Those applications can reuse our business logic just fine.

Conclusion

We at hyper are very excited about Remix and Remix stacks. A huge shout out to the Remix team and to Kent C. Dodds for showing us this cool new feature.

Try out the Remix Hyper Stack today, and let us know what you think!

We are also sponsoring Remix Conf. and will be there, so if you see a hyper shirt, come say hi!

Using CloudFront to Redirect HTTP -> HTTPS on ApiGateway

hyper — Tue, 05 Apr 2022 13:00:04 +0000

ApiGateway is great service for quickly spinning up a resilient, performant API layer for your application.

An increasingly common practice, as a result of putting frameworks like NextJS, SvelteKit, and Architect behind ApiGateway on a Lambda integration, is to serve static assets, as well as data, using a single ApiGateway. The ApiGateway is assigned a Custom Domain name, and serves the web applciation, assets, and the api the serves the data to power it.

The Problem

When typing a url into a browser, if the protocol is not specified, most browsers will default to http. If your site is served up via ApiGateway, this will result in a failure to connect and an error:

This is because ApiGateway only supports https. This isn't a great user experience. Instead of an error, it would be great to redirect http -> https.Unfortunately, this involves more moving parts than is expected. There isn't a setting that you can toggle in ApiGateway; http isn't supported. To get around this, most solutions use CloudFront to perform this redirect. There were some tutorials that already exist on how to do this, but all them were missing some key details. This post will describe how I used CloudFront in front of ApiGateway to redirect http to https.

Set up CloudFront

In order to set up CloudFront to redirect http to https, you will need to set up a CloudFront distribution to:

redirect http -> https
forward all traffic to the invoke url of your ApiGateway

There some quirks to this, that I will get into later in this post

First, navigate to the ApiGateway dashboard and take note of the invoke url for your Gateway.

Next, navigate to the CloudFront dashboard and create a new CloudFront Distribution.

For Origin Domain paste in your ApiGateway’s invoke URL.

For Origin Path if you are using your default stage, leave blank.

For Name , name the origin whatever you’d like.

Under Viewer Protocol Policy , check Redirect HTTP to HTTPS

Under Allowed HTTP Methods , check GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE

This Next Piece is Important!

Scroll down to Cache key and origin requests

Under Cache Policy choose CachingDisabled policy. This will prevent CloudFront from caching responses from your ApiGateway.

Under Origin request policy choose AllViewer policy. This will make CloudFront forward all headers it receives from the request to your ApiGateway. You will need this if your application uses cookies or Authorization header for AuthN/Z.

If your ApiGateway uses a custom domain, this next piece is important!

Scroll down to Settings

Under Alternate domain name (CNAME) add the custom domain that is currently assigned to your ApiGateway. If you’re using ACM, choose the corresponding certificate for that custom domain.

By default, ApiGateway has CORS disabled. If CORS is disabled on your ApiGateway, DO NOT remove the custom domain configuration from your ApiGateway. The custom domain configuration should match between CloudFront and ApiGateway. This will ensure requests are not rejected by ApiGateway due to CORS.

Create the Distribution. After a few minutes, your Distribution should be deployed.

Copy your Distribution domain name , and update your DNS, that currently resolves to your ApiGateway, to instead resolve to your Distribution’s domain name. It may take some time for DNS to propagate.

This should be all you need to set up CloudFront in front of your ApiGateway, in order to redirect http -> https. You can verify by navigating to your site, being sure to use the http protocol. Do this in a browser, and view the redirect in the network dev tools tab. You can also use cURL with the -L flag to follow redirects and see the redirects listed out listed out.

The important bits

Most of this is probably self explanatory. The pieces that aren’t as intuitive:

The Origin request policy MUST forward all headers received to ApiGateway. AWS has a precanned policy called AllViewer that does this, but you can also create your own. Just make sure the headers you need are forwarded to ApiGateway by CloudFront
If CORS is disabled for ApiGateway, the custom domain configuration MUST exist on both the CloudFront distribution and the ApiGateway. Otherwise, ApiGateway will reject the request.

Hopefully this was helpful!

hyper cloud beta is a go!

hyper — Mon, 04 Apr 2022 12:41:12 +0000

The hyper team is proud to announce ⚡️hyper cloud⚡️ is now in beta.

hyper is a dev-ops team wrapped in a single API. Our easy-to-learn API manages data, cache, storage, search, and queue services.

Okay, it’s confession time 😬.

A long time ago, way before hyper, we may have contributed to codebases that may have turned into a big pile of 💩. As new features were attempted, unintentional technical debt and complexity increased. Our product slowly became intertwined and deeply coupled with the underlying services. We sacrificed quality to deadline pressure. Our developer happiness turned into frustration 🤯 and developer retention suffered. Adding developers and site reliability engineers frankly didn’t solve the problem. Maybe this sounds familiar to you.

We learned from our mistakes by focusing on specific fundamentals: shifting left, continuous delivery and clean architecture. The result is hyper: a game-changer for front-end developers, startups, agencies, or anyone looking to save time, energy, and money 💵.

Features are king 👑.

Building the services that power your features is difficult to get right. We took what we’ve learned about building scalable, secure, and performant service tiers and crafted hyper cloud. With hyper cloud as your services tier, you can focus on building what matters most: features that delight your customers.

How much of your budget is focused on your backend service personnel? Minimize the human resources required to build and maintain your software product. Bypass the red tape, frustration, bureaucracy, and uncertainty around creating cloud-based backend services. Stop wasting precious resources 💸. Shift your personnel to the side of your solution that your customers need: features and business logic.

With a few clicks, you get robust and scalable backend cloud services including a document datastore, in-memory cache, search engine, storage buckets, and queues. Sign up for free 😀 with your GitHub account and create backend services in seconds. When you’re ready to step it up, we have plans starting at $99 a month.

A DX that rocks 🎸

Developers will enjoy a delightful DX 🤘🏽using a REST API or the hyper-connect SDK that supports Node and Deno 🦕. Our API provides a consistent shape across all our services, making it easy to learn and apply.

Support options

We’ve got your back! 😉 We provide basic and extended support options. Learn by doing with our workshops 💪, quickstarts 🚀, blog 👩🏽‍💻, and YouTube tutorials.

Introducing our CTO service

Our new fractional CTO service for startups provides the oversight and guidance necessary to cultivate quality, productivity, and accountability. Let us help you curate the technology strategy and vision of your company’s software tools and technologies.

Hyperfocus on features. Delight your developers and customers. Put your applications on solid footing. Hyper cloud is ready to go.

Using Zod to Parse Function Schemas

hyper — Mon, 14 Mar 2022 14:00:03 +0000

Data validation, ensuring the data your system receives is in some expected shape, is crucial for a mature system. The most important part of a system, the business logic, expects and provides data in a particular shape, and so validating these shapes is an important part of running and testing your business logic.

There are a ton of options. TypeScript is widely used and will provide compile time checks on your code. Most systems require runtime validation at its boundaries. For example, I may have a web server endpoint that expects a certain payload shape that it will need to validate, at runtime. I can’t use TypeScript for that. In addition, TypeScript adds a build step (unless you use Deno 🙂), and TypeScript checking can be bypassed using catchall types like any and unknown. I can disallow those types, using strict, but I now am beholden to library types, types I don't have control over or may be incorrect. So then using the any escape-hatch becomes an exercise in design and discipline, for each dev that works on the system. At the very least, that's cognitive overhead that can't be ignored, and at its worst, an obstacle to delivering quality software.

My last points were not to knock TypeScript, it’s great and we use it. My point is that it takes experience and discernment to know where TypeScript is a boon, and where TypeScript is an obstacle. TypeScript catches tons of common bugs, but it’s just another tool in the toolbox. It takes a good developer to decide how and when, and to what extent, to use it.

So regardless of using compile time checks, we need some way to validate data shape at runtime, so that bad data doesn’t get into the crucial parts of the system. There are tons of runtime options. Joi or Yup are both great runtime options. At hyper, we use a library called Zod.

At hyper

The hyper service framework we’ve built at hyper, uses a “Ports and Adapters” architecture, also known as Hexagonal Architecture. This allows swapping out the underlying components that power hyper services, without having to change the hyper core.

To accomplish this architecture, hyper core must specify a contract or “port”, for each service that it offers. Then a service adapter must implement one of those ports in order to be used by hyper core:

Each of these ports are published modules. You can see hyper’s data port here. All service ports are implemented using zod. We define a Zod schema for the adapter object. Then, given an adapter implementation, the port wraps each function implemented by the adapter with the corresponding z.function() schema that enforces the contract between hyper core and the hyper adapter. Zod even has a feature that allows TypeScript type inference from schemas!

function schemas are a really cool feature of zod as they allow for separating the validation logic from the "meat" of the implementation. Adapters don't have to worry about validating inputs and outputs for each function implemented; hyper core does that. In fact, as an adapter developer, you can use the hyper port as part of your unit tests, ensuring your adapter returns the proper responses for each api!

import { data } from 'https://x.nest.land/hyper-port-data@1.2.0/mod.js'

// wrap your impl with the port
const myDataAdapter = data({...})

/**
 * Now simply assert each api call,
 * and Zod parses the inputs and outputs.
 * If the test doesn't throw,
 * you know you've implemented the port!
 */
test('should return the correct shapes', async () => {
  assert(await myDataAdapter.createDatabase('foo'))
  ...
})

This is precisely how hyper core wraps each adapter.

A function schema

A function schema in zod looks like this:

const MyFunctionSchema = z.function()
  .args(
    z.string()
  )
  .returns(
    z.promise(z.object({ ok: z.boolean() }))
  )

You can then pass a function to the schema’s implement method, which returns a new function that automatically validates its inputs and outputs:

function businessLogic (str) {
  ... // do some stuff
  return Promise.resolve({ ok: true })
}

const withValidation = MyFunctionSchema
    .implement(businessLogic)

withValidation('foo') // passes
withValidation(123) // throws ZodError because input doesn't match schema

MyFunctionSchema.implement(
   str => Promise.resolve({ not_ok: true })
)('foo') // throws ZodError because output doesn't match schema

Function overloading

You may have a function that supports multiple input shapes and multiple output shapes. Zod does have support for Union types which works as a sort of logical OR type, And you could use those to build a function schema:

const stringOrNumber = z.union(
  [z.string(), z.number()]
)

const identity = z.function()
  .args(stringOrNumber)
  .returns(stringOrNumber)
  .implement(i => i)

// equivalent TS type
type stringOrNumberIdentity =
  (i: string | number) => string | number

This works if either input can produce either output, but if there is a 1:1 relationship between input and output, then we will need something different. For that, what we really want is a type like this:

type stringOrNumberIdentity =
  (str: string) => string | (n: number) => number

We can accomplish this with two zod function schemas, and then parsing the argument using each schema's parameters() api. parameters() returns the Zod schema for the input args:

const strIdentity = z.function()
  .args(z.string())
  .returns(z.string())

// schema for the args of strIdentity
const strInput = strIdentity.parameters()

const numIdentity = z.function()
  .args(z.number())
  .returns(z.number())

const myFn = ....

const identityWithValidation = z.function()
  .args(stringOrNumber)
  .returns(stringOrNumber)
  .implement(i => {
    if (strInput.safeParse(i).success)
       // parse i/o as string
       return strIdentity.implement(myFn)(i)

    // parse i/o as number
    return numIdentity.implement(myFn)(i)
  })

With this, we can enforce a 1:1 relationship between input and output, for an overloaded function.

Conclusion

A system will need some sort of runtime validation eventually. Consider separating your validation logic into composable pieces using a library like zod

hyper Enhancements

hyper — Wed, 09 Mar 2022 21:34:25 +0000

Announcing the Crysknife release!

The hyper team is pleased to announce new enhancements to our service cloud platform for startups. hyper cloud is a scalable, backend cloud-based service to store and retrieve resources such as data, files, cached data, etc. No dev-ops required.

Enhancements

🚀 Updated hyper-connect with Queue and Storage. The hyper-connect SDK now supports queue and storage services.
🔥Delete a service instance
🎉 hyper-ext-model is an experimental hyper-connect extension that creates a model for an application that uses the hyper service.
🎓 New NodeJS Queue Quickstart
😎 hyper vision enhancements
🪄 Enhanced service type progress steps
👩🏽‍💻 Improved error responses from cloud.hyper

🍾 We’ve reached over 100 accounts created on hyper cloud. Sign up for a free hyper cloud account.🍾

For more details, head on over to What’s New.

Keeping it steezy,

The hyper team

March hyper madness

hyper — Sat, 05 Mar 2022 15:02:30 +0000

hyper is going BETA! ⚡️️️⚡️

Our small developer preview has reached 100 accounts 🎉 and we are thankful 🙏 for the support and encouragement. Now that all of our hyper OSS ports are available via the cloud service we are ready to invite more developers to the platform.

hyper will always have a free tier for developers, giving developers a chance to evaluate, prototype and experiement.

Signup and start innovating today with hyper at https://dashboard.hyper.io

Events in March

There is a lot going on in March 2022 in the hyper verse.

Keep on a lookout for the hyper BETA announcement! 👀

Community

Join our Slack community and say 👋 https://hyper.io/slack

Ship First Development

hyper — Thu, 24 Feb 2022 10:49:57 +0000

Just do it, before you write a single line of code, automate your CI/CD pipeline, have a single passing test, that tests nothing and have a deployment script that publishes your project to a staging environment, then a production environment, or embrace trunk-based development and just have a production environment. The point is to take the time upfront to set up your automated delivery pipeline first before you start to write code.

Before hyper, I was part of a team building a new software application and during the development process, everything was going great in our local environment. We were knocking out features left and right and our tests were verifying everything. As time went on, we would demo our work to our stakeholders, they would see the progress, but continue to make adjustments. These adjustments made the usability of the software better, but they impacted our capacity as the delivery date became closer. We shifted into another gear and began to implement the adjustments to the software application. Now it is time to ship our product, no sweat, we just push our code to the staging environment, then the production environment.

Code push “take one”, 404, what? How can that be? Is the database running? Is it accessible by the application? Is the application running? Check the logs, oh it’s missing a dependency that happened to be installed on the local machine. Code push “take two”, success! no more 404, but authentication does not work, I can’t sign up. WTF, oh crap, we need to create a new OAuth2 service for both staging and production, because the callback URL needs to point to the actual environment. Code push take three, another issue, anyway, eventually we get the app deployed by the delivery date, but the process was a process of stress. And because the timeline was so tight we completely lost focus of documenting our deployment process or the time to create robust delivery scripts.

What is the answer? It’s obvious, hire an SRE to do this for you right? Well, that will work, but that SRE needs to know everything about your app and technical stack, they need the time to understand what decisions you made and why you made them, then they need to start to dynamically create the deployment scripts, etc. Which will take time, and for many teams this is a valid process. But, I would like to recommend another approach, how about “ship your app first”, before one line of business logic is written. Take the time upfront to create the environments and write the automated deployment scripts and wire everything up end to end. Put a coming soon page up for your app.

Why?

Simple, automation is easier to get right when not under duress. For example, all of your tasks are complete, everything works on your machine, the reviews have gone great and the stakeholders are excited to see your deliverable in a production environment. They think it will only take a minute, a push of the button to promote your incredible code to a production environment that meets all the performance and security requirements.

Guess what? The CI/CD setup always takes time, even for simple things, it takes time and there are always issues that come up between your dev environment and the staging and production environments, you may find the tests don’t run in the CI because they are missing some unexpected dependency. Or you may find that the SSL Cert is not generating because y0u don’t have the correct DNS configuration and you need operations to configure it and they are busy with other issues. You may find that the Redis production server you were promised months ago is not ready yet. This creates drama and anxiety and leads to pressure and frustration.

Just ship it! 🐿

I have found, taking the time to set up CI/CD before writing code saves a lot of time and effort and reduces frustration at the point of delivery. Give it a try! You will be surprised.

CI (Github actions)

on:
  push:
    branches: "**"
    tags-ignore: "*"

jobs:
  test-deno:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        deno-version: [1.x]
    steps:
      - uses: actions/checkout@v2
      - name: Use Deno $
        uses: denoland/setup-deno@v1
        with:
          deno-version: $
      - run: make
        env:
          CI: true

CD (Github actions)

jobs:
  publish-nest:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: denoland/setup-deno@v1
        with:
          deno-version: v1.x
      - run: deno install -A -f --unstable --no-check https://x.nest.land/eggs@0.3.6/eggs.ts
      - run: |
          export PATH="/home/runner/.deno/bin:$PATH"
          eggs link ${{ secrets.NESTAPIKEY }}
          eggs publish --yes

What if I am adding a new feature to an existing product?

This is one of the best things about automation is the ability to use feature flags, create your new module and any dependencies with no code, but hidden behind a feature flag, and ship it! Make sure you can push changes in real-time, now all you have to do is write and test your feature, have the code reviewed, and BAM! you are done! “Easy peasy lemon squeezy!” 🍋

“Ship first, code later”

It may feel different, but it is not that hard and once you see the benefits you will jump for joy because you will no longer fear that push of code, it is done, you just have to make it work, which is the easy part 😀!

Not convinced? Trust the science!

A DevOps study conducted with 5,000 developer teams assessing the quality and performance, and it turns out the teams that ship code multiple times a day have a higher quality score than teams that ship code weekly, monthly or quarterly. To dive deeper read Accelerate — https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339 or google DORA metrics. It will be time worth investing. While you are reading, ship your code, go ahead right now and push that developing code behind a feature flag, and know, that when it works on your machine, it will work in production! 🐿

BONUS: Pro Tip

Develop in the cloud! By developing in the cloud, you keep your development environment clean and similar to the deployment environment. We use https://gitpod.io for our development environment and the result is frictionless experiences.

⚡️hyper can help you ship! Spin up Data, Cache, Search, Storage, and Queue Services with a single click! Check it out at https://hyper.io

It’s your dime.

hyper — Wed, 16 Feb 2022 20:08:25 +0000

For all the non-technical and technical folks out there, I’d like to explain the genius behind hyper and our software development kit (SDK). With hyper, you can put the power back in the hands of your application developers, get things done, and get back to delighting your customers.

Why should you consider using hyper?

Hyper is easy. Spin up backend services such as databases, search engines, and file storage buckets (to name a few) in seconds with literally a few clicks. It’s painless and friction-free.
Hyper is inexpensive. Start-ups that don’t have to spend hundreds of thousands of dollars on dev-ops personnel and database administrators have an advantage. Sign up and try hyper for free. When you’re ready to get serious, our Pro plan is just $99.00 per month.
Focus on features. Hyper allows you to focus on your time and resources on your customers. It’s your dime. Would you rather spend it on features or managing backend services?
Hyper is secure, scalable, and performant. This is what we do and we do it well.
Hyper is composable. What does this mean? A software developer can gracefully connect calls from one service, such as a call to the data service, to another, such as a call to the cache service. This is made possible by our promised-based SDK. Its consistent shape and behavior provide a great developer experience. See our related blog posts on Caching all the things and Composing Data and Cache.

In conclusion, hyper is unique in its ability to easily spin up new backend services, such as data, cache, queue, storage, and search in the cloud. How easy? Literally, just a few clicks. Skeptical? Sign up and create a new hyper application and backend services for free.

Keeping devs happy,

⚡️ hyper team ⚡️

Composing hyper data and cache services

hyper — Wed, 16 Feb 2022 20:05:33 +0000

hyper cache is a cache document store that provides a clean API to cache JSON documents. Caches are good for all sorts of things, to take the stress off of your transactional database when performing reads, to provide sessions for authentication, to contain simple aggregate values for dashboards and metrics, and more. Cache systems are complex and a challenge to set up and maintain. hyper removes this burden. hyper makes it easy to cache.

Why should I consider hyper?

For example, a dev could save data into the hyper data service followed by caching the document. Your application’s API can check for the data’s existence in the cache, and if it exists, retrieve popular data requests from memory rather than the disk. This has several advantages:

Speed : Retrieving data from cache is much faster than retrieving data from a database.
Conservation : Retrieving data from a cache takes pressure off your database.
Delight : A performant app delights the customer.

Here’s a TypeScript code sample that saves a JSON document into a hyper data service followed by caching the document into a hyper cache service. Since the calls to hyper-connect are promised-based, the calls to data and cache can be chained together:

In conclusion, while the code sample above demonstrates a fairly happy path, it does illustrate composition of individual hyper backend services. Ready learn more? Check out our blogs, docs, workshop videos, and quickstarts.

Shhhh don’t tell anyone. We’re building an experimental project: ⚡️ hyper-ext-model ⚡️. hyper-ext-model is a hyper-connect extension that creates a model for an application that uses the hyper service. Using this extension you can compose hyper data, cache, search, storage, and queue (notification) services into a generic data model to define a given domain and provide basic business rules. You can specify rollback modes of atomic or non-atomic for those not-so-happy-paths. 😀 😔

It’s all about the dx y’all,

The hyper team.

3 responsibilities every software startup should address

hyper — Tue, 15 Feb 2022 20:00:42 +0000

Are you a founder or leader of a software startup? If so you want to incorporate a CTO role into your organization, it does not necessarily require a full-time employee, but the role should be addressed within your technical team.

(see glossary below for clear definition of technical terms)

In working over 25 years with several startups to publicly traded companies and now consulting with many startups, I have found a recipe for success to creating high-performing development teams and high quality software. There are a set of requirements that should have focus and importance for the continued success of a software startup. This focus has been applied to startups like Citibot, Hyper, NeedConnect, and RezRev in the role of a fractional CTO. In this article, I will introduce you to these responsibilities in the shape of a CTO role with these core responsibilities.

To fully understand the value a CTO can provide for a Startup Company lets dive into the following:

What is CTO? Define the CTO Role
CTO Responsibility 1 — Oversight and Direction (Values and Principles)
CTO Responsibility 2 — Strategy and Vision (Methods and Practices)
CTO Responsibility 3 — Client Empathy and Communication (Transparency)

Chief Technology Officer / VP of Engineering / Lead Engineer are various roles you may encounter in technology-driven companies. The CTO may not be a full-time person in a startup, but a fractional role that may be played by a founder, consultant, or technical lead. Often the responsibilities of a CTO and the value of executing on those responsibilities are not realized early in the company’s growth. Let’s explore the role and responsibilities of a CTO and how a CTO can help set a technical startup company for success.

What is a CTO?

The role of a CTO is to provide and curate the technology strategy and vision of the company’s software tools and technologies. In this role the CTO has the following responsibilities:

To provide oversight and direction for the technology group
To establish and communicate a clear vision of the software architecture and lifecycle of the company’s software products
To meet and work with customers and prospects to help provide clarity and understanding of the technical abilities and capabilities of the company’s software products

Oversight and direction

Software Development is in a constant state of motion that changes over time, based on a continuous feedback loop between the users of the software and the creators of the software. In order for this loop to remain highly functional and productive, it is a good idea to establish a system for checks and balances. Good working systems approach the delivery of the software in a “verify” mode. You may have heard of the phrase “Don’t Trust, Verify”.

Don’t Trust, Verify is a common communication strategy used in the blockchain development world, but it applies with all software code, we have tools and technologies that can quickly verify effective code, via automated testing and scanning tools.

This mode requires that the software is verified by the stakeholders, product team, or quality assurance team. In startups, depending on the size this may be founders, salespeople, or a dedicated product or quality review team. A CTO can help provide a vision and plan for a more efficient and productive review cycle. By establishing agreed-upon values and practices, the verification of delivery can require a high degree of automation to create high-quality deliverables.

The agile manifesto has a great starting point for defining the values of a software development organization:

Individuals over interactions
Working software
Customer collaboration
Responding to change

These four values are great values, and all participants in the software lifecycle will agree to these values. There are some additional values that I have implemented with several startups and consider to be a standard approach, that may require some debate:

Integrity/Commitment to Quality
Automate repeatable operations

Quality first or “Shift Left” and Automate repeatable operations are strategies formed from the DevOps movement and are considered industry standard, proven and documented in the ACCELERATE book

Lean development strategy (Lean development is the process of continuous delivery in small batches, this approach results in shipping production code multiple times a day instead of a weekly or bi-weekly cycle. Reference Continuous Delivery)
Keep it simple (functional thinking — approaching software design and development using simplicity References, Grokking Simplicity and Clean Architecture)

And there may be more to consider, the most important thing is to capture values and define them for your team and make them transparent to the team , each team member should apply your team’s values to every decision being discussed or determined and they can act as guard rails to protect the commitment to the success of the software and the success of the company.

In the future we will expand deeper into the process of establishing core values and explore how to implement some of the core values I have mentioned here.

Other resources to check out: Twelve Factors

Idea to product (like farm to table)

Often times a company is born by an idea and the team creating the idea is not thinking about the far-off future of success, but thinking about the near-term challenge of creating enough value of a product to establish a sale. Early in my career, I was working for a startup company without clearly defined values for how the software developers should make decisions. Every developer and development team had to figure it out on their own with immense pressure to deliver features on fixed delivery dates. As a result, many shortcuts were applied and the software architecture formed organically and not by design, which resulted in complexity and confusion, and a lot of duplication of functionality. The result was a fragile product that contained lots of bugs. These bugs started to reduce the productivity of the teams, which resulted in delays and the inability to deliver features. Over time the creators of the software left and new developers were required to come in and work through the project with little documentation and scarce resources for direction. A common term to describe this situation is technical debt. Technical debt is a term that defines the trade-off between quality, cost, and time.

Technical Debt (UnIntentional) — is best defined in the developer coeffcient report — 17 hours a week or 42% of a developers time is spent on code maintenance.

Without a north star of identified values or principles, the likely hood that your software company can fall victim to un-intentional technical debt is increased greatly, and the sooner a startup company can define and instill values in the development practice the less likely large un-intentional technical debt will happen. The importance of oversight and direction to create accountability and purpose can not be overlooked and is a cornerstone responsibility of a CTO.

Strategy and Vision

Having software developer values or principles is a great start but these guidelines need to translate down to practices and processes that shape your architecture/design and delivery lifecycle. A CTO is responsible for establishing the practices in a collaborative manner with the development team. These practices describe the architecture design patterns your team will implement as well as the approach to software delivery. But first to apply a clear vision of the product and approach. A great way to achieve this is to answer 10 questions called an inception deck. This inception deck asks the team to answer 10 questions about the product and plan that the team will develop. Regardless of approach, your team needs to understand the vision and purpose of the software product, what is the definition of success for the product? What is the technical stack? What is the budget? What is the timeline? What are the roles required to achieve the objective? How much will it cost for a minimum viable product, how much time will it take?

There are a couple of practices that should be heavily considered on all projects and have been scientifically proven to create successful results. They are Continuous Delivery and Clean Architecture. We will explore these practices in the future. This core responsibility is to work with the team to establish the vision and practices to determine success for the software product. The benefit is that there will be strong clarity for each member of the team and as the team grows and things evolve knowledge can be transferred in a clear and transparent flow.

Client empathy and communication

Technology and Software are confusing to a lot of people, from how it works to the complexity and challenges, customers/prospects may not want to get deep into the weeds of the technology, but often they need to be able to understand the value at a high level. The responsibility of the CTO is to be able to explain the technology in an understandable way for stakeholders, leaders, customers, and prospects. This is not as easy as it may seem, the complexity lies in calculating a baseline of understanding by the audience and adjusting the presentation in a way that transfers meaning. You will need to understand the audience’s environment, and deeply understand the problem the software product is looking to solve. Users gauge value on outcomes, and any process needs to have strong visibility of the outcomes it produces. These outcomes can be measurements or emotions, measurements usually form in productivity milestones. A user is able to x process y times faster using this software product. A user enjoys the experience of using this software to accomplish their goals.

Effective communication of complex technology is often led by leveraging empathy, and you can become an effective communicator of how the technology your team is building can support the core needs of the user.

Infuse the communication into the product itself

Once you establish an effective communication strategy, it is worth thinking about embedding this communication into the product itself. The term is called User Experience, and the more the product can communicate the features and functionality in a relatable way to the user the better the experience. In consumer products this can be in the form of creative communication messages or spinners and in more enterprise applications it can be in the form of dashboards and metrics. The more your product can tell a relatable story to your user the better chance for success and separation from the competition.

Summary

What is a CTO? A CTO is a role that provides and curates the strategy and vision of the software tools and technologies your company provides either to internal stakeholders or external customers. In order to fulfill that role the CTO must perform the following responsibilities:

To provide oversight and direction for the company technical group
To establish and communicate a clear vision of the software architecture and life cycle of the companies software products
To meet and work with customers and prospects to help provide clarity and understanding of the technical abilities and capabilities of the companies software products

As a startup founder, you may be thinking about budget, time, and fundraising. You may have hired an agency or freelancer to tackle the technical side and don’t want to worry about the details. There are many stories where that kind of approach has led to failing outright or costly technical debt and very plain cookie-cutter products. No matter what stage of your software product or products, make sure you have a strong strategy and vision in place to empower your technical team to become high-performing and successful. By investing attention to these responsibilities you will find an increased opportunity for success and you will find loyal and happy software team members leveraging all of their creativity and talent toward a common purpose.

Still, have questions?

If you want to learn more about a Startup CTO and how to approach software development as a startup, sign up to get notified when the next chapter of the Startup CTO book will be available.

Glossary

Software Architecture — The design of the software how the code is organized for maintainability, scalability, reliability, the more intentional in the design of software the better. You can also define software architecture in the terms of goals, the goal of software architecture is to create software that empowers high productivity and low cost over time in economies of scale.
Software Lifecycle — Is the description of the process from feature to user, in order for a software feature to get to a user a series of steps or events need to occur, the description of these events organized in a timeline is known as the software development lifecycle. A common high-level lifecycle is the following: Design -> Develop -> Test -> Document -> Deploy
Technical Debt (UnIntentional) — The added maintenance and support required over time that must be completed in order to keep software functional, as a code based grows the debt can build up and productivity slows and the cost of software increases exponentially.

DEV Community: hyper

Introducing Hyper {Nano}: Hyper Cloud in a Bottle ⚡️

What is Hyper Nano

Usage

Workflows

Local Development with Persistent Services

Local Development Using Ephemeral Services

Cloud Development using Ephemeral Services

What Hyper Does

Deploying your Application

Conclusion

Clean Architecture At Hyper ⚡️

Clean Architecture 🧼🛠

Under The Hood 🚘

Benefits

Hyper Clean Architecture Lingua Franca 📚

Hyper Apps 🎮

Hyper Core 🪨

Hyper Ports 🔌

Hyper Adapters 🛠

Hyper Services

Hyper {Nano} 🍷

Conclusion

Acknowledgements

Introducing the Remix Hyper Stack ⚡️+=✨

Remix run (the web 🌎)

Remix Stacks

Introducing the Remix Hyper Stack ⚡️💿

Usage

What’s it doing?

AWS Deployment via Github Actions

Hyper Cloud Integration with hyper-connect

Local Development using hyper nano

Styling, Type Checking, Linting, Testing, Oh My! 🐯

Clean Architecture With Hyper

Conclusion

Using CloudFront to Redirect HTTP -> HTTPS on ApiGateway

The Problem

Set up CloudFront

The important bits

hyper cloud beta is a go!

Okay, it’s confession time 😬.

Features are king 👑.

A DX that rocks 🎸

Support options

Introducing our CTO service

Using Zod to Parse Function Schemas

At hyper

A function schema

Function overloading

Conclusion

hyper Enhancements

March hyper madness

hyper is going BETA! ⚡️️️⚡️

Signup and start innovating today with hyper at https://dashboard.hyper.io

Events in March

March 17 — CHSJS Meetup — Remix and Github Actions

March 23 — Starters Guide to API Development

March 29 — Opensource 101 — hyper OSS

Keep on a lookout for the hyper BETA announcement! 👀

Community

Ship First Development

Why?

Just ship it! 🐿

CI (Github actions)

CD (Github actions)

What if I am adding a new feature to an existing product?

“Ship first, code later”

Not convinced? Trust the science!

BONUS: Pro Tip

⚡️hyper can help you ship! Spin up Data, Cache, Search, Storage, and Queue Services with a single click! Check it out at https://hyper.io

It’s your dime.

Composing hyper data and cache services

3 responsibilities every software startup should address

What is a CTO?

Oversight and direction

Idea to product (like farm to table)

Strategy and Vision

Client empathy and communication

Infuse the communication into the product itself