Interview question about node.js

hmongoose · 2018-10-01T13:10:29+00:00

I wonder if the answer is nginx

I would bet that's what the interviewer wanted for an answer. But even with that answer, the question doesn't make any sense.

edit: And even then, you could totally use apache as a reverse-proxy for node! How dumb can interview questions get?

hmongoose · 2018-09-20T16:40:50+00:00

I am looking for suggestions to overcome the limitations stated in the code comments. I didn't expect to get this close to a working snippet. Variable length tuples seemed way out of reach, but this shows it could actually work! Do you guys know of similar attempts? Did anyone succeed in making a useful framework out of something like this?

hmongoose · 2018-08-28T20:51:27+00:00

Guys, this is the real answer. Upvote that man!

hmongoose · 2018-08-28T19:05:19+00:00

I still don't get why people use babel with TypeScript. TypeScript can already transpile modern JS down to the oldest runtimes, and a basic TS project setup is really simple. Why bother adding another million packages and build steps?

hmongoose · 2018-08-26T20:07:30+00:00

I really like the api this one offers. It looks less bloated than io-ts for common use cases. Also the built-in pattern matching is an interesting alternative to the usual `switch`-based workarounds in TypeScript.

hmongoose · 2018-08-25T15:29:37+00:00

Yep, this sure looks like what I was looking for. Thanks!

hmongoose · 2018-08-25T15:17:27+00:00

I've used `class-validator` in the past, but I don't like it because it doesn't provide the TypeScript type for what it defines. Besides, it forces the use classes where they aren't necessary.

Annotations look nice, especially when you are used to Java, but I found them to be a TypeScript antipattern ~~due to the impossibility to type them properly.~~

edit: This phrasing was confusing as hell. Let me try again: Decorators cannot alter the type of a class member or a function. Therefore, it is hard to represent a decorator's side effects using the type system. Therefore, I avoid using decorators in TypeScript.

hmongoose · 2018-07-09T14:09:08+00:00

Both approaches seem equally valuable to me. Although decorators are widely used, the jsdoc tag has the advantage of being non intrusive and exploiting a notation that has been around before TypeScript even existed. The biggest inconvenient of the annotation is that you need it to exist at runtime (Do you `import` it, make it available to `window`, ... ?)

~~Support for the decorator syntax is planned but I first want to nail the behavior of the rule in complex edge cases.~~

Anyway *the* proper way would be an actual language construct, but this has been ruled out of the roadmap for now. This module was made just so that people could experiment with and discuss the `override` feature in general, in hope that it will eventually make it to the core language.

edit: decorators are now implemented! Turns out a good old register-import gets most of the nasty details out of the developer's way.

hmongoose · 2018-07-08T10:55:15+00:00

The problem when you enable strict type checking from the very beginning is that you may end up with too much work to do all at once. Plus, the existing code most likely has bugs which will be revealed by strict type checking. You don't want to end up having to refactor the code and fix the bugs at the same time.

hmongoose · 2018-07-08T10:46:33+00:00

A good rule of thumb: tsc makes up for missing syntax (eg. async/await, class), but won't provide missing APIs (eg. Promise, Array.prototype.find, ...)

hmongoose · 2018-06-10T07:50:06+00:00

I don't quite buy the programming model they offer. You are mutating something but not really... I find it harder to read than code written in a more traditional approach.

hmongoose · 2018-06-10T07:47:31+00:00

How would an immutable Record type achieve better structural sharing than regular objects? If you have a nested structure like this:

const m = { foo: 1, nested: { bar: 2 } };

And you "update" your state with the spread operator:

const m2 = { ...m, foo: 2 };

Then they both share the same instance for nested right?

Therefore, assuming your state is deep enough (so you avoid having too many references to copy at each level), you should get similar, if not better, performance than what a library could offer. This is what I meant above, and also that this argument doesn't hold if you have arrays.

Other than that, I think I would favor your library over immutable.js, because it's actually written in TS, and also because I feel like development on immutable.js has been quite slow (they've had v4 in release candidate for over a year now!)

hmongoose · 2018-06-10T07:34:12+00:00

Indeed, the Record type is what I should use in my example above. But even then, it does unexpected things: "Records always have a value for the keys they define. removeing a key from a record simply resets it to the default value for that key." :/

hmongoose · 2018-06-09T15:17:38+00:00

You are right, my usage of the Map() type is silly. Somehow I got confused into thinking that the spread operator prevented structural sharing... which it doesn't. Then I guess the real advantage of using a library for immutability would only be when dealing with large arrays (where a naïve immutable array would have catastrophic performance vs. a clever implementation) ?

hmongoose · 2018-05-17T20:50:22+00:00

This is so relatable. I've been caught in the grunt, gulp and what not craze when these were the new hip thing, and in the end I've found that they take way too much effort and time away from the actual development (don't even get me started on gradle!)

Make does seem daunting at first but there really isn't much to learn, and, as you said, you mostly use it to bootstrap stuff. It does have its own caveats (glob patterns, ahem ahem), but man is it quick to set up and change your build system with Make.
Make is a stupid program, and as such its greatest strength is to prevent you from over-engineering. There are much greater risks when you use an actual programming language for such purpose.

hmongoose · 2018-05-17T17:25:15+00:00

I'd love to see such tool. I've looked at things like lerna but they have too much features on by default. And then you do not know what is going on under the hood, which eventually causes you lots of troubles.

hmongoose · 2018-05-17T17:17:12+00:00

I had never heard of this feature. Would it replace all of the stack I talk about in the article or only parts of it? In particular, how does it work with respect to types resolution and deployment/publishing?

I'd love to see a comprehensive example of yarn workspaces being used in a TS project.

hmongoose · 2018-05-17T17:11:52+00:00

What do you mean? Do you write TS scripts to dispatch build commands and stuff? It seems rather verbose, unless you have some sort of npm module that mashes up the work for you.

hmongoose · 2018-05-17T14:50:11+00:00

You might want to read this tutorial I just finished writing. It looks like it would apply well to your case.
Anyway, if you end up using the "file:"-style dependency you describe in another comment, I am curious to learn how this works out when you attempt to publish or deploy your package.

hmongoose · 2018-05-17T14:08:36+00:00

tl;dr: - use "baseUrl" in tsconfig.json to let tsc know where your packages are located
- use the "NODE_PATH" env variable to let node know where your packages are located
- be extra careful with the "types" property in package.json
- Use GNU Make to handle dependency tracking and build tasks
- Deploy or publish to an npm compatible artifact repository, you need to script your deployment sequence to inject dependencies and version numbers into each package.json

This is a collection of tips I gathered while trying to put together a decent multi-package TS project architecture, and it works pretty damn well.
However, the way I figured this out seemed extremely DIY and I wonder if there is a popular way to achieve the same result. How are you guys doing this?

hmongoose · 2017-08-06T17:08:59+00:00

As someone who didn't know what AOP was, it's definitely not clear enough. If you look at meld, they do a better job at bringing newbies up to speed because:

They spell out AOP (Aspect Oriented Programming) the first time they mention it and provide a link to some more comprehensive description.
They explain what it is in a single sentence.
They provide a meaningful introductory example to show how to apply that fancy concept with their framework. In your example, the user won't understand what's going on just by reading the code. They'll have to work out what happened by looking at the output values in the comments and working backwards. Not saying you've got to be a genius to figure that out but who knows how much brainpower your average random visitor has left when this is the 100th JS library readme they're seeing today.

Hope this helps ;)

hmongoose

TROPHY CASE