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

Node.js Fundamentals: Web Server Without Dependencies

blog.bloomca.me

Post reply on HN
Print view View original

41–44 of 44 posts

Re: Node.js Fundamentals: Web Server Without Dependencies

#41

Post by Y7ZCQtNo39 »

devxpy wrote: post #39
Y7ZCQtNo39 wrote: post #38

Earlier quoted context omitted.

I'm not a huge fan of decorators since they obfuscate the state of the runtime. What exactly does the call stack look like when login gets invoked? What variables are in scope? I find it difficult to reason about. I understand that this function will execute when the HTTP server receives a GET or POST request at `/login`. The semantics of the decorator is clear-- I don't particularly take issue with that. But the sec…

Well, You'll be happy to know that a decorator is literally just a function that takes another function as its first argument. @app.route(...) def login(): ... Is literally the same thing as - def login(): ... login = app.route(login, ...) Hopefully that clears up the air a bit?

It clears it up but personally, I'd rather just write `app.route(login, ...)`. Isn't a lot clearer to use more conventional language features? What exactly is this buying me?

I don't know if me saying 'Just, why?' is a good enough reason to throw my arms up and say it's an idea I'm not a fan of. I'm willing to say that it's a rather subjective attitude.

I guess my retort is that, it's far more confusing to have that syntax, then explain what it meant, when I could've just used the conventional syntax.

It's not like it's offering me something substantially simpler. For example, the spread operator that was introduced. It actually allows you to write clearer JavaScript code. This syntax isn't intuitively clear like the rest operator is.

Re: Node.js Fundamentals: Web Server Without Dependencies

#43

Post by hardwaresofton »

devxpy wrote: post #37
hardwaresofton wrote: post #15

Earlier quoted context omitted.

IIRC before nodejs+express the req/resp/next paradigm and middleware paradigm had never been so accessible. Other frameworks had it of course, but it was often hidden behind layers of abstraction or little quibbly bits. Express gave you just what you needed for both middleware and handlers: app.get('/', function(req, res, next) { res.send('hello world'); }) For comparison, flask: @app.route("/", method='GET') def hel…

>Need to access the request? use `req` Well, I don't see what's especially difficult about this? from flask import request @app.route('/login', methods=['GET', 'POST']) def login(): if request.method == 'POST': return do_the_login() else: return show_the_login_form() I would actually argue that this is better, since I have to type "request" only once. Although I have to admitt, the middleware thing looks quite compos…

Other people basically covered it but yeah my problem is how `request` comes out of nowhere. The NodeJS snippet is way more obvious, treating the two handlers as separate (`app.get`, `app.post`) is cleaner, and it's immediately obvious what's happening, no need to know about `flask.request` to undrestand the code. I have come to abhor non-obvious code, and on that metric the flask code loses by a step in my mind.

If we really want to get in the weeds, we could talk about python 2.x's floundering around async IO -- IIRC Twisted/Tornado/Gevent/Eventlet were all close to equally good options (and thus mindshare was split) while node had it built in, with a virtualenv-by-default packaging system. Also there's WSGI -- the interoperability it provides is cool, but also means more moving parts than a simple node+express setup.

I don't want to make this a nodejs vs python thing, because that's a really dumb conversation (argument) to try and have, but personally node+express is what I pick over python+flask any day of the week for spinning up simple "just-good-enough" web services. These days I've been checking out Molten and Falcon (I'm a huge fan of pypy) but when I need to build a quick server I just pick up node+typescript.

Re: Node.js Fundamentals: Web Server Without Dependencies

#44

Post by hardwaresofton »

eropple wrote: post #36
swaggyBoatswain wrote: post #32

Earlier quoted context omitted.

Its not as opinionated as rails/django but there's typeORM among others

TypeORM exists, but I hope you really, really like having it own your schema. Its support for migrations, rather than "uh, just let us do our thing!", is sneaky-not-great. There's no documentation, for example, for how anything in a TreeRepository actually is structured in the database, and the recommendation is "let us run the DDLs on a scratch database, you can puzzle it out from there", which should make your bloo…

I've actually had great success with TypeORM now on various personal and client projects... Maybe I haven't used all the features you have used (like I've never touched TreeRepository...), but I've never had a problem with the migrations because I just write my own, and I write my own models, etc. TypeORM has had the best combination of fullblown ORM and just-build-my-query-intelligently that I've seen to date.

TypeORMs migrations are pretty simple, just write your own migrations? I only use TypeORM to generate the migrations (i.e. `typeorm migration:create -n `, then open the generated file and write `await queryRunner.query(`....`);` and craft the migration myself, and make sure the changes are reflected as need by in the related models.

TypeORM is actually a better ORM than a lot of the options out there. I remember using C#'s EntityFramework (this was during the move from .NET 4.x to core/standard) and I kept wishing I was using TypeORM over it -- the annotations in EF were half-baked (to be fair they were still porting functionality), and it was just shitty all around. Then again, C# is my weakness so maybe I just didn't have enough skill.

Post reply on HN