News for hackers. Stuff that matters.
Re:ExpressJS vs. Actix-Web: performance and running cost com... by hn_throwaway_99 on Sunday March 01, 2020 @11:12AM (#22457449)
A common language across front and backend systems is a huge benefit. I find it extremely productive to have a backend in Typescript on NodeJS, and a frontend in ReactJS, talking over a GraphQL layer where I'm autogenerating Typescript types from the GraphQL typedefs. Means I can share many libraries and tooling across the front and back ends, but most importantly it means devs feel much more comfortable digging into code on the other side. If a front end dev has an issue with a backend API call, he can just pull down the code and instantly inspect it and submit a PR of necessary without feeling "out of his element".
Re:ExpressJS vs. Actix-Web: performance and running cost com... by ttty on Sunday March 01, 2020 @11:14AM (#22457454)
How you generate the types from graphql. I noticed most of the generators create types with all optional keys. Do basically you need to check all the time...
Re:ExpressJS vs. Actix-Web: performance and running cost com... by hn_throwaway_99 on Sunday March 01, 2020 @11:19AM (#22457488)
If they're creating types with optional keys it's probably because that's how you're defining your types in GraphQL. E.g. with

type Foo { bar: String }

bar would be optional in the Typescript type because it's specified as optional in the GraphQL type. You would need to do the following to make it required:

type Foo { bar: String! }

Re:ExpressJS vs. Actix-Web: performance and running cost com... by ttty on Tuesday March 03, 2020 @09:24PM (#22480691)
I mean... All keys can be optimal in reality, but in real world you can't put all non optional because defeats the purpose of graphql.