Forem: Oranda IO

I wanted a simpler way to run commands in a container from code, so l built a small HTTPS alternative to SSH

Oranda IO — Wed, 25 Feb 2026 16:23:38 +0000

Github Repo: https://github.com/Oranda-IO/Shed

I'm building a mobile IDE that needs to remotely execute commands on a Docker container from code.

I made the switch to containerized development, but CDE tools (like Codespaces) don't always provide Docker host access, so Docker Exec is not an option.

SSH is an option.. but managing SSH connections for one-off commands is costly, and I found the developer experience frustrating (e.g. need an SSH client lib, need to manage connection state). It felt especially counter-intuitive in a Lambda.

So (possibly against my better judgment) I built a small Go daemon (~9MB built) I'm calling "SHED" for Secure HTTP Execution Daemon.

You can drop it into a container and run remote kernel commands with stateless HTTPS fetch calls instead of opening a stateful SSH terminal session.

Shed exposes an /exec endpoint over HTTPS with bearer token auth. You POST a JSON command, and you get JSON back with stdout, stderr, and the exit code.

I know I'm reinventing a wheel. SSH is reliable and trustworthy, but it does come with baggage that adds resistance for the modern web.

I did my best to defend it technically in the motivation section here: https://github.com/Oranda-IO/Shed#motivation

This is early and experimental, but I wanted to share in case anyone else has this problem or finds this approach useful.

All feedback is appreciated

Building an AI Voice Assistant in 1 Minute (Command Line)

Oranda IO — Sun, 08 Jun 2025 17:03:44 +0000

Today, I decided to build an AI Voice Assistant.

My goal was to convert my voice to text, pass it through an LLM, and stream it back as audio - all within a few seconds in MacOS Terminal.

I was able to accomplish this quickly with help from GPT-4o.

Setup

We'll build this using 3 OpenAI models:

Whisper: Speech -> Text
GPT: LLM to Process Text
TTS: Text -> Speech

If you don't already have API keys, you can get them here: https://openai.com/api

Before starting, you'll need to export your OpenAI API Key for the commands to work.

export OPENAI_API_KEY=sk-...

If you don't want to use OpenAI models, there are plenty of alternatives (Open-Whisper, LM Studio, Piper, Claude, etc...).

The Minute

Over the next minute, you can paste these commands into your MacOS Terminal:

Record Your Request

sox -d -q test.wav trim 0 3

This will run the SoX tool (Sound eXchange) for recording / processing audio.

The -d option says to use the input device.
The -q option enables quiet mode (to suppress output).
The recording is saved as test.wav.
trim 0 3 tells sox to listen for 3 seconds.

Convert to Text

TRANSCRIPTION=$(curl -s -X POST https://api.openai.com/v1/audio/transcriptions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: multipart/form-data" \
  -F file=@test.wav \
  -F model=whisper-1 \
  | jq -r .text)

This will run OpenAI's Whisper model to convert your audio into text.

Process the Text

REPLY=$(curl -s -X POST https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"model\": \"gpt-3.5-turbo\",
    \"messages\": [
      { \"role\": \"system\", \"content\": \"You are a helpful assistant. Keep responses short.\" },
      { \"role\": \"user\", \"content\": \"$TRANSCRIPTION\" }
    ]
  }" | jq -r .choices[0].message.content)

This uses GPT-3.5 to process your request.

Stream the Reply

curl -s -X POST https://api.openai.com/v1/audio/speech \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"model\": \"tts-1\",
    \"input\": \"$REPLY\",
    \"voice\": \"fable\",
    \"response_format\": \"pcm\",
    \"sample_rate\": 24000
  }" | sox -t raw -b16 -e signed-integer -r24000 -c1 -L - -d

This uses OpenAI's TTS API to convert the output of GPT back into speech. It then streams that to sox in lightweight PCM format.

Done!

You can add all of this to a single shell script to make it easier to run:

assist.sh

#!/bin/bash

# Record WAV — fixed 3 second clip
echo "🎙️  Recording 3 second clip..."
sox -d -q test.wav trim 0 3

# Transcribe with Whisper
echo "📝 Transcribing..."
TRANSCRIPTION=$(curl -s -X POST https://api.openai.com/v1/audio/transcriptions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: multipart/form-data" \
  -F file=@test.wav \
  -F model=whisper-1 \
  | jq -r .text)

# Print what was transcribed
echo "🗣️  You said: \"$TRANSCRIPTION\""

# Chat with GPT
REPLY=$(curl -s -X POST https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"model\": \"gpt-3.5-turbo\",
    \"messages\": [
      { \"role\": \"system\", \"content\": \"You are a helpful assistant. Keep responses short.\" },
      { \"role\": \"user\", \"content\": \"$TRANSCRIPTION\" }
    ]
  }" | jq -r .choices[0].message.content)

# Print reply
echo "🤖 AI reply: \"$REPLY\""

# TTS — stream back and play
echo "🔊 Speaking reply..."
curl -s -X POST https://api.openai.com/v1/audio/speech \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"model\": \"tts-1\",
    \"input\": \"$REPLY\",
    \"voice\": \"fable\",
    \"response_format\": \"pcm\",
    \"sample_rate\": 24000
  }" | sox -t raw -b16 -e signed-integer -r24000 -c1 -L - -d -q

# Final message
echo "✅ Done."

Then, to run it:

chmod +x ./assist.sh
./assist.sh

Conclusion

This is a quick AI assistant you can use by typing "assist" in the command line.

You can extend yours to use "silence" to listen until you stop speaking or listen on a loop for a hot-key, etc.

I've extended mine to run within an express server for better control and both input / output streaming for embedded devices.

Let me know if you have any questions!

Happy Hacking,
Zuluana

Home Screen Shortcuts in React Native (with Expo)

Oranda IO — Thu, 19 Aug 2021 20:25:06 +0000

On March 22, 2017 Apple acquired "Workflow", an app which has since been re-branded and distributed as "Shortcuts".

It's a versatile app, enabling users to string together features from various apps installed on their device.

One such feature is the ability to add Shortcuts to the iOS home-screen.

Developers can access these features programmatically with SiriKit, the SDK used to interact with Siri and Shortcuts.

To use SiriKit in React Native, like most native SDKs, it's common to install an existing library and link native dependencies.

At this time, I've only found one popular library to solve this problem: react-native-siri-shortcut

I found another called react-native-siri-shortcuts, but it has low NPM activity and partial implementation.

Unfortunately, I found three issues with this approach:

Cross-Platform Compatibility

Because SiriKit is an iOS-only feature, you won't be able to save shortcuts to your Android home-screen.

Android has its own solution for this.

Expo Ejection

react-native-siri-shortcut needs to be linked, so, to use it with an Expo app, you'll need to eject.

Luckily, with the new "Bare" Expo workflow, this is easier than ever.

Viral License

react-native-siri-shortcut is licensed under GPL-3.

This is considered a "copyleft" and "viral" license, because all distributed dependent work is (usually) required to be licensed under the same terms:

You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. - GPL v3 Section 5c

I personally avoid dependencies with viral licensing, especially in commercial products.

If you don't know what licenses you're currently using, I suggest the license-checker NPM tool.

I use this command to check for several common "viral" licenses:

license-checker | grep "GPL\|CC\|MTS\|Mechanical" -B1

Tip: Not all CC licenses are copyleft. Look for the "ShareAlike" qualifier.

Homeward

Given these problems, we built a small web app, called Homeward, to save shortcuts to the iOS / Android home-screen.

To use it, re-direct users from your mobile app to the Homeward web app with the required parameters.

The user will then be prompted to save the link to their home-screen:

To simplify this process in React Native / Expo apps, we built Homeward SDK.

Installation

npm i https://github.com/CodalReef/homeward-sdk

NOTE
We plan on publishing to npm shortly.

Create the Link

Next, create the deep link you'd like saved to the user's home-screen:

const link = "myapp://feature1.context1?payload={ ... }"

The exact format of the link will depend on your application.

If you're using Expo, the expo-linking library can help with this:

import * as Linking from 'expo-linking';
const link = Linking.makeUrl();

Build a Web App Manifest

The Homeward SDK directs the user to a web browser where they can save the icon to their home-screen.

The style of both the icon and the web page are controlled by the supplied Web App Manifest JSON.

Web App Manifests are an experimental web standard supported by several major browsers.

Let's make a Web App Manifest to save a Calendar icon to the home-screen:

import { WebAppManifest } from 'homeward';
const manifest: WebAppManifest = {
    name: "Calendar",
    background_color: "#79ccd2",
    theme_color: "#79ccd2",
    "icons": [{
        "src": "https://image.flaticon.com/icons/png/512/2948/2948115.png",
        "sizes": "512x512",
        "type": "image/jpeg"
    }]
}

The name field will be shown below the icon on the home-screen.

The theme_color field is used on Android to style the navigation bar and on iOS to style the default icon.

The background_color field is a transitory color shown while loading the browser.

If you do not specify an icon, a default icon is created.

NOTE
Android has full support for custom icons, but on iOS you must specify a "180x180" icon.

Trigger Save to Home

With the link and the manifest, we can now save the icon to the home-screen:

import { saveToHome } from 'homeward';

saveToHome({ link, manifest });

This immediately redirects the user to the web app with instructions on how to save the shortcut (shown above).

Once saved, the user can tap the home-screen icon to be directed to the cached Homeward PWA. This then immediately opens the provided link.

The PWA stays open in the switcher and can be tapped again to re-open the deep link.

See Pitch / Antipitch and Disclaimer for caveats and further discussion.

Technical Details

I originally considered abstracting over native iOS / Android APIs, but, a solution effectively exists.

On both plaftorms, the built-in web browser has a "Save to Home-Screen" feature.

Apps like "Facebook Groups", "Workflow", and others have taken advantage of this to create ad-hoc home-screen shortcuts.

This approach is documented on StackOverflow:

Redirect from the Native App to a Web App
Check the timestamp of the request. If it's new, prompt the user to save the shortcut to their home-screen. If it's old, re-direct to the deep link.
When the user taps the icon on their home-screen, it will redirect to the same Web URL but with an old timestamp, triggering the deep link.

Conclusion

This solution provides a standardized way of saving a deep link across platforms without abstracting over disparate APIs.

There's a lot of interesting work to be done bridging the gap in SiriKit, Shortcuts, and the associated Android SDKs.

I'm sure usable SDK wrappers will be available soon, but in the meantime, this browser-based solution has worked for me.

I hope you enjoyed this write-up on SiriKit, shortcuts, and my personal struggles.

Cheers,
CodalReef

If you'd like more articles like this, feel free to follow me on: Github, Dev, Twitter, Reddit

The Calendar icon was created by bqlqn and hosted by Flat Icon

The Plugin Market: An Open Letter to Apple

Oranda IO — Sun, 07 Feb 2021 17:29:58 +0000

Hi Apple,

Today I’d like to propose a change to your revenue model:

Build a "Plugin Market" to sell external app extensions (also called Plugins).

Developers should be able to build "Extensible" apps and capitalize by selling "Plugins" (like Wordpress).

These "Plugins" should be able to dynamically (and drastically) change existing functionality.

This has been possible on the web for ages, and I feel it’s time to fully support Plugin Oriented Design (POD) on mobile.

The Problem

Imagine I build an "extensible" native app and sell "Plugins" using an in-app store. I take a cut of the profits, and so do the Plugin developers.

Today, I'd expect this app to be rejected as per sec. 3.3.2 of the Apple Developer Agreement:

Except as set forth in the next paragraph, an Application may not download or install executable code. Interpreted code may be downloaded to an Application but only so long as such code: (a) does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store, (b) does not create a store or storefront for other code or applications, and (c) does not bypass signing, sandbox, or other security features of the OS. - https://developer.apple.com/terms/

I’d certainly be in violation of (b), possibly (a), and perhaps (c), depending on the implementation. Let’s focus on (a) and (b):

I'm sure you (Apple) like getting paid for "Apps" in your store. You take a cut of the sale, and it’s a big part of your revenue. So, if everyone started selling there own "Plugins", you'd lose money.

All those “Plugins” might have otherwise been registered as new “Apps”. Each of which comes with a set of developers paying for Apple Developer accounts. All that revenue would be re-directed to the App / Plugin developers.. which you (understandably) want a cut of.

So... as much as you want to allow innovation and extension on your platform, you're concerned about losing control and money.

Current Solution

I could build a web-app... but I won't get your nice native features.

I understand you're getting pressure from competitors to close the gap between web and native, but that’s a problem for another day.

For now, let's say I really want the newest native features and my app in your "App Store".

We could keep the iOS App clean of any store-like interface and have users buy / register plugins on the web, but I'm not sure you'd like that... I wouldn't be surprised if my app was rejected or removed.

So, how can we make this work for everyone?

Proposed Solution

You already have first-class support for OS extensions, but not iOS App Extensions.

Introduce first-class support for "iOS App Extensions" (Plugins).

Here are the benefits (edited after comments):

Profit: This could be an untapped greenfield opportunity for mobile. Nested Plugins produce a natural, exponential fanout of charge points. Coupled with technical advantage and demand, this should increase revenue.
Momentum: People are doing this anyways (think Expo). It only benefits you to capture this revenue instead of fighting it. It takes time and money to filter apps that break these terms. If you adapt these concepts, those resources can be repurposed.
Employment: Look at all the jobs created from Wordpress alone. Now imagine extensibility as a commonplace feature of mobile / web systems.
Competition: Your competitors are already adapting. Google Play supports dynamic feature delivery. I don't yet believe they support external developer injections or nested features. There's also dynamic module loading on the web. Plus, you're getting pressure from other players (like Google) to continue bridging native features (and vice versa).
Innovation: The current agreement is technically limiting. By removing (or lessening) these restrictions, developers have more freedom to innovate.
Low Cost: It should be possible to leave the existing deployment framework and retrofit support for Plugins. This could be an optional feature devs use. It's a low cost, high reward feature for you.
Clarification: The current agreement leaves room for interpretation. Specifically part (a).
Control: This gives you touch-points to assert control.
Security: By limiting the set of APIs available to Plugins, they have a subset of the security profile of the base application.

Demand for extensive dynamic code interpretation is increasing. It may just be a matter of time before it's more advantageous to accept it than to fight it.

Implementation

Registration

Allow developers to register their Apps / Plugins as “Extensible”. Plugins should be able to extend both Apps and other Plugins. Have developers express which Apps / Plugins their Plugins can be installed into.

Require a Developer Account to register a Plugin, and take a cut of the profits from the sale (whether it be one-time, subscription, etc…)

Instead of "Plugins" you may also consider charging by "Feature", "Module", "Element", etc...

Start by getting the registration / billing in place, and then work on the technical tools.

Technical Tools

Start by helping with hosting and code-signing. Eventually, consider helpful tools to manage dependencies, check API impedance, custom rules, etc...

While you may eventually build a UI in the App Store (including nested Plugins), allow developers to build custom store-fronts conforming to your design standards.

Loosen Restrictions

Now that you're capturing the lost revenue, allow Plugins which are inconsistent with the original App intent. If classification is the issue, you can derive the classification data from the fanout of statically assigned Plugins. Consider support for dynamic assignment in the future.

Conclusion

The details can be sorted, but the idea is to convert a gray area of the License Agreement to a greenfield opportunity.

There are other issues to consider, like security, but given the language of the agreement, I tend to believe revenue loss is the biggest hindrance.

Thanks for reading, and I hope you'll re-consider first-class support for Extensible iOS Apps.

Also, thanks for building these cute metal boxes with all these bright little lights. They're pretty useful.

Cheers,
CR

I'm building a Plugin Market for the Web and React Native. For more, follow me on Github, Dev, Twitter, Reddit

Acknowledgments

Thanks to the Reddit users who responded to my recent post. This feedback helped identify these License Agreement concerns.

I'm just a random guy with some thoughts, and nothing in this post is meant to be construed as legal advice.

Plugin Oriented Design with Halia

Oranda IO — Sun, 31 Jan 2021 19:34:36 +0000

Building apps with Plugin Oriented Design (POD) has a lot of advantages (discussed in my recent blog post)

Today, I'd like to introduce "Halia", an extensible TS / JS Dependency Injection Framework built to manage "Plugins" in your apps.

Building a Pluggable app has its advantages, but it can be challenging to stay organized when you're dynamically importing code that changes other code.

For example, if you build a feature that depends upon another feature (or multiple), you'd likely end up "splitting and spreading" the feature across the app.

Halia can help with this:

Halia - Extensible TS / JS Dependency Injection Framework

With Halia, your app's core is packaged as a Plugin, and features are packaged as Plugins. Each Plugin can then be extended by other Plugins.

We’re also building tools to dynamically load plugins from a URL, activate plugins dynamically, user level managment (like a plugin store), cross-stack and cross-eco plugins, and contracts (for building re-usable plugins).

Halia is responsible for managing this tree of plugins. Let's see how it works with an example:

Example

You have a duck that everyone loves:

//  duck-app.ts
export const getDuck = () => {
  return "Quack";
}

Everyone except Paul. Paul wants a special 🦄 Disco Duck 🦄, so you make an update:

//  duck-app.ts
import { Paul } from 'client-list';
import { config } from 'config';
export const getDuck = () => {
  if (params.client === Paul) {
    return "Michael Quackson";
  }
  return "Quack";
}

While the code works for Paul, it's become more complex, harder to read, and coupled with the "client" concept.

Instead, we can use a Halia Plugin to encapsulate and inject this feature:

//  duck-app-plugin.ts
import * as DuckApp from './duck-app';
export const DuckAppPlugin: HaliaPlugin = {
  id: "duckApp",
  name: "Duck App Plugin",
  install: () => ({
    setGetDuck: (getDuck) => DuckApp.getDuck = getDuck
  })
}

//  disco-duck-plugin.ts
import { Paul } from 'client-list';
import * as config from 'config';
export const DiscoDuckPlugin: HaliaPlugin = {
  id: "discoDuck",
  name: "Disco Duck Plugin",
  dependencies: [DuckAppPlugin.id],
  install: ({ duckApp }) => {
    if (config.client === Paul) {
      duckApp.setGetDuck (() => "Michael Quackson")
    }
  }
}

Then we can build the stack and invoke the code:

//  main.ts
import { HaliaStack } from Halia;
import { DuckApp } from './DuckApp';
import { DiscoFeature } from './DiscoFeature';

const buildApp = async () => {

  //  Initialize the Stack
  const appStack = new HaliaStack();

  //  Register Plugins
  appStack.register(DuckApp);
  appStack.register(DiscoFeature);

  //  Build the Stack
  await appStack.build();

  //  Call the Method
  const duckApp = appStack.getExports(DuckApp.id);
  duckApp.logNoise();
}

buildApp();

With this, the original code is left in-tact and de-coupled.

If Paul longer wants the 🦄 Disco Duck 🦄 we just don't register the Plugin. If he needs an additional change, we have a namespace dedicated to his unique needs.

This is a simple example that can be solved in other ways. However, it demonstrates the general idea, and as features become more complex, we've found this pattern helps to keep things organized.

Conclusion

For more info on Dependency Injection Frameworks (like Angular, Nest, and Halia) see our article:

Dependency Injection with Doug the Goldfish 🐠

I hope you enjoy the package and the associated concepts.

Cheers,
CR

For more articles like this, follow me on: Github, Dev, Twitter, Reddit

Build Extensible Apps with Lenny the Duck 🦆

Oranda IO — Sun, 31 Jan 2021 18:10:19 +0000

Unlike many apps, "Extensible" apps can be extended with self-contained pockets of code called "Plugins".

These apps tend to be modular by design, resulting in manageable, loosely-coupled code.

Today, let's learn how to build extensible apps.

Introduction

Every day, you probably use extensible apps:

Your favorite development tools are probably extensible too:

The problem is, there are too many problems.

With Plugins, you don’t need to solve every problem. Users solve their own problems.

With plugins, feature logic can be centralized instead of spread throughout the codebase. This leads to modularized, loosely-coupled features.

When you build your entire app as a “Tree of Plugins”, these benefits extend to the whole codebase. Ultimately, this benefits you, your team, and your customers.

Building Non-Extensible Systems

Imagine you're a duck named Lenny (🦆), and you love to quack. Most of your friends love to quack too, except Lonnie (🍗).

Anyways... you live in a park and people like to throw food at you (despite the litany of signs indicating not to).

One day, you notice you’ve become quite plump. So, you build a web service to track your consumption:

//  food-service.ts

//  Log of Foods Eaten
//  Example:  [{ name: "lenny", food: "waffle", calories: 5 }]
const foods = [];

//  Function to Log a Food (by Duck Name)
const logFood = (name: string, food: string, calories: number, ...props: any) => {
  foods.push({ name, food, calories, ...props });
}

//  Function to Get Log (by Duck Name)
const getLog = (name: string) => {
  return foods.filter(food => food.name === name);
} 

//  JS Module Exports
export logFood, getLog;

Congratulations, tracking has given you the bill-power to lose 3 ounces!

That's great, but your friend Mack (🐦) has no self control. So, he asks you to scare the humans with a horn once he exceeds his 300 calorie daily limit.

Then your friend Jack (🐤) asks if you can also track protein. He’s already fit, so he’s more concerned with staying jacked than losing fat.

Before you know it, Abby (🦀), Tabby(🐢) and Doug (🐠) are asking for features. Even Larry (🐊) wants something, and you're pretty sure he's the one who ate Lonnie (🍗)!

The whole pond descends upon you, the backlog is full, and now the app is so complex that you're losing customers talking about "the good old days" when things were simple.

Then you wake up... "Are you ok honey?", asks your wife Clara (🦆) as she waddles in with a basket of breadcrumbs.

"I had the nightmare again...", you reply in an anxious tone.

“Silly goose”, Clara chuckles and says:

The pain of feature creep, non-modular code, and tightly coupled functionality can be largely avoided with plugin-oriented design (POD).

Looking up to meet her gaze you say, "You're right dear. let's recap the basics of plugin oriented design so we never forget."

With a warm embrace Clara replies, "I can't think of a better way to spend our Sunday =)"

Building Extensible Systems

A fundamental characteristic of plugin-oriented design is the ability to alter functionality without altering the existing system definition.

So, to make your Food Service "extensible", you decide to do two things:

Register: Allow users to register custom functions.
Invoke: Run the registered functions when a condition is met.

With this, other developers can “inject” functionality into your app.

These registration points are called Hooks.

We see this pattern everywhere:

Wordpress: "Filters" and "Actions (gasp it's just another Filter)"
Babel: Visitor Plugin Function
Webpack: Tapable

I recommend taking a look at tapable. This is the small module underlying every Webpack Plugin.

Here's the Food Service code updated to use Hooks:

//  extensible-food-service.ts

//
//  Define the Hook
//

type LogFoodFunction = (name: string, food: string, calories: string, ...props: any) => void;

//  List of Functions Registered to this "Hook"
const functions: LogFoodFunction[] = [];

//  Add a Function to the Hook
const addFunction = (func: LogFoodFunction) => {
  functions.push(func);
}

//
//  Build the Food Service
//

//  List of Foods Eaten
//  Example:  [{ name: "lenny", food: "bread", calories: 5 }]
const foods = [];

//  Add the Core Function
addFunction((name, food, calories) => {
  foods.push({ name, food, calories });
});

//  Function to Log a Food (by Duck Name)
const logFood = (name: string, food: string, calories: number, ...props: any) => {
  //  Trigger Functions in the Register
  functions.forEach(func => func(name, food, calories, ...props));
}

//  Function to Get Log (by Duck Name)
const getLog = (name: string) => {
  return foods.filter(food => food.name === name);
} 

//  JS Module Exports
export logFood, getLog, addFunction;

Now, anyone can extend this JS Module by calling addFunction.

Here’s Macks’s (🐦) Plugin to scare humans with a horn:

//  macks-plugin.ts
import * as FoodService from "extensible-food-service";
import * as Horn from 'horn-service';

//  Set Calorie Limit
const calorieLimit = 300;

FoodService.addFunction(() => {

  //  Get Total Calories
  const eatenCalories = FoodService.getLog("mack").reduce((prev, entry) => prev + entry.calories);

  //  Check Condition
  if (eatenCalories > calorieLimit) { Horn.blow() }
})

Now, all you need to do is import Mack's Plugin, and the feature will be integrated.

However, building a system with “Hooks” is just one way to implement “POD” principles.

Hook Alternatives

Hooks (and their variants) are fairly common. Probably because they're simple:

Build a way to register code, and invoke the code when a condition is met.

But, they're not the only way to build an extensible system.

Primitive Domain

In the code above, we register "primitive" code with a Hook. Fundamentally, primitive code is just an encoding of intent. In this case, it's then decoded by the JS runtime.

Application Domain

However, intent can be encoded in other ways too. For example, you can build your own language. It sounds complicated, but it's exactly what you do when you define classes or build an API. Your application logic is then responsible for managing and decoding entities in this domain.

External Domain

In some cases, you may want to externalize the entire process. For example, you can trigger external code with Webhooks, Websockets, and tools like IFTTT, Zapier, and Shortcuts.

Regardless of the implementation, it helps to remember this golden principle:

Keep it simple.

a.k.a. don't do more than reasonably necessary

This applies to you, your team, your functions, modules, app, and everything you touch. If something is too complex, try to break it up. Refactor, rework, and fundamentalize as necessary.

Plugin-Oriented Design (POD) can help achieve this goal, especially as logic becomes complex. By modeling each feature as a Plugin, complexity only bubbles up when necessary, and in a predictable, modularized container.

Hook Concerns

There are several concerns with the hook implementation we built above:

Centrality: You're responsible for loading Plugins.
Trust: You're responsible for auditing code.
Conflicts: Users may disagree on the feature set.
Dependencies: No management system for complex dependencies.
More: A whole lot more.

These concerns can be addressed using various strategies:

External Plugins: Dynamically inject code from an external resource (like a URL) at runtime.
Contextual Activation: Dynamically activate features based on the current context (logged in users, application state, etc...)
Plugin Managers: Coordinates feature extension, even in a complex network of dependencies.
More: A whole lot more.

I hope to cover "External Plugins", "Contextual Activation", and related topics in future articles.

To learn about "Plugin Managers" and how our new tool "Halia" can help you build Extensible JS / TS systems, see our blog post:

Plugin Oriented Design with Halia

Conclusion

The concepts discussed here are just the start. We've opened a can of worms, but for now, let's put the worms back in the can. We've already overfed the park animals.

Speaking of which, we found Lonnie (🦆)! It turns out she was just across the pond learning plugin-oriented architecture (like all good ducks do).

In closing, there are plenty of ways to cook your goose, so you might as well be a duck (🦆).

Cheers,
CR

For more articles like this, follow me on: Github, Dev, Twitter, Reddit

Dependency Injection with Doug the Goldfish 🐠

Oranda IO — Tue, 26 Jan 2021 23:14:14 +0000

There are lots of great strategies to keep code manageable and extensible. Today, let's learn about "Dependency Injection".

Dependency Injection

Imagine you're a goldfish named Doug (🐠), and you love bubbles. So much so, that you bought a Bubble Machine with a programmable Typescript SDK.

You write a program to make bubbles when you wake up:

import { Bubbler } from 'bubbler';
const initBubbler = () => {

  //  Instantiate
  const bubbler = new Bubbler({ id: "dougs-bubbler" });

  //  Start the Bubbler
  bubbler.bubble({ startTime: "7:00AM", endTime: "8:00AM" })
}
initBubbler();

Great, now you awaken to fresh, well-oxygenated water 💦

You tell your friend Mary (🐟), and she's so excited, she buys a bubbler too.

You update the code to initialize both bubblers:

import { Bubbler } from 'bubbler';

const initDougsBubbler = () => {
  const bubbler = new Bubbler({ id: "dougs-bubbler" });
  bubbler.bubble({ startTime: "7:00AM", endTime: "8:00AM" })
}

const initMarysBubbler = () => {
  const bubbler = new Bubbler({ id: "marys-bubbler" });
  bubbler.bubble({ startTime: "7:00AM", endTime: "8:00AM" })
}

initDougsBubbler();
initMarysBubbler();

It works, but there's something... fishy... going on here...

Instead of duplicating the initBubbler function, you could have "hoisted" the instantiation step outside the function:

import { Bubbler } from 'bubbler';

const dougsBubbler = new Bubbler({ id: "dougs-bubbler" });
const marysBubbler = new Bubbler({ id: "marys-bubbler" });

const initBubbler = (bubbler) => { 
  bubbler.bubble({ startTime: "7:00AM", endTime: "8:00AM" })
}

initBubbler(dougsBubbler);
initBubbler(marysBubbler);

Now, we only need the single initBubbler function, even if your friends Larry (🐙) and Barry (🐡) decide to buy Bubblers too.

The initBubbler function is no longer responsible for constructing a bubbler instance. Instead, it's injected into the function from the outer scope. This pattern is called "Dependency Injection" (DI).

Dependency Injection is a great way to keep your functions simple, modular, and re-usable by delegating responsibility to the caller.

Inversion of Control

Further, because the "caller" is now responsible for initializing the Bubbler (instead of the initBubbler function), we say control has been "inverted". Dependency Injection is a means by which to achieve "Inversion of Control" (IoC).

IoC Container

The outer scope, responsible for instantiating the bubbler dependency, is called the "Inversion of Control Container" (IoC Container).

DI Frameworks

You can use a "DI Framework" to make things even easier. Instead of manually initializing the dependencies, a DI Framework acts as the IoC Container and does the work for you.

You just tell the framework which dependencies your function needs, and once they're initialized, the framework automatically invokes your function.

Angular and Nest are two popular tools that include DI Frameworks. Both of these helped in the writing of this article and shaping my own understanding of DI:

Angular: https://angular.io/guide/providers
Nest: https://docs.nestjs.com/fundamentals/custom-providers

Plugins

DI Frameworks are great for keeping code organized. However, I like to go one step further and build a module for every "Feature" in my app.

When the DI Framework initializes the "Feature Module", it "installs" itself by invoking dependency methods. It then exports its own API for dependencies to install themselves.

We call call these modules "Plugins", because they inject functionality back into the app.

By building apps as a "Tree of Plugins", feature code is centralized instead of being spread throughout the app.

This makes it easy to mix and match features, build new features, and even open your app for extension by external developers (like Wordpress does).

To learn more about building apps as a tree of Plugins, check out my new package "Halia":

Halia - Extensible TS / JS Dependency Injection Framework

Halia is a simple, lightweight, and extensible DI Framework. It's not tied to a particular backend / frontend technology, and you can customize the framework by installing "Plugins".

Conclusion

We hope your time spent as Doug has helped you see value in the DI Pattern and DI Frameworks.

If you'd like, you can stop imagining you're a goldfish and resume normal human function.