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

As 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!

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

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 Alternative Stack ⚡️💿

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

Out of the box, the Alternative Stack comes with:

• AWS deployment with Architect
• Hyper Cloud integration via
  hyper-connect
• Zero-setup ⚡️ local development using
  hyper nano
• Hyper Vision support, to peer into your hyper services
• GitPod integration for developing in ephermeral cloud environments
• 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 Alternative Stack, simply use the Remix CLI:

npx create-remix --template hyper63/alternative-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 Alternative 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.

Hyper Sevice Vision 🕶

If you'd like to see what is being stored in your hyper services, you can use Hyper Vision to peer into your services.

Hyper Vision is a hosted, read-only, hyper service explorer that you can use to view your services. Just provide Hyper Vision with your application's hyper connection string (process.env.HYPER) and it will introspect your services!

If you're running hyper nano locally, you will need to use a proxy to make it accessible on the internet. ngrok is a great tool for this (though if you develop in ephemeral cloud environments like Gitpod, you get this out of the box 😎).

Gitpod Integration

The Alternative Stack comes with support for cloud based development, using
GitPod. Just initialize the Alternative Stack using the Remix CLI, push to Github, and then open in Gitpod by visiting:

https://gitpod.io/#your-repo-url

You can also use Gitpod's browser extension

This will build a containerized cloud environment, install dependencies, and start up your services for you, a complete sandboxed environment. We use a GitPod .gitpod.yml to set up our Cloud environment and expose your services.

Botch a feature and need to wipe the data? Just open a new Gitpod!

Need to fix a bug? Create an issue and then open the issue in Gitpod!

You no longer have to maintain a local environment. Just spin up a new one every time!

At hyper, we love cloud based development, and trunk based development. We exclusively develop in ephemeral, short-lived, cloud-based environments using GitPod. Any time we start a new feature, or bug fix, we open up a new GitPod instance, which spins up a sandboxed environment.

Because each environment starts from scratch, every GitPod instance exercises our Onboarding flow; we onboard for each new feature! This prevents our onboarding flow from becoming stale, or too cumbersome for new team members or contributors.

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

The Alternative 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.

What's Next

Right now, the Notes application only uses a Hyper Data Service. It is pretty simple and doesn't do much. In future iterations, we may add Hyper Cache Integration, to demonstrate just how simple it easy to compose Hyper services using hyper-connect, while keeping your business logic decoupled from underlying services. Stay tuned!

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 Alternative 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!

Just do it! Automate your CI/CD pipeline, have a single passing test, and have a deployment script that publishes your project to a staging environment, then a production environment.

Another option is to embrace trunk-based development and just have a production environment and deploy your code using feature flags.

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 (Resource not found), 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 (Site Reliability Engineer) 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 ship first?

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 ${{matrix.deno-version}}
        uses: denoland/setup-deno@v1
        with:
          deno-version: ${{matrix.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

Glossary

404 - Resource not found - an http status code that is returned when the server is unable to provide a response for the given request.

OAuth2 - OAuth2 is a standard authentication and authorization specification that enables users to register and log in to applications using secure identity management services, so that they do not have to share/enter identity information in the application unless the choose to.

CI/CD Pipeline - Continuous Integration and Continuous Delivery are quality automation tools, that all applications should to distribute software to users. Continuous Integration is the process of constantly integrating developers code into the main code branch while developing the application. Continuous Delivery is the process of shipping the application when new code is applied, reviewed and approved.

Feature flags - are identifiers that enable/disable features by configuration.

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 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 ⚡️

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:

1. Speed:  Retrieving data from cache is much faster than retrieving data from a database.
2. Conservation:  Retrieving data from a cache takes pressure off your database.
3. 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.

How to future proof your application?

When you start to build an application or product there are many things to think about. What is the purpose of the product, what is its mission, what are the features we need, how will it be used, what is the best technology stack to use, etc? And these are all important questions, gathering requirements, understanding your goals, understanding the skillsets of your team. One major thing to think about is architecture or design, a well-designed application is an application that does not increase cost and decrease productivity over time.

Thought should be given about how to organize your application in such a way, that your team can continue to maintain the application based on economies of scale. This means that as your application scales the productivity should not decrease and cost should not increase in a relative proportion to the scale and complexity of your application. If the development effort continues to be more than the revenue of your product then you will not have a product or business for long.

How are computers architected?

So, how should we think about architecting our product's code? Many architectural patterns are available. As a thought experiment, let's  look at is the architecture of a computer. The design of a computer is a great example of an architecture that has lasted for many years and scales.

If you think about it, the computer is the most useful tool we have, yet without instructions it is a brick that does not do anything. When given peripherals, operating systems, and applications, it can serve many purposes.

Design

A computer is made up of the following components, CPU (central processing unit) this component is responsible for executing instructions, Memory RAM (random access memory) which is responsible for storing data in a temporary state for very fast reads and writes, Storage DISK (solid-state drives) which is responsible for storing data in a permanent location that can be accessed. These three core components make up the modern computer. Then you have a keyboard, monitor, printer, network, etc. These are peripherals that the computer uses to interact with the physical world.

You also have an operating system and applications that can be loaded on the computer. These systems are what transform the computer from a brick to a set of specific machines or applications that actually do something.

Benefits

There are significant benefits to this architecture, it allows for the computer to be used and re-used for many different applications with many different form factors and functions, from watches, phones, virtual reality, productivity, appliances, drones, etc. Using this architecture, we are able to create utility from idea to instruction to apply instantly. How does this relate to software architecture?

Clean Architecture

Clean Architecture is the concept of separating side-effects from business rules or business logic. In computer architecture, we can think of side effects as peripherals and storage systems, and memory and CPU. The operating system as the bridge and applications as the business logic. This separation creates a highly reusable architecture, if the keyboard goes bad, you simply replace the keyboard, or if you want to swap the display for a VR Headset, you change the driver. Since drivers are injected into the computer, the computer does not have to know the implementation details of the VR Headset, it just needs to talk to a driver or specific API surface.

Separation of Services

Leveraging design patterns like dependency injection, closures, and functional programming, you can provide the basic model of a driver or bridge. These patterns allow the business rules/logic to perform functionality in a pure side effect free zone, then when the application sends the result of all of that calculation to the external service, whether that service is the presentation or a given external service, like a database, cache, or storage system. This separation increases the effectiveness of testing and organizes your application into a system of replaceable and upgradable sections. On the interwebs you will see a lot of talk around micro-services versus monolithic architecture, but regardless of the style of your architecture the details are in defined boundaries and separating your logic/rules from your services and side-effects.

Summary

Clean Architecture is not easy, because it requires an extra abstraction at the time of creation may seem to be worth the extra effort. At hyper we have built a suite of services that makes this easier, checkout https://hyper.io for more information.

Unfortunately, the majority of software applications are not designed this way and it is creating huge costs and lots of churn in the industry, we are not building on the shoulders of giants as much as we should be. For reference, check out The Developer Coefficient Report. Over 40% of a developers time is spent dealing with technical debt. This should not be the norm and a significant amount of that technical debt is create by tightly coupled services and the spread of business logic and rules over several layers of an application.  

Over time as the product needs more features and becomes more complex, this separation will become a time-saver, by creating boundaries between your business logic and services.

The proof is right in front of us, while the computer started with the input of punch cards and the output of green bar paper, we were able to evolve the external devices and services without changing the core architecture. And the cost of the computer went down and the productivity of creating the computer went up.

Designing applications to separate presentation and service layers from your business logic will empower your teams to change and modify services without having to change or break the application over time.

Learn more

To learn more about this approach, come chat with us https://hyper.io/slack, check out functional programming and dependency injection. The book Clean Architecture is worth checking out as well.

There are many solutions that support this design, at hyper we use FP and transform async functions that contain side effects into pure Task/Async functions then execute them at the edges of the boundary of the application using lazy execution.

We also use closures for dependency injection so that our business logic inverts the dependency of the service by injecting the pure Task/Async function into the business rule function. As you will learn by reading the above-linked book and articles there are plenty of ways to approach this design.

Check out hyper's collection of services

Regardless of your approach, having clear boundaries between your services and your application is a great way to get started, check hyper a service that gives you this separation by giving you access to core application services using a general-purpose API.

extensibility

hyper is designed with the ability to extend any API without directly affecting the core API design and functionality, the counter module is our first implementation of extending the hyper core API. The counter module leverages the cache API to create a more specialized API that increments, decrements and resets a numeric value in your hyper cache store. This specialization, will enable developers to quickly implement counter functionality in their applications. We plan to continue to provide extensions for the hyper-connect client that compose the primitive services together for more specialized services, while maintaining a general purpose.

hyper-ext-counter

The counter extension gives developers the ability to easily increment and decrement a unique key in the cache store.

Install

npm install hyper-connect hyper-ext-counter

⚡️ create a free hyper account at https://dashboard.hyper.io then get a connection string and create an ENVIRONMENT VARIABLE

HYPER=[CONNECTION STRING]

Initialize

import { connect } from 'hyper-connect'
import { counter } from 'hyper-ext-counter'

const hyper = counter(connect(process.env.HYPER))

Increment

The increment command will read the current value from the cache and increment that value by 1 and store the new value on the cache and return the new value.

const widgetCount = await hyper.ext.counter.inc('widgets')
console.log(widgetCount)

Decrement

The decrement command will read the current value from the cache and decrement the value by 1 and store the new value on the cache return the new value.

const widgetCount = await hyper.ext.counter.dec('widgets')
console.log(widgetCount)

Reset

The reset command will reset the current value in the cache to zero and return zero to the caller.

const widgetCount = await hyper.ext.counter.reset('widgets')
console.log(widgetCount)

Each of these commands take a single argument, this argument is a unique key in the cache store and can be called whatever the developer chooses as long as it is alphanumeric and does not contain any non-alphanumeric characters and starts with an alpha character (a-z).

summary

hyper services are built to extend and provide consistent general value that can be combined in several ways to create re-usable purposeful functionality. These extensions can speed up application development of business rules as well as maintain a clear separation from the business layer and the services layer.

What is DENO?

Deno is a JS runtime open source project that was started by the creator of NodeJS, this runtime implements core principles that the creator felt should have been in NodeJS. What a great opportunity to create a project to right some of your wrongs, but I don't think they were all wrong in the beginning a lot of these improvements were learned in the years that followed. The big takeaway about Deno is, that it enables you to run TypeScript and JavaScript on the server and edge platforms, and many of the standard library modules are Web standard compatible. Standard compatibility means that the APIs are the same specifications created by the W3C standards body. This conviction goes a long way to anti-fragility.

Why is DENO the future?

The conviction to security and Web standards, I believe will slowly evolve into Deno being the clear Javascript runtime in the future, unfortunately, there are a lot of tools and higher abstractions built on top of NodeJS.

It is not always about features when choosing a runtime, sometimes a solution with core mission and sound foundation can be a real game changer.

Web Standards compatibility

Deno focuses on Web Standards compatibility, which means, Deno provides API's using browser standards as much as possible:

• window
• localStorage
• navigation
• crypto
• fetch

Single and Secure Executable

Being able to bundle your application with Deno in a single binary with security flags specified makes distributing your applications extremely flexible for any platform. You can avoid constraints imposed by specific platforms, for example, if deployment platform only supports version x, and you deliver an executable wrapped with your preferred version of Deno, then the platform can't dictate your version.

It's in the box

Deno comes with JSX, TypeScript, REPL, Linting, Formatting, Testing in the box, no need to search for third-party tools and dependencies, these will always be supported.  

deno repl
deno lint
deno fmt
deno test

Decentralized Dependency management

Better dependency management by not having a central point of failure. Deno accomplishes this by using URLs to import modules. A URL can be a reference point to any address on the internet. Using DNS, you can easily have several origins that serve up content. This decentralized model provides redundancy and scalability. URL imports will give your team more confidence that code that is running on their environment is unchanged in production environments, especially with repositories like nest.land.

Nest.Land is a Deno code repository that uses ARWeave Blockchain to store all source code, which means the code is permanent and always available for a minimum of 200 years, but more likely forever. This can give consumers of your modules a great deal of confidence. It is impossible for even the owner of the software to delete from the ARWeave blockchain.

Built to run on the edge

The edge is a server network that distributes executable code to data centers around the world giving everyone with the internet very close proximity to the executable code. This is a perfect solution for web and mobile applications to significantly reduce latency and leverage near-user caching to create incredibly fast experiences for your clients.

Is it right for me?

JavaScript is here to stay and there are plenty of options, NodeJS certainly has the strength of being around in the server space for the longest, but it does not play well on the edge. Runtimes like Cloudflare workers, Deno Deploy, and others are starting to take shape. If your application requirements consist of low latency and stateless performance, give Deno some consideration.

If you start to feel fatigued by dependency nightmares and growing concerned about security threats via man-in-the-middle attacks or the number of open source libraries you have to trust that lack full support capabilities, then I would recommend looking for a Deno for your next project. Why not take it for a spin in this little getting-started tutorial I created [here https://github.com/twilson63/go.hyper.io].

Cons, why should I hold off on Deno?

People do not like change, sometimes change is hard, too entrenched in one technology and the "features" vs the "pain/risk" don't seem to be enough to invest in a migration. But I think the big one is Meta framework support, Deno does not have a good story for the meta frameworks. I think this will change in 2022, look at Remix, SvelteKit, etc.

Summary

DENO at version 1.17 is starting to mature as a JavaScript runtime, the edge computing space is ramping up starting to improve support for many different architectures, SPAs, MPAs, APIs, etc. JavaScript is here to stay, the web is here to stay and I believe DENO is here to stay, so if you bet on JS, consider betting on DENO, for our team, Deno has removed many pain points we experienced from the NodeJS ecosystem and we believe Deno has a very bright future.

BTW! Check out hyper!

⚡️hyper is our backend as a service product that lets you never have to say Kubernetes or AWS Web Services again. Check out our getting started docs at https://docs.hyper.io/cloud and get started building applications that can change the world! If you need help or just want to chat join our community at https://hyper.io/slack and say 👋🏻 Hi!