yasserf

I have been working on pikku.dev, a typescript server library / framework that does most things and deploys in most places [1]

Been a project I was using for a few years now. Initially started off as express middleware with a few tools chained together to automate as much typing as possible which can run anywhere (similar to hono).

Around a year ago I decided to change the approach and write a layer to statically analyze the typescript code ontop of tsc and pull out as much meta as possible.

After that I went a little crazy and ultimately added wires to everything. HTTP, Websockets, Queues, Scheduled Jobs, etc. All totally agnostic (the core runtime is pretty tiny). So can run scheduled tasks on lambas / a cron job / pgadmin, deploy websockets serverless or local, run your queues again most queue provides, etc.

I then saw Vercels workflow runner and figured, well, I could try do better . Looked at other libraries out there and decided to include addons, which are pikku typescript packages that declare functions which can be automatically imported into your app and are responsible for their own service initialization. If your used to writing n8n plugins be awesome to hear what you think about this approach!

That sort of required me to create a console to view workflows (otherwise what's the point right?). And since everything is statically extracted during runtime we can pretty much just visualise the entire codebase. So all your functions, what permissions each have, etc etc. The idea behind the console is that it doesn't have an actual backend. You install an addon into your own codebase, permission it as you see fit and you point the console towards it. That means you have a unified permissions/auth system as everything else.

Figured the last part was creating an AI agent to wrap it all together. Which is almost there. Subagent flows, tools, approvals, ai middleware that can turn input and output into voices, its does a bit.

Ultimately the idea is you write a function once, and it can be consumed as an AI tool, a workflow step, by a http route, a cron job, a gateway (like whatsapp) (I liked openclaw approach so figured.. why not ).

A function is the source of truth, so is permissioned / authenticated. Been alot of heavy development since I'm building a 'BuildYourAgent' portal ontop that pretty much takes an openapi doc and turns it into an MCP server / hooks it up to an agent / gives you a CLI around it so it can integrate with all the crazy wild west approaches, while you know, still allowing us to maintain sanity and build servers that don't hallucinate and burn forests down.

Curious on thoughts! Bit of a rambling explanation. I hope the website does a better job! Lots of content helped with AI (I prefer speaking tech, but doesn't always transition well).

Also, looking for a potential cofounder to help balance that out! If your interested in potentially working together / adopting pikku feel free to leave a comment / ping me an email

[1] https://pikku.dev/

Pikku is a TypeScript backend framework that lets you write your backend as plain functions, similar to Lambdas, but without any platform tie-in.

Each function can be wired to whatever transport you want:

  - HTTP / WebSockets / SSE

  - Queues (SQS, RabbitMQ, Postgres jobs, etc.)

  - CLI commands, schedulers, or AI MCP agents

Pikku builds a full type contract between your backend and frontend. It doesn’t ship a runtime SDK just typed native fetch calls / websockets / queue clients so your frontend gets zero added bundle size and fully inferred request/response types out of the box.

The framework is tree-shaken at the function level, so you can deploy only what’s needed (plus its dependencies) as a binary, Docker image, or serverless functions. Switch cloud providers or queue systems freely, no rewrites, just switch runtimes.

Auth, permissions, and middleware live directly at the function level, giving you a single consistent entrypoint across all transports.

It also supports Next.js-style "use server" patterns — you can call backend functions directly in SSR while keeping them accessible over HTTP for external use.

There’s even a CLI mode where you can run commands on a server and stream live output to a tiny local client — same code, same types.

I'm about to release the next version that allow supports workflows similar to those just released by Vercel or by Cloudflare Workflows.

Would love to hear your thoughts! There's even more on the roadmap :D

Thank you for the feedback!

I agree framing pikku has been a pretty hard challenge for me.

It supports different runtimes in the sense of deno / bun or custom nodeJS runtimes in the cloud, but ultimately relies purely on typescript / a JavaScript compatible backend.

It’s less of a webserver and more of a lightweight framework though, since it also supports CLIs or Frontend SDKs / isn’t tied to running an actual server.

I have been working on https://pikku.dev

The goal is to provide a fully typed nodeJS framework that allows you to write a typescript function once and then decide whether to wire it up to http, websocket, queues, scheduled tasks, mcp server, cli and other interactions.

You can switch between serverless and server deployments without any refactoring / completely agnostic to whatever platform your running it on

It also provides services, permissions, auth, eventhub, advanced tree shaking, middleware, schema generation and validation and more

The way it works is by scanning your project via the typescript compiler and generating a bootstrap file that imports everything you need (hence tree shaking), and allows you to filter down your backend to only the endpoints needed (great to pluck out individual entry points for serverless). It also generates types fetch, rpc, websocket and queue client files. Types is pretty much most of what pikku is about.

Think honoJS and nestJS sort of combined together and also decided to support most server standards / not just http.

Website needs love, currently working on a release to support CLI support and full tree shaking.

I agree it’s pretty frustrating, but I do really like the SSR capabilities

I’m divide my frontend and backend via pikku, that way I can continue using normal server side functions but optionally spin up a seperate api service if needed.

Haven’t really tested it on vercel as much, but it ignores middleware on the nextJS side unless it’s for frontend code.

https://pikku.dev/docs/runtimes/nextjs-app

Disclaimer: I’m the pikku core developer

Most backends still treat HTTP as the “first-class citizen,” and everything else (WebSockets, queues, cron, mcp) feels bolted on with custom wiring and their own typings if any.

Pikku aims to take a different approach:

- Define a function once → invoke it from HTTP, WebSockets, queues, cron, or even Postgres.

- Deployment is your choice: single process, containers, serverless, or workers. Pick your own queue library, deploy scheduled tasks via lambda, the choice is endless.

- Fully typed, end-to-end → auto-generated clients are tiny, just thin wrappers over existing libs.

Built-in support for services, middleware, permissions, and auth.

Docs & examples: pikku.dev

I would recommend looking into being able to recognise ‘thought viruses’

A book that really helped me was ‘Stop overthinking’ by Nick Trenton. I still have those thoughts, Anxiety isn’t the easiest thing to get rid of.

Find what it is that you enjoy, build habits (tiny habits / atomic habits are great references) and you might find that just moving a tiny bit in the direction that makes you happy might compound over time.

Success isn’t always about careers or large paydays. Your health, relationships, hobbies, identity and sanity play a big part of that as well.

I have friends who moved to other countries and restarted their lives at the age of 35/40, and I met people in their 70s who done the same.

Good luck!

SEEKING WORK | Berlin (CET/CEST) | Remote | Senior Full-Stack & Cloud Specialist

I’m a senior developer and infrastructure consultant with 15+ years of experience

— available for part-time work (24h/week). I help teams move fast without breaking things, bringing deep infrastructure expertise alongside strong full-stack execution.

What I Do Best:

• Cloud & Infrastructure: AWS (primary), Azure, GCP, Terraform, Kubernetes, Serverless, CI/CD (GitHub Actions, etc.)

• DevOps Workflows: Monitoring, cost reduction, zero-downtime deploys, secure secrets management, staging/preview environments

• Full-Stack Development: Node.js, React, React Native, Next.js, Tailwind, Postgres, MongoDB

• Delivery-First Mindset: Recently helped a client setup up CI/CD, staging, and production environments via Kubernetes — from scratch to deploy — in just 3 weeks part-time

What I’m Looking For:

Teams with meaningful technical challenges — ideally past the MVP/PoC stage and ready to do things properly. I’m most effective where there’s a need to scale infra, clean up dev workflows, or modernize architecture.

Engagement Style:

• Part-time (24h/week)

• Open to short/middle term high-impact contracts, retainers, or embedded support

• Happy to mentor as part of the engagement

Projects: • deepstream.io – Real-time messaging infrastructure (co-founder)

• pikku.dev – Open-source framework for building transport-agnostic TypeScript APIs

Let’s Talk:

• GitHub: github.com/yasserf

• LinkedIn: linkedin.com/in/yasserfadl

• Email: yasser.fadl [at] vlandor.com

SEEKING WORK | Berlin (CET/CEST) | Remote | Senior Full-Stack & Cloud Specialist | Part-Time (24h/week)

I’m a senior developer and infrastructure consultant with 15+ years of experience — available for part-time work (24h/week). I help teams move fast without breaking things, bringing deep infrastructure expertise alongside strong full-stack execution.

What I Do Best:

• Cloud & Infrastructure: AWS (primary), Azure, GCP, Terraform, Kubernetes, Serverless, CI/CD (GitHub Actions, etc.)

• DevOps Workflows: Monitoring, cost reduction, zero-downtime deploys, secure secrets management, staging/preview environments

• Full-Stack Development: Node.js, React, React Native, Next.js, Tailwind, Postgres, MongoDB

• Delivery-First Mindset: Recently helped a client setup up CI/CD, staging, and production environments via Kubernetes and compliant — from scratch to deploy — in just 3 weeks part-time

What I’m Looking For:

Teams with meaningful technical challenges — ideally past the MVP/PoC stage and ready to do things properly. I’m most effective where there’s a need to scale infra, clean up dev workflows, or modernize architecture.

Engagement Style:

• Part-time (24h/week)

• Open to short/middle term high-impact contracts, retainers, or embedded support

• Happy to mentor as part of the engagement

Projects:

• deepstream.io – Real-time messaging infrastructure (co-founder)

• pikku.dev – Open-source framework for building transport-agnostic TypeScript APIs

Let’s Talk:

• GitHub: github.com/yasserf

• LinkedIn: linkedin.com/in/yasserfadl

• Email: yasser.fadl [at] vlandor.com

I’m working on https://pikku.dev

It’s a TypeScript web framework that’s runtime agnostic, so it can work on serverless and servers (similar to Hono).

What’s different is that the focus is primarily just on TypeScript. There’s a CLI tool that inspects all the project code and generates loads of metadata. This can include:

• services used

• all the HTTP routes, inputs and outputs

• OpenAPI documentation

• schemas to validate against

• typed fetch client

• typed WebSocket client (and more)

The design decision was also to make it follow a function-based approach, which means your product code is just functions (that get given all the services required). And you have controllers that wire them up to different transport protocols.

This allows interesting design concepts, like writing WebSocket code via serverless format, while allowing it to be deployed via a single process or distributed/serverless. Or progressive enhancement, allowing backend functions to work as HTTP, but also work via Server-Sent Events if a stream is provided.

It also allows functions to be called directly from Next.js and full-stack development frameworks without needing to run on a separate server or use their API endpoints (not a huge advocate, but it helps a lot with SSR). Gave a talk about that last week at the Node.js meetup in Berlin.

It’s still not 1.0 and there are breaking changes while I include more use cases.

Upcoming changes:

• use Request and Response objects to make it truly runtime agnostic (currently each adapter has its own thin layer, which tbf is still needed by many that don’t adopt the web spec)

• smarter code splitting (this will reduce bundle size by tree-shaking anything not needed on a per-function basis)

• queues (one more form of transport)

Check it out, would love feedback!

SEEKING WORK | Berlin (CET/CEST) | Remote | Part-time | Senior Full-Stack Developer and Cloud Specialist with 14+ years of experience seeking part-time work.

Experience Highlights:

- Fintech: 5 years with banks and hedge funds - Co-founder: deepstreamHub.com

- AI Projects: Tazamun on mindfulness and mental health

- Infrastructure Contracting: Security audits, cost optimization, minimizing downtime, feature environments / QA tooling, monitoring, CI workflows

Skills & Expertise:

- Infrastructure: AWS, Azure, Serverless, Terraform, Docker, CI/CD, logging, alerting systems

- Optimizing infrastructure and development workflows

- Reducing cloud costs

- Full-Stack Development: Postgres, MongoDB, React, React Native, Next.js, Tailwind, Node.js

Seeking a part-time role with a motivated team. If you need senior expertise in infrastructure optimization or full-stack development without the commitment of a full-time hire, let's connect!

Personal Projects:

- deepstream.io - vramework.dev

Contact:

- linkedin.com/in/yasserfadl - yasser.fadl [at] vlandor.com - github.com/yasserf

  const onConnect: ChannelConnection<'hello!'> = async (services, channel) => {
    // On connection (like onOpen)
    channel.send('hello') // This is checked against the input type
  }

  const onDisconnect: ChannelDisconnection = async (services, channel) => {
    // On close
    // This can't send anything since channel closed
  }

  const onMessage: ChannelMessage<'hello!' | { name: string }, 'hey'> = async (services, channel) => {
    channel.send('hey')
  }

  export const subscribeToLikes: ChannelMessage<
    { talkId: string; action: 'subscribeToLikes' },
    { action: string; likes: number }
  > = async (services, channel, { action, talkId }) => {
    const channelName = services.talks.getChannelName(talkId)
    // This is a service that implements a pubsub/eventhub interface
    await services.eventHub.subscribe(channelName, channel.channelId)
    // we return the action since the frontend can use it to route to specific listeners as well (this could be absorbed by vrameworks runtime in future)
    return { action, likes: await services.talks.getLikes(talkId) }
  }

  addChannel({
    name: 'talks',
    route: '/',
    auth: true,
    onConnect,
    onDisconnect,
    // Default message handler
    onMessage,
    // This will route the message to the correct function if a property action exists with the value subscribeToLikes (or otherwise)
    onMessageRoute: {
      action: {
        subscribeToLikes: {
          func: subscribeToLikes,
          permissions: {
            isTalkMember: [isTalkMember, isNotPresenter],
            isAdmin
          },
        },
      },
    },
  })

A code example.

Worth noting you can share functions across websockets as well, which allows you to compose logic across different ones if needed

I have been working on an idea/Node.js library called vramework.dev recently, and a big part of it focuses on addressing the main complexities mentioned below.

For a bit of background, in order to tackle scalability, the initial approach was to explore serverless architecture. While there are both advantages and disadvantages to serverless, a notable issue with WebSockets on AWS* is that every time a message is received, it invokes a function. Similarly, sending a message to a WebSocket requires invoking an HTTP call to their gateway with the websocket / channel id.

The upside of this approach is that you get out-of-the-box scalability by dividing your code into functions and building things in a distributed fashion. The downside is latency, due to all the extra network hops.

This is where vramework comes in. It allows you to define a few functions (e.g., onConnect, onDisconnect, onCertainMessage) and provides the flexibility to run them locally using libraries like uws, ws, or socket.io, or deploy them in the cloud via AWS or Cloudflare (currently supported).

When running locally, the event bus operates locally as well, eliminating latency issues. If you apply the same framework to serverless, latency increases, but you gain scalability for free.

Additionally, vramework provides the following features:

- Standard Tooling

Each message is validated against its typescript signature at runtime. Any errors are caught and sent to the client. (Note: The error-handling mechanism has not yet been given much thought into as an API). Rate limiting is also incorporated as part of the permissioning system (each message can have permissions checked, one of them could rate limiting)

- Per-Message Authentication

It guards against abuse by ensuring that each message is valid for the user before processing it. For example, you can configure the framework to allow unauthenticated messages for certain actions like authentication or ping/pong, while requiring authentication for others.

- User Sessions

Another key feature is the ability to associate each message with a user session. This is essential not only for authentication but also for the actual functionality of the application. This is done by doing a call to a cache (optionally) which returns the user session associated with the websocket. This session can be updated during the websocket lifetime if needed (if your protocol deals with auth as part of it's messages and not on connection)

Some doc links:

https://vramework.dev/docs/channels/channel-intro

A post that explains vramework.dev a bit more in depth (linked directly to a code example for websockets):

https://presentation.vramework.dev/#/33/0/5

And one last thing, it also produces a fully typed websocket client, so if using routes (where a property in your message indicates which function to use, the approach AWS uses serverless).

Would love to get thoughts and feedback on this!

edit: *and potentially Cloudflare, though I’m not entirely sure of its internal workings, just the Hibernation server and optimising for cost saving

I raised an issue here https://github.com/vramework/vramework/issues/119, feel free to add any info that can help.

Note to self: need to signup to X!

If deploying off of vercel is acceptable, it can be done pretty nicely via serverless-nextjs or nextjs docker in one server. But from what I understand vercel internally does quite a bit of code analysis to split things and I don't really want to get too deep into the weeds in that direction

Thank you for raising!

Also curious how you would want Websocket servers to talk to each other (to broadcast messages). Would you be okay having a pub sub layer like redis that nestjs servers run on?

Also is running on vercel a requirement?

The difference between the two versions is that we now have a cli, whereas before you needed to call scripts to do the same things

Yes it’s ws using lambda, the worker-starter example shows how it works

Also abstracts away the idea of an eventbus which is pretty critical in any Websocket deployment.

It doesn’t use Websocket directly via Vercel, but would work if you use nextjs by providing it a http server and also providing that server to ws

Can get this to work, but I’m pretty curious why you think this is a game changer? Thanks!

Thank you!

Heya!

It’s used in three companies so far, but the new productised (via the cli) version is still in development / qa stages

There is one company that has been using it for over four years tho! Just checked in and seems to be working solid

Looks great!

I build something similar (vramework.dev), actually on my way now to give a talk on it

Got a presentation for it at presentation.vramework.dev if anyone is interested

This looks incredible, thank you for creating it! I have been looking for something exactly like this for a while now

I feel that with typescript you can sort of build an SDK by creating a thin wrapper around fetch and have it consume the API types as a generic.

This way you still have the benefits of type safety without the bloat of creating an actual SDK.

SDKs tend to be useful when they hold state / don’t just proxy to a rest call, but I don’t see why we need wrapper libraries. They also hide away the complexity of knowing how the rest api is meant to consume data (query / params / body / encoding). So the assumption is the rest API itself makes sense.

I took this approach with a backend typescript framework called vramework.dev which can generate openapi specs as well as the thin fetch wrapper, and feel like for my projects satisfies my needs.

Do you think having a normalization layer between serverless and server-based approaches could actually help with the issue of becoming too dependent?

I find that the tight integration with providers like Azure, AWS, or CloudFront can make switching between them a very costly upfront decision.

Another disadvantage of serverless is that it’s quite challenging to produce an on-premises or enterprise-ready codebase if the need suddenly arises.

I think lambdas work really well for doing things as a reaction.

So for example, uploading an image to s3 could trigger a job, or having them run in parallel on a job queue since they theoretically scale way better then spinning up lots of 'job processors' to deal with influx.

One of the most fringe but interesting usecases I'm aware of is it being suggested as part of co2 (and cost) reduction. The main idea is that since lambdas only run the exact amount of time needed, we don't continue running/reserving costly machine time. This is still something where research is being done and does mostly pass the responsibility to the infrastructure / PaaS solution though

I personally went down the route of creating a mini wrapper around functionless/functions which allow me to run things locally via a server and then when it comes to deployment decide whether it should run via serverless or docker / on a vm via adaptors.

It doesn't allow you to simulate a lambda function directly, but makes the assumption (that held so far) that all the different API's and runtimes usually come down to the same core principles (HTTP / Websocket / timed jobs).

The core idea is exactly around testing which approach works best for lambdas / functionless.

https://vramework.dev/

Disclaimer: The core maintainer and I haven't yet published the serverless adaptors. Also need to update the landing page, as the serverless/server switch is only one of the core principles.

SEEKING WORK | Berlin (CET/CEST) | Remote | Part-time | Available Immediately

Senior Full-Stack Developer and Cloud Specialist with 14+ years of experience seeking part-time contract work.

Experience Highlights: - Fintech: 5 years with banks and hedge funds - Co-founder: deepstreamHub.com - AI Projects: Focus on mindfulness and mental health - Infrastructure Contracting: Security audits, cost optimization, minimizing downtime, feature environments / QA tooling, monitoring, CI workflows

Skills & Expertise: - Infrastructure: AWS, Azure, Terraform, Docker, CI/CD, logging, alerting systems - Optimizing infrastructure and development workflows - Reducing cloud costs - Full-Stack Development: Postgres, MongoDB, React, React Native, Next.js, Tailwind, Node.js

Seeking a part-time role with a motivated team working on meaningful projects. If you need senior expertise in infrastructure optimization or full-stack development without the commitment of a full-time hire, let's connect.

Contact:

- linkedin.com/in/yasserfadl - [email protected] - github.com/yasserf

SEEKING WORK | Europe/UK | Remote | Part-time | Berlin Timezone (CET/CEST) | Available Immediately

Senior Full-Stack Developer and Infrastructure Specialist with 14+ years of experience seeking part-time contract work.

Experience Highlights:

Fintech Expertise: 5 years with banks and hedge funds. Startup Co-founder: deepstreamHub.com AI Projects: Focused on mindfulness and mental health. Infrastructure Contracting: Specialised in infrastructure projects.

Skills & Expertise:

Infrastructure: AWS, Azure, Terraform, Docker, CI/CD, logging, and alerting systems. I focus at optimizing infrastructure, accelerating development workflows (e.g., automatic QA environments on push), and reducing cloud costs and carbon footprint.

Full-Stack Development: Proficient in Postgres, MongoDB, React, React Native, Next.js, Tailwind, and Node.js.

What I'm Looking For:

I'm seeking a part-time role with a motivated team where I can apply my skills to meaningful projects. Available immediately for part-time engagements in the Berlin timezone (CET/CEST). If you need senior expertise in infrastructure optimization or full-stack development without the commitment of a full-time hire, let's connect.

Contact:

LinkedIn: linkedin.com/in/yasserfadl Email: [email protected] GitHub: https://github.com/yasserf