DEV Community

Cover image for Hyperlambda HTTP Interceptors
Thomas Hansen
Thomas Hansen

Posted on • Originally published at


Hyperlambda HTTP Interceptors

Hyperlambda HTTP interceptors allows you to intercept some HTTP endpoint, and add logic that should be executed before or after your original endpoint. This opens up a lot of interesting use cases, such as for instance.

  • Logging invocations to your original endpoint
  • Attaching additional input data to your original endpoint
  • Return additional data from your endpoint required by the client
  • Changing the data specified by the client before invoking original endpoint
  • Changing authorisation requirements to your original endpoint
  • Add caching to your intercepted endpoint
  • Etc, etc, etc

This becomes almost the HTTP equivalent of AOP software development, which of course implies “Aspect Oriented Programming”, and is a more declarative way of creating software, due to allowing you to attach additional functionality, both before and after the invocation to your original endpoint.

Other use cases might be adding business logic to an HTTP endpoint you cannot add business logic to, such as for instance a GraphQL or PostgREST endpoints, such as those given to you by Hasura or Supabase. Logically this becomes the HTTP and Hyperlambda equivalent of OOP “polymorphism”, since it allows you to take some static thing, and modify how it behaves by “overriding” your original HTTP method. In the video below I am showing you how such interceptors works.

The idea is easily understood; Take some “whatever” HTTP endpoint. Create a new interceptor endpoint that invokes your original endpoint, and attach code to your interceptor endpoint allowing you to do things both before and after your intercepted endpoint is invoked. Then forward the arguments given to your interceptor to your intercepted endpoint, and optionally attach the Authorization header if any before invoking the intercepted endpoint.

Now the only thing you need to do to start using your interceptor, is to change the URL your client is using while invoking the original endpoint. The signature and logic should be the same, assuming your interceptor endpoint can accept any arguments.

You can find the code I am using in the above video below.

.description:Intercepts our foo endpoint

// Endpoint we're intercepting.

 * Retrieving Authorization header to transmit to
 * intercepted endpoint.

 * Lambda object executed as an "intercepted lambda object"
 * before invocation to HTTP endpoint.

 * This is where you would parametrise your above [.before] object
 * with for instance arguments given by the client.

// Evaluating [.before] lambda object.

// Forwarding arguments given to endpoint to intercepted endpoint.

 * Checking if we've got an Authorization HTTP header,
 * at which point we forward it to the original HTTP endpoint.

// Invoking the intercepted HTTP endpoint.

// Sanity checking invocation to endpoint.
      log.error:Something went wrong as we invoked our intercepted HTTP endpoint
      throw:Intercepted endpoint did not return success

 * Lambda object to execute after invocation to
 * intercepted endpoint.

 * This is where you would parametrise your above [.after] object
 * with for instance arguments given by the client.

// Evaluating [.before] lambda object.

// Return result to caller.
Enter fullscreen mode Exit fullscreen mode

auth.ticket.verify:root endpoint was executed
   .:"Hello "
Enter fullscreen mode Exit fullscreen mode

To reproduce what I am doing, signup for a free demo LowCode cloudlet here and watch the above video.

Latest comments (0)

50 CLI Tools You Can't Live Without

The top 50 must-have CLI tools, including some scripts to help you automate the installation and updating of these tools on various systems/distros.