[HN Gopher] Hono v4.0
___________________________________________________________________
Hono v4.0
Author : MrAlex94
Score : 166 points
Date : 2024-02-09 11:55 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| arminluschin wrote:
| I only ever used hono as a simple convenience router for my
| cloudflare functions. This feels ambitious. I'm a bit skeptical
| if this is the right direction frankly, I hope it doesn't make
| the framework too bloated.
| cosbgn wrote:
| Same, I'll probably move to https://github.com/unjs/h3 since
| it's used anyway in Nuxt (which I use for other projects)
| eddd-ddde wrote:
| Not too long ago I discovered itty-router and since then it's
| the only thing I need for my APIs.
|
| It's extremely minimalist, I just create a context object and
| implement in it any functionality I need such as headers, error
| handling, anything.
|
| I even use it for "CLIs" that I then call with curlie.
| lf-non wrote:
| Yeah, I like Hono, but it was surprising to see a react
| alternative from them. I am not sure why they are trying to
| compete with preact/atomico.
| evnix wrote:
| Have to agree on this one. As a current user of Hono, I'll just
| switch to a proper router.
|
| I don't want those SSR oddities and react like "hooks" sneak
| into our backend codebase. They have been a constant source of
| confusion, bugs and performance issues in our frontend app.
|
| Let me save you from typing the obligatory HN response: YoU
| DoNt HaVe tO UsE ThOsE
| kkielhofner wrote:
| Same. IMO Hono + Workers seems to be somewhat of a hidden gem
| but this largely comes down to Workers, of course.
|
| The performance (and especially pricing) is pretty wild and
| combined with various bindings (R2, KV, D1, AI, etc) general
| Cloudflare stuff, free egress, etc it can provide significant
| advantages.
|
| That said looking at this I'm confused, to put it mildly, and I
| may start looking elsewhere. Back to itty-router?
| drewbitt wrote:
| Doesn't seem right to me either. Of note though, it has not
| bloated the core and you can continue using the backend
| portions the same as before.
| surprisetalk wrote:
| I'm using Hono and Deno for https://flashcasts.com
|
| Hono + Postgres.js is getting pretty close to my ideal web stack.
|
| IMO, SSR websites is the best way to get projects out quickly:
| predictable "builds", minimal surface area, boring tech, etc.
|
| It helps that Hono has a very clean API :)
| xrd wrote:
| Another thread here mentioned SQLite. Can you say more about
| why/how you are using postgres.js? I use pocketbase a lot and
| am curious how your stack handles auth, login, etc?
| surprisetalk wrote:
| Here's two posts I wrote on how I do email tokens and async
| workers:
|
| * https://taylor.town/pg-email-token
|
| * https://taylor.town/pg-task
|
| Here's a condensed version of how I do login/signup:
| app.post("/signup", async c => { const body = await
| c.req.parseBody(); const usr = { email:
| body.email.toString(), password:
| sql`crypt(${body.password.toString()}, gen_salt('bf', 8))`,
| } as Record<string, unknown>; const [{ usr_id, email,
| token }] = await sql` with usr_ as (insert into usr
| ${sql(usr)} returning *) select usr_id, email,
| email_token(now(), email) as token from usr_ `;
| await sendVerificationEmail(email, token); await
| setSignedCookie(c, "usr_id", usr_id, cookieSecret);
| return c.redirect("/u"); });
| app.post("/login", async c => { const { email,
| password } = await c.req.parseBody(); const [usr] =
| await sql` select *, password =
| crypt(${password.toString()}, password) AS
| is_password_correct from usr where email =
| ${email.toString()} `; if (!usr ||
| !usr.is_password_correct) return c.html(<p>Your password was
| incorrect.</p>); if (!usr.email_verified_at) await
| sendVerificationEmail(usr.email, usr.token); await
| setSignedCookie(c, "usr_id", usr.usr_id, cookieSecret);
| return c.redirect("/u"); });
| xrd wrote:
| Ha, Taylor, of course this is you doing cool things in cool
| outfits. I should have known. Thanks!
|
| My favorite truth in that site: "Anyway, instead of
| learning biochem and spanish I went and built this stupid
| website." I don't know what you are talking about at all.
| xrd wrote:
| OK, I need to say more about this code snippet. I'm really
| fascinated by it.
|
| This is typescript, which is interesting because we have
| more confidence the JS "works."
|
| But, it is also embedding SQL directly into your
| typescript.
|
| Isn't that a contradiction in code? I'm NOT suggesting you
| refactor to use an ORM or something!
|
| When I was an Android developer, I thought it was really
| fascinating to see how Room worked. Each SQL statement you
| created was actually compiled and validated at compile time
| not runtime, and it meant the SQL was sanity checked and
| sanitized.
|
| Nothing like that is happening here, right? You cannot
| validate this SQL at compile/build time? If not, aren't you
| YOLO riding the motorcycle but telling mom you are wearing
| your helmet?
| DrDroop wrote:
| I also use postgres.js a lot, but most of the time I
| don't even bother with the typescript. If you develop
| using the JetBrain suite then you can have really good
| support for sql embedded in strings, it is aware of your
| schema and does syntax highlighting.
| surprisetalk wrote:
| _> Nothing like that is happening here, right? You cannot
| validate this SQL at compile /build time? If not, aren't
| you YOLO riding the motorcycle but telling mom you are
| wearing your helmet?_
|
| Correct! It's a total pain haha.
|
| I loathe SQL, but it's the best tool for most modern web
| apps.
|
| All of flashcasts.com is 1800 lines. I'd guess 30% is
| HTML and 30% is SQL.
|
| The SQL does the vast majority of the heavy lifting if
| you think about moving bits over distances.
|
| So SQL is really important, but why don't I have any
| safeguards? Well, in my experience, the available
| safeguards are medicine more painful than the poison.
|
| For example, any of the queries in my app I can copy-and-
| paste into psql and start an interactive debugging
| session. Can't do that with ORMs.
|
| In my app, I dynamically aggregate and build all the
| podcast XML for every feed in a single Postgres query.
| It's super performant and surprisingly little SQL. Can't
| imagine doing that through an ORM.
|
| SQL queries will throw an error if they're not well
| formatted, so you just have to write a test suite that
| somehow hits every query exactly once. You can do this by
| separating out your SQL, or integration tests, or a
| handful of other methods, none of which are pleasant.
|
| Anyway, I'm tired of SQL, sol I'm working on an embedded
| query language in scrapscript. Stay tuned for details:
|
| [1] https://scrapscript.org
| paulryanrogers wrote:
| Isn't there a risk of SQL injection from user input?
| surprisetalk wrote:
| postgres.js sanitizes inputs, but also provides a
| backdoor, so sql`select ${"hello"},
| ${sql`world`}`
|
| becomes select $1, world
|
| [1] https://github.com/porsager/postgres
| LorenzoGood wrote:
| I am taking the SAT soon, and I am going to try out your
| flashcards. Thanks!
| _heimdall wrote:
| I've used deno + hono and a basic file-based router for a few
| projects now. The biggest win IMO is avoiding a build step, I
| hope HonoX and the hono project in general don't start walking
| down the same path as others, using Vite for a required build and
| bundle step.
|
| Astro already solves many of the problems HonoX will run into, if
| a build step with Vite is acceptable for you. What I personally
| really want is an easy way to deploy exactly what I have locally
| and keep my dependencies small enough that shipping it unbundled
| isn't a problem for your project.
| iainmerrick wrote:
| How does the "basic file-based router" work, out of interest?
| _heimdall wrote:
| It was a pretty lazy one-off router, nothing too fancy. I use
| deno's file API to scan a `routes` directory and modified a
| copy of Astro's router to parse filenames and prioritize
| route matching patterns.
|
| API-wise its very similar to most other file-based routers,
| including HonoX. Each file exports `GET`, `POST`, etc
| functions to handle requests.
| postepowanieadm wrote:
| Hono, Bun and SQLite are soo boring - I love it.
| joshstrange wrote:
| Hono looks very cool but in my experience you can quickly run out
| space in your lambda (package size) when you bundle your whole
| application together verses having each endpoint be it's own
| package.
|
| Am I wrong or have others experienced this as well? Just having 1
| package (to deploy vs 1 per endpoint) would be super nice in a
| number of ways and you could take advantage of things like
| provisioned concurrency (something much more difficult to plan
| for when you have a lambda per endpoint).
|
| Maybe I'll just branch my main project and see what happens as I
| move my code into a monolith with Hono but I'd love some feedback
| if others have experienced this and/or how they worked around it.
|
| I guess you could still have multiple Hono-based packages that
| handle segments of your backend (verses all in one), is this how
| people are managing it?
| willsmith72 wrote:
| how much space is too much? curious how much you've had hono
| apps use
|
| i've done a few express apps on lambda, just because it was a
| free way to host fun projects and i didnt want to use a custom
| framework/tech, and they never got above 25MB zipped. big, but
| not really close to the limit (i believe 50MB)
| joshstrange wrote:
| I've never used Hono, I'm just interested in it. I think the
| AWS Lambda limits are something like 50Mb compressed and
| maybe 200Mb uncompressed. I might be a little off, I'm on my
| phone right now.
|
| Prisma doesn't help matters but right now I take that hit on
| every function package anyway.
|
| I might just need to try it one day (move my existing app to
| Hono to see if it would work).
| toinbis wrote:
| Am very curious about the same very question.
|
| "I guess you could still have multiple Hono-based packages that
| handle segments of your backend" -> I am thinking the same - if
| you hit bundle size problems, you can just split your app.
|
| I'd also love to see some benchmarks how bigger bundle size
| impacts the performance - i.e. 1 MB adds additional 1ms on
| average, or so... My platform of interest is mostly Cloudflare
| Workers.
| bleeding wrote:
| I think with Lambda there are a lot of downsides to either
| approach. When you build the Lambda as a monolith, you also
| give all the code executing from that monolith access to all
| the resources needed by every single route in the Lambda. When
| I was working with Lambda a lot, we had a lot of secrets that
| were only needed by a few routes, and which would have been
| very bad if someone misused those secrets from a different
| place.
|
| But if you have a sufficiently large enough API surface, doing
| one lambda per endpoint comes with a lot of pain as well.
| Packaging and deploying all of those artifacts can be very time
| consuming, especially if you have a naive approach that does a
| full rebuild/redeploy every time the pipeline runs.
|
| I think there's a happy medium where you group lambdas by
| resource type or domain, but even still it can be tricky to
| enforce "least privileged access" for those when the content of
| the lambdas is constantly being added to. Eventually there is
| creep in the IAM permissions available to those lambdas.
|
| I came up with a system that did incremental build/deploys for
| all of our lambdas based on the code changes since the last
| builds/deploys, but even so that came with some pain and
| definitely some hacks that I wouldn't do again (and relied on
| technologies it was difficult to get other people to engage
| with, like Bazel.) I also think Lambda (in particular of the
| FaaS options) is...not great for APIs, especially if you use a
| language with a long cold start time.
| joshstrange wrote:
| > But if you have a sufficiently large enough API surface,
| doing one lambda per endpoint comes with a lot of pain as
| well. Packaging and deploying all of those artifacts can be
| very time consuming, especially if you have a naive approach
| that does a full rebuild/redeploy every time the pipeline
| runs.
|
| Yeah, thankfully SST [0] does the heavy lifting for me. I've
| tried most of the solutions out there and SST was where I was
| the happiest. Right now I do 1 functions per endpoint. I
| structure my code like url paths mostly, 1 stack per final
| folder, so that the "users" folder maps to "/users/*" and
| inside I have get/getAll/create/update/delete files that map
| to GET X/id, GET X, POST X, POST X/id, DELETE/id. It works
| out well, it's easy to reason about, and deploys (a sizable a
| backend) in about 10min on GitHub Actions (which I'm going to
| swap out probably for something faster).
|
| I agree with the secrets/permissions aspect and I like that
| it's stupid-simple for me to attach secrets/permissions at a
| low level if I want.
|
| I use NodeJS and startup isn't horrible and once it's up the
| requests as very quick. For my needs, an the nature of the
| software I'm writing, lambda makes a ton of sense (mostly
| never used, but when it's used it's used heavily and needs to
| scale up high).
|
| [0] https://sst.dev
| bleeding wrote:
| Nice, we evaluated their Seed product but didn't pull the
| trigger, which caused me to eventually roll our own. I'm
| pretty proud of what we ended up with but due to reasons we
| ended up with _hundreds_ of lambdas, for which a full re-
| build re-deploy took around 45m (Go lambdas).
|
| We used Go and the Serverless framework (ugh), and if I had
| to do it all over I would probably just use AWS SDK since
| it would make doing the "diff" to redeploy dead simple,
| since everything is just a binary to build.
|
| Your use case definitely makes sense for Lambda APIs
| though! I think my complaint is more directed at APIs that
| back frontends. We had a JVM lambda API there for a while
| that was horrificly slow startup unless you set provisioned
| concurrency, which gets expensive fast.
| joshstrange wrote:
| Yeah, I totally understand and agree with your
| "downsides" for lambdas. My use case just happens to gel
| perfectly with them but it's not a "one-size-fits-all".
|
| I also looked at SEED and I would like to give them money
| but some of their methodology with SEED didn't fit with
| mine and since my deploys aren't horrible I left my
| system as-is. Also I understand they need to make money
| but I wish more tools geared towards serverless "scaled
| to zero". I'm happy to pay but my company has such bursty
| traffic that paying for a plan (on SEED or something like
| monitoring) that can handle our "peak" means burning
| money 70%-90% of the time while our app is scaled to zero
| but we still have to pay for tools around it.
|
| Some monitoring tools, like New Relic, are based on usage
| but both NR and DataDog have absolute shit serverless
| monitoring solutions and their docs are a dumpster fire
| (at least around serverless). It's also unfortunate that
| most serverless monitoring means adding ~$10 per account
| per month (in increased AWS costs) just for their data
| pipelines to scan CloudWatch logs. This again sucks since
| we have an AWS account per client but each client is only
| active for ~1mo every year so it can get expensive fast.
| pbronez wrote:
| Never heard of this, took some digging to figure out what it is.
| Best blurb I found was in the docs, not the homepage:
|
| Hono - [Yan ] means flame in Japanese - is a small, simple, and
| ultrafast web framework for the Edges. It works on any JavaScript
| runtime: Cloudflare Workers, Fastly Compute, Deno, Bun, Vercel,
| Netlify, AWS Lambda, Lambda@Edge, and Node.js.
| Kennnan wrote:
| I use hono a lot and im going to avoid these new features for
| certain. Hono already had a problem with documentation and
| feature completeness for anything beyond their simple REST api,
| such as their middlewares like graphql and RPC. The jump in
| complexity from a meh graphql plugin to a full stack SSR
| framework is so massive and I don't think the current dev team
| can do it justice.
|
| I highly recommend anyone looking into this to instead stick with
| larger, better community supported projects like Astro.
| lf-non wrote:
| I formed a similar impression. I tried using their graphql
| plugin only to discover that there was no way to pass a context
| to the graphql handler (at the time) which was surprising. I
| went back to yoga after that.
| rozenmd wrote:
| I rewrote OnlineOrNot's API to use Hono + Zod (almost a drop-in
| replacement for Express), and got an OpenAPI schema out of it for
| very little additional work.
|
| I highly recommend it, and wrote more about it here:
| https://onlineornot.com/built-my-http-docs-from-scratch#conv...
| carstenhag wrote:
| Nowhere there's any explanation of what this is. Web standard?
| Fast? Workers?
|
| Ok, but what is it doing? How can it help me? The snippets
| subpage is empty. The examples have code directories with almost
| empty readmes.
| asplake wrote:
| I agree that "fast, lightweight, web standards" isn't much of a
| description but not too far down https://github.com/honojs/hono
| I did find this:
|
| > Hono ... is a small, simple, and ultrafast web framework for
| the Edges. It works on any JavaScript runtime: Cloudflare
| Workers, Fastly Compute, Deno, Bun, Vercel, AWS Lambda,
| Lambda@Edge, and Node.js.
| MrAlex94 wrote:
| Sorry, should've probably added a text description.
|
| Hono is a JavaScript framework designed to run on (but not
| just) Edge runtimes. It's nice due to it being very
| "lightweight". It was mainly for server side functionality but
| this release adds more front end functionality, which I find
| quite welcome.
|
| Personally I have found this works well if you're targeting
| those platforms. For example, I use it on Cloudflare Pages with
| Page Functions and it works a dream.
|
| I haven't found it to be a write once target anywhere platform
| (for example, serving static files differs between platforms),
| but it makes it significantly less effort to migrate to a new
| platform if necessary, which is always nice.
| deliriumchn wrote:
| yeah, the text on their main landing page reads like a promo
| you see in a game; just a combination of fancy words lol
|
| "Hono
|
| Fast, Lightweight, Web-standards
|
| Runs on any JavaScript runtime."
| theultdev wrote:
| fast = fast routing / throughput
|
| lightweight = small code size
|
| web standards = not node apis (fetch, not http.createClient,
| etc.)
|
| runs on any JS runtime = runs in deno/node/bun/workers/etc
|
| ---
|
| But yes the project is meant to be read by someone already in
| the field.
|
| The people who actually know how to use it.
|
| Yes it seems like a fancy combo of words if you don't know
| what they mean, but that's true for anything.
| jonahx wrote:
| > Yes it seems like a fancy combo of words if you don't
| know what they mean, but that's true for anything.
|
| This is untrue: it's possible to make things much more
| accessible than they are here.
|
| You write for an audience. This project could have written
| a description that works for "most programmers with any
| background at all in web development." Instead they chose a
| much narrower audience. People are complaining about that
| choice.
| theultdev wrote:
| Sure, and they can complain to their hearts desire.
|
| But it would be more fun to talk about the tech.
|
| 1. The OP is not the author of this project.
|
| 2. The project author did not know it was going to be
| directed at a more general audience.
|
| 3. They may have prepared the README for that if they
| knew.
|
| 4. Enjoy the tech and stop being so damn nitpicky HN
|
| So to end this, I explained the tech and reason why:
|
| https://news.ycombinator.com/item?id=39318998
| ggregoire wrote:
| From the example it seems like it's to make HTTP APIs? You
| declare a route "/" and it returns the content "Hello Hono!"
| for this route. The word "API" appears twice on the landing
| page and github README, and the word "web framework" appears
| once on the github README. But indeed we shouldn't have to
| scrutinize all the sources of information to know what this is.
|
| Also "web standard API" doesn't really mean anything? Might
| just be because the authors are not native English speakers
| tho.
|
| I'd rewrite the main description to "Hono: Fast, Lightweight,
| web framework to build APIs" or something. See FastAPI landing
| page [1] for a reference: "FastAPI is a modern, fast (high-
| performance), web framework for building APIs with Python 3.8+
| based on standard Python type hints." I know immediately what
| this is.
|
| [1] https://fastapi.tiangolo.com
| 16bytes wrote:
| Thank you. Even after spending 10 minutes reading, I still have
| only a vague idea of why this project exists.
|
| All of the code examples look like a slightly different syntax
| for express.js.
|
| So it's a server side javascript framework for handling HTTP
| requests?
|
| Since it targets multiple runtimes, I suppose it's "express.js
| but without the node.js dependency?".
|
| I feel like that's closer, but I'm still missing the "why
| should I care?" part.
| theultdev wrote:
| it's a much faster, leaner, express.js on the edge.
|
| you can't run traditional http servers in edge sandbox worker
| environments.
|
| frameworks like these target deno deploy, cloudflare workers,
| aws lambdas, etc.
|
| they are small to fit in worker 1mb~ limits and use browser
| apis instead of node apis to fit the env.
|
| bonus: sharing the same apis on the server and client also
| result in being able to share code client/server side.
|
| You'd only care if you were in the "serverless" field, and
| then you'd likely already know about Hono since it's linked
| in many documentations like Supabase, Cloudflare, Deno, etc.
|
| But you may not know about Hono because there are many
| options and some ways to be in serverless without seeing it
| yet and it's the newest framework I know of. (also my
| favorite so far other than raw deno)
|
| --
|
| This particular release was linked since it's one update that
| turns it into a real framework like Next or Astro.
|
| They added 3 major features:
|
| - Static Site Generation
|
| - Client Components
|
| - File-based Routing
|
| Static site generation (SSG) would mean certain routes
| compile at build time and the worker won't compute them on
| the edge.
|
| Client components means they now support client side
| rendering (CSR), before Hono was only used for server side
| rendering (SSR).
|
| File-based routing is instead of coding your paths, the
| folder structure is used for routing, similar to Next which
| mimics how traditional http web serving works.
|
| --
|
| This is important for users of Hono as it unlocks features
| that exist in larger frameworks while still staying extremely
| minimal and flexible.
| cacozen wrote:
| I know AWS's LLRT was just announced, but it would be great if
| this would support it. (For reference:
| https://github.com/awslabs/llrt)
| davidy123 wrote:
| Would this be a sort of holy grail product, where we could write
| once for 'edge/function/lambda' systems? I am helping develop a
| new project that will be hosted on Azure, but would really like
| to make it as cloud portable as possible, including a cloud-free
| version. It is a significant product for a government agency, and
| it will be open source. I really want to get this piece right.
| Thanks!
|
| [edit] I notice Azure support is under development. But the time
| frame could be ok if it has good tests & the project is well
| supported.
| cranberryturkey wrote:
| how does this compare to primatejs?
| pdyc wrote:
| I am using it to build https://easyanalytics.win . Honojs is a
| nice framework for routing. I chose it because i was working on
| cloudflare functions and i did not wanted to tie my application
| to cf way of doing things. By using honojs i can use it in both
| serverless as well as server-full settings without any changes.
| However i am not liking the current direction this project is
| taking its becoming too bloated.
| reactordev wrote:
| This is awesome! The server-side, the page gen, the router, jsx
| on the backside, outstanding work!
|
| In webdev, I've been a huge fan of vite since it came out. Not
| having to wrangle configurations and bundlers and everything was
| very welcome. I wrapped it all up into a useful internal tool to
| play nice with our packages and splice together express+vite
| frontend. Then koa+vite. After playing with bun, I'm very keen on
| stack setups with convention over configuration (with config
| options) to just do the typescript thing, do esm, do it well.
|
| I'm going to give this a go this weekend and see if this can
| replace our setup. Bun+Vite(React-TS)+Koa.
___________________________________________________________________
(page generated 2024-02-09 23:01 UTC)