Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Build your own web framework

vercel.com

Post reply on HN
Print view View original

121–130 of 155 posts

Re: Build your own web framework

#121

Post by eyelidlessness »

Cyberdog wrote: post #119
eyelidlessness wrote: post #98

Earlier quoted context omitted.

Make other database requests, or return the responses derived from prior requests. Or just anything else waiting in the event loop queue, including queueing more work. You can think of the concurrency model like green threads with only one thread available, or actors in a single system process. Edit to elaborate: yield/suspend is key here. The way it works is yielding/suspended calls have their outstanding work put b…

I'm trying to envision a situation where you'd want to make more than one database request at the same time. Like I guess on a blog or something, you could load the user record of the current user and then load the blog post details at the same time, but then there's a chance that the user doesn't have permission to view that blog post and then the request for the post has gone to waste, right? It goes against my ins…

> I'm trying to envision a situation where you'd want to make more than one database request at the same time.

Because I have two requests active at the same time and the second one which arrived shouldn’t wait for me to stand around doing nothing while I wait for the database to serve the first.

> Like I guess on a blog or something, you could load the user record of the current user and then load the blog post details at the same time, but then there's a chance that the user doesn't have permission to view that blog post and then the request for the post has gone to waste, right? It goes against my instincts to kill a request as quickly and directly as possible if something can't be accessed.

Here one user represents 2+ events, both of which should fail. This wasn’t part of my original explanation but yielding does give you the opportunity to fail both simultaneously. Albeit in this case it’s just concurrency broadly. Why is that against your instincts, if you know that one request’s failure implies the other will also fail? Why should that user wait in line to get the same error after another cycle of the same trial?

> I'm just not used to thinking of developing back-end web apps that way. But async still just doesn't seem as useful as it would in a GUI desktop app

Yep I get that. And async takes a bit to get used to in general. The way I think of it is: I have two kinds of work which need to be done, and a long line asking me to work. Some of the work needs labor (CPU), some needs patience and communication (IO). Everyone in line needs some of both.

If I do the first person’s immediate labor and wait for further communication, persons 1 and 2 are waiting for me to proceed. If I do the first person’s labor, send off an asynchronous request for feedback on that, I can do N people’s labor before I get any response. As long as no one spends too long making anyone else wait in queue everyone moves as fast as the queue’s capacity.

Re: Build your own web framework

#123

Post by Cyberdog »

eyelidlessness wrote: post #121
Cyberdog wrote: post #119

Earlier quoted context omitted.

I'm trying to envision a situation where you'd want to make more than one database request at the same time. Like I guess on a blog or something, you could load the user record of the current user and then load the blog post details at the same time, but then there's a chance that the user doesn't have permission to view that blog post and then the request for the post has gone to waste, right? It goes against my ins…

> I'm trying to envision a situation where you'd want to make more than one database request at the same time. Because I have two requests active at the same time and the second one which arrived shouldn’t wait for me to stand around doing nothing while I wait for the database to serve the first. > Like I guess on a blog or something, you could load the user record of the current user and then load the blog post deta…

> Here one user represents 2+ events, both of which should fail. This wasn’t part of my original explanation but yielding does give you the opportunity to fail both simultaneously. Albeit in this case it’s just concurrency broadly. Why is that against your instincts, if you know that one request’s failure implies the other will also fail? Why should that user wait in line to get the same error after another cycle of the same trial?

I really have no idea what you're saying here, so let me put it this way. I would code this hypothetical blog page access situation this way in PHP: Get user data from database. Do access checks on user data. See user does not have permissions to view blog article. Show 403 page.

Assuming I'm understanding what you're saying about async database requests, this is apparently "correct" in Node: Request user data and blog post data from database. If the blog post data comes first, wait. When the user data comes, do access check and show 403 page. If the blog post data hasn't come yet… it just gets ignored or something, I guess. Otherwise the data just gets thrown out…?

What's against my instinct is to make the request for the blog article data unless and until it is known that it will be needed.

Re: Build your own web framework

#124

Post by saghm »

cercatrova wrote: post #110
jeshin wrote: post #69

Earlier quoted context omitted.

on the note of babel, I don't usually do front end stuff but the other day I wanted to transpile one single javascript file to support older browsers, one time and then never again. I tried for like an hour and I could not figure out how to do it, without setting up like a whole environment/pipeline for it. My expectation going into it was "surely there's some sort of command that just lets you do input file -> outpu…

If it's only one file, you could just go to the Babel website where they have a playground and paste it in, voilà, converted for older browsers. Now place the output file wherever you want.

Not sure if they edited their comment (although it seems unlikely given that your comment was four hours later), but that sounds exactly like what they said they did. Maybe I'm old-fashioned, but the idea that I need to upload a plaintext file to have it converted to another plaintext file so I can download it instead of just having a command to run locally seems almost surreal.

Re: Build your own web framework

#125

Post by cloudc0de »

akmittal wrote: post #9
upupandup wrote: post #4

not sure how this differs with AWS, you can do more at less cost than Vercel

AWS is overwhelming for most of Developers. Also vercel is focusing on ease of deployment for front end, it is also zero config, you can just deploy nextjs, react, svelte, remix apps in matter of minutes. Which is impossible with AWS

AWS Amplify Hosting is the direct Vercel competitor and has improved since it's initial launch quite a bit. Also has a decent free tier

Re: Build your own web framework

#126

Post by intelVISA »

hsn915 wrote: post #81
tambourine_man wrote: post #77

What a sad state “modern” web dev is in. I’m glad that I’m living in a much faster and simpler world, but I fear, for end users and developers alike, that it is an ever shrinking one. I really can’t understand the appeal of what, to my eyes, amount to endless layers of needless complexity. I wish articles such as this one were more common: https://alexcabal.com/posts/standard-ebooks-and-classic-web-... This is the we…

With modern hardware it is very easy to serve millions of daily users from a single machine with simple software. No one bothers because everyone loves their fast-as-a-snail framework in their favorite slow scripting language and they need massive infrastructure to scale it to serve less than 1k concurrent users. Programmers have no one to blame but themselves.

I always feel bad when I see novice programmers herded toward frameworks like Flask and Express for uncomplicated API cases, you can take your pick of mature C#, Rust, Java and C++ API frameworks that serve ~7,000,000 responses per second compared to Express' and Flask's ~123,000 and ~15,000 respectively.

Re: Build your own web framework

#127

Post by intelVISA »

Cyberdog wrote: post #120
cercatrova wrote: post #111

Earlier quoted context omitted.

Interesting. Based on this series of responses, you moved from "async is useless" to "actually, I don't actually know what async processes can do, and what happens between each process." It implies to me that your initial comment was written with little understanding of what you purported to denigrate.

Well, I understand what they can do in desktop and mobile GUI apps. But server-side web requests don't work that way; there's a beginning and an end and a pretty straight line between the two.

Cooperative multitasking is incredible for server side applications.

Re: Build your own web framework

#128

Post by JoeyJoJoJr »

intelVISA wrote: post #126
hsn915 wrote: post #81

Earlier quoted context omitted.

With modern hardware it is very easy to serve millions of daily users from a single machine with simple software. No one bothers because everyone loves their fast-as-a-snail framework in their favorite slow scripting language and they need massive infrastructure to scale it to serve less than 1k concurrent users. Programmers have no one to blame but themselves.

I always feel bad when I see novice programmers herded toward frameworks like Flask and Express for uncomplicated API cases, you can take your pick of mature C#, Rust, Java and C++ API frameworks that serve ~7,000,000 responses per second compared to Express' and Flask's ~123,000 and ~15,000 respectively.

Which would you recommend?

Re: Build your own web framework

#129

Post by deeter72 »

intelVISA wrote: post #126
hsn915 wrote: post #81

Earlier quoted context omitted.

With modern hardware it is very easy to serve millions of daily users from a single machine with simple software. No one bothers because everyone loves their fast-as-a-snail framework in their favorite slow scripting language and they need massive infrastructure to scale it to serve less than 1k concurrent users. Programmers have no one to blame but themselves.

I always feel bad when I see novice programmers herded toward frameworks like Flask and Express for uncomplicated API cases, you can take your pick of mature C#, Rust, Java and C++ API frameworks that serve ~7,000,000 responses per second compared to Express' and Flask's ~123,000 and ~15,000 respectively.

This is a gross generalization. And I'm not sure where you are picking up those values from as well or their accuracy, for Flask is ~15,000 on uWsgi or Gunicorn? or the default werkzeug dev server? How you deploy matters very much I'm sure you'd understand.

However, Ultimately development teams make do with the skillset they have and saved development time is saved money. Who cares of the toolset, Most programmers forget about the business objectives ultimately. Instagram's backend was originally Django, they managed just fine for a long time. Using C++ is pretty overkill even for a simple API project and potentially a huge waste of developer time, people seem to forget developer time is expensive.

Re: Build your own web framework

#130

Post by oreally »

intelVISA wrote: post #126
hsn915 wrote: post #81

Earlier quoted context omitted.

With modern hardware it is very easy to serve millions of daily users from a single machine with simple software. No one bothers because everyone loves their fast-as-a-snail framework in their favorite slow scripting language and they need massive infrastructure to scale it to serve less than 1k concurrent users. Programmers have no one to blame but themselves.

I always feel bad when I see novice programmers herded toward frameworks like Flask and Express for uncomplicated API cases, you can take your pick of mature C#, Rust, Java and C++ API frameworks that serve ~7,000,000 responses per second compared to Express' and Flask's ~123,000 and ~15,000 respectively.

How about Go? How fast would it be?
Post reply on HN