Service pattern with Hono.js

Hey Im coming from Expressjs backend dev background, and its a bit confusing to me how to implement service pattern with Hono js on top of Cloudflare workers.

What i want to achieve is create a singleton object of thirdparty SDK service in

/services/engine.ts

/services/engine.ts

/services/engine.ts

/services/engine.ts file.

const engine = new Engine(env.ENGINE_API_KEY)

const engine = new Engine(env.ENGINE_API_KEY)

const engine = new Engine(env.ENGINE_API_KEY)

const engine = new Engine(env.ENGINE_API_KEY)

And then inside hono routes use it like this:

const app = new Hono()
app.get(async c => {
const res = await engine.get("foo")
return c.json(res)
})

const app = new Hono()
app.get(async c => {
const res = await engine.get("foo")
return c.json(res)
})

const app = new Hono()
app.get(async c => {
const res = await engine.get("foo")
return c.json(res)
})

const app = new Hono()
app.get(async c => {
const res = await engine.get("foo")
return c.json(res)
})

How can I achieve this? Im getting error inside

engine.ts

engine.ts

engine.ts

engine.ts file, since it cannot access env vars for some reason.

Fflow Hey Im coming from Expressjs backend dev background, and its a bit confusing to ...

IEatBeans•4/26/24, 3:44 PM

I’m not completely understanding, but since this is serverless you cannot have any objects that persist and are shared across workers. You will need to create that engine object each time it’s used. You get the env variable from the request context

IIEatBeans I’m not completely understanding, but since this is serverless you cannot have a...

flowOP•4/26/24, 4:16 PM

oh shoot. so for each route, i need to create it again and again? i have tons of routes...

Fflow oh shoot. so for each route, i need to create it again and again? i have tons of...

IEatBeans•4/26/24, 4:28 PM

I think so. That’s how serverless works. It’s meant for stateless endpoints. What does creating that engine do? Does it need to persist data across multiple calls, or does it make a connection to something?

flowOP•4/26/24, 4:28 PM

yeah, makes connection to a 3rd party service. creates a client. that i need to use inside routes

IEatBeans•4/26/24, 4:29 PM

Yea, you would need to do that each time your worker handles an api call

IEatBeans•4/26/24, 4:29 PM

Is that an expensive process or can it be done many times like this?

IEatBeans•4/26/24, 4:31 PM

I haven’t used durable objects yet and I’m trying to learn about them. They may be able to help you here, since I think they can let you keep objects in memory or something.

IEatBeans•4/26/24, 4:31 PM

Definitely worth taking a look at the docs, but I really do not understand them so

flowOP•4/26/24, 4:34 PM

@IEatBeans thanks

IIEatBeans Is that an expensive process or can it be done many times like this?

flowOP•4/26/24, 4:35 PM

not expensive, just too much boilerplate, considering i have 100s of routes

flowOP•4/26/24, 4:35 PM

@rickyrobinett

Fflow not expensive, just too much boilerplate, considering i have 100s of routes

IEatBeans•4/26/24, 4:36 PM

You could put all the boilerplate and config for the engine in a function, and then just call it in each worker? The code will still run and create the client each time, but you won’t have to see that every time

flowOP•4/26/24, 4:36 PM

yeah, thats what im doing right now, as i couldnt find any better way

IEatBeans•4/26/24, 4:38 PM

It’s hard to migrate from a stateful backend like node or express to serverless, because you really have to think about it differently. It’s much easier to start a project completely serverless (if you can)

rickyrobinett•4/26/24, 4:45 PM

@yusukebe who will have the best insight on doing this with Hono

Fflow Hey Im coming from Expressjs backend dev background, and its a bit confusing to ...

Hello, I’m Allie!•4/26/24, 8:06 PM

Something like this?

import { Hono } from "hono";

// Fake SDK for reference
class SomeSDK {
    constructor(str: string) {

    }
}
const app = new Hono<{ Variables: { SDK: SomeSDK }}>();

app.use((ctx, next) => {
    ctx.set("SDK", new SomeSDK("test"));
    return next();
});

app.get("/", (ctx) => {
    const SDKInstance = ctx.get("SDK");
    // Do something with the SDK
    return new Response();
});

import { Hono } from "hono";

// Fake SDK for reference
class SomeSDK {
    constructor(str: string) {

    }
}
const app = new Hono<{ Variables: { SDK: SomeSDK }}>();

app.use((ctx, next) => {
    ctx.set("SDK", new SomeSDK("test"));
    return next();
});

app.get("/", (ctx) => {
    const SDKInstance = ctx.get("SDK");
    // Do something with the SDK
    return new Response();
});

Hello, I’m Allie!•4/26/24, 8:06 PM

Don't mind the fake SDK there

yusukebe•4/26/24, 8:06 PM

Hi @flow

Indeed, you have to create the engineengine instance per route in the Cloudflare environment. Then, you can use a simple factory method to do it like the following:

import { Hono } from 'hono'

type Env = {
  Bindings: {
    TOKEN: string
  }
  Variables: {
    client: Client
  }
}

export const createAppWithDB = () => {
  const app = new Hono<Env>()
  app.use((c) => {
    const client = initClient(c.env.TOKEN)
    c.set('client', client)
  })
  return app
}

import { Hono } from 'hono'

type Env = {
  Bindings: {
    TOKEN: string
  }
  Variables: {
    client: Client
  }
}

export const createAppWithDB = () => {
  const app = new Hono<Env>()
  app.use((c) => {
    const client = initClient(c.env.TOKEN)
    c.set('client', client)
  })
  return app
}

Then you can use it in your routes:

const app = createAppWithDB()

app.post('/api', (c) => {
  c.var.client.put(/* */)
  // ...
})

const app = createAppWithDB()

app.post('/api', (c) => {
  c.var.client.put(/* */)
  // ...
})

Yyusukebe Hi @flow Indeed, you have to create the `engine` instance per route in the Clo...

Hello, I’m Allie!•4/26/24, 8:07 PM

Jinx!

Yyusukebe Hi @flow Indeed, you have to create the `engine` instance per route in the Clo...

Hello, I’m Allie!•4/26/24, 8:09 PM

Your example isn't per-route though, right? You create the appWithDBappWithDB once, then it works in every route, no?

Hello, I’m Allie!•4/26/24, 8:09 PM

At least for that Worker anyway(and I guess as long as you aren't mixing multiple routers together/using other handlers).

yusukebe•4/26/24, 8:13 PM

As a syntax, one app would cover every route as you imagine. But, actually, the

app

app

will be created per request.

Yyusukebe As a syntax, one app would cover every route as you imagine. But, actually, the ...

Hello, I’m Allie!•4/26/24, 8:14 PM

Oh, like that

Hello, I’m Allie!•4/26/24, 8:14 PM

Wait

Yyusukebe As a syntax, one app would cover every route as you imagine. But, actually, the ...

Hello, I’m Allie!•4/26/24, 8:15 PM

If you aren't calling the new Hono()new Hono() constructor within the

fetch()

fetch()

handler then wouldn't it be able to be reused over multiple requests, asuming they hit the same isolate?

Hello, I’m Allie!•4/26/24, 8:15 PM

It wouldn't reuse the DB client instance, but it would reuse the

app

app

itself

yusukebe•4/26/24, 8:20 PM

Sorry for confusing! new Hono()new Hono() is called once outside the

fetch()

fetch()

as you mentioned. But the middleware that is defined in the factory is called everytime:

app.use((c) => {
  const client = initClient(c.env.TOKEN)
  c.set('client', client)
})

app.use((c) => {
  const client = initClient(c.env.TOKEN)
  c.set('client', client)
})

So you are right!

Service pattern with Hono.js

Similar Threads

Similar Threads

Similar Threads