Proposed Architecture Question: PerryTS + Centralized API + Web/PWA

[ralyodio]

# Proposed Architecture Question: PerryTS + Centralized API + Web/PWA

I’m evaluating PerryTS for a brand new project and trying to understand the right architecture.

My current understanding is:

- PerryTS is best viewed as a TypeScript-to-native runtime/compiler layer, not a full replacement for a browser web framework.
- For a browser-based web/PWA, I may still need something like Next.js if I need SSR, SEO, public pages, OpenGraph previews, routing, service workers, etc.
- PerryTS seems better suited for native binaries such as CLIs, workers, background daemons, agents, native tools, and possibly desktop/native UI experiments.
- The safest architecture seems to be separating the web app from the central API.

Proposed structure:

```txt
apps/
  web/        Next.js only if SSR/SEO/public web/PWA is needed
  api/        Hono centralized API
  cli/        PerryTS native CLI
  worker/     PerryTS native workers/agents
  native/     Optional PerryTS native UI experiment

packages/
  core/       Business logic
  db/         Database access
  schemas/    Request/response validation
  sdk/        Shared API client used by web/mobile/desktop/CLI/workers

Runtime model:

Browser/PWA
Mobile app
Desktop app
CLI
Worker nodes
Third-party clients
        |
        v
https://api.example.com
        |
        v
apps/api: Hono
        |
        v
packages/core + packages/db
        |
        v
Postgres/Supabase, Redis, queues, object storage, payments, etc.

The key idea is:

• Do not put core business logic inside Next.js routes/server actions.
• Keep the central API independent of the web framework.
• Let every client talk to the same API.
• Use PerryTS where native binaries are useful.
• Possibly move apps/api to PerryTS later if compatibility and server support are mature enough.

So my question is:

Is this the right mental model for PerryTS today?

In other words:

Next.js = browser web/SSR/PWA shell, only if needed
Hono = centralized HTTP API
PerryTS = native CLI/workers/agents/tools, and maybe API later

Or is PerryTS already intended to replace more of this stack, including apps/web or the central API layer?

[proggeramlug]

Hi @ralyodio

Thanks for the question and discussion! These are some thorough thoughts. Let me explain where Perry fits in and where it does not.

Straight upfront: If your web implementation targets traditional DOM, SEO, and things like that, then Perry will at most compile the server returning the HTML/JS bundle (which is independent of Perry itself). Our landing page (perryts.com) does that. It's a Perry compiled server, but the page itself is just plain JavaScript + HTML + CSS. And honestly: Perry is not made to "build" the DOM, that's part of the design.

But, here is where Perry fits in perfectly:

1. Next.js can run as Perry compiled (or Fastify, etc.). This might need some tweaking depending on how you need it, but Perry definitely compiles servers that can serve web/SSR/PWA, etc.
2. Hono, you can actually (almost) compile Hono via Perry and serve it as a binary. Literally in my terminal right now, I am finishing the last few things for Hono projects to compile. So this one is not far out, I expect this to land today/tomorrow.
3. Any native cli, workers, apps, tools, or anything that does not need a DOM can compile and run perfectly fine with Perry.

So what "in other words" is essentially correct, but the long-term idea here is to replace "nodejs" entirely in the stack. (not JavaScript for the browser, but nodejs on the server).

Also worth mentioning: Perry has a fairly mature WASM/WebAssembly platform adoption. For example, this here is Perry compiled: https://bloomengine.dev/jump/

So, depending on "what" you need/want to do in the web browser, Perry can compile natively there as well. It's just not a good fit for "traditional websites/webapps", and that's by design.

Feel free to contact me directly (@realamlug on X/Twitter or proggeramlug on Telegram) if you want to talk more specifically and in detail. :)

[ralyodio]

yeah i've been using next.js for ssr mostly. i guess i still need to keep doing that for the web/pwa app huh?

[proggeramlug]

I am actually intrigued to say: Let's try to get this to compile via perry as well. I'm sure we can do that. The truth is more: I can't tell you "today" that it will work and satisfy what you want. next.js is quite complex and also uses a lot of dynamic features, which we inherently don't support (well).

So short-term: Yes, you are correct.

Soon: We'll have "something" for this. Might not be an exact 1:1 next.js replacement/drop-in but SSR is definetely on the list for what Perry is great for and should be used for.

[ralyodio]

that's ok how can i help?

[proggeramlug]

I'd love to design the project together with you in a Perry-native way. Two reasons why I want to do that:

1. It gives Perry another reference project, which is always good (even if not published)
2. It battletests the compiler and the ecosystem

Interested? if so contact me (telegram, x/twitter or email: ralph@perryts.com)

[ralyodio]

do you have singla or discord?

[proggeramlug]

write me a quick email and I'll send you my discord and signal