Working efficiently with GraphQL-CodeGen types in TypeScript

In our project, we’re using GraphQL, and we’re using graphql-codegen to generate types for our queries. While this is very convenient, it’s almost impossible to extract sub-types from these generated types. Let me explain.


Dude … we have to talk about this (in JavaScript)

Recently I stumbled about this post about The complete elimination and eradication of JavaScript’s this.

To give you a TL;DR: The author states that almost no JavaScript developer understands this, that it is a terrible concept, and introduces a library that allows developers to avoid using this in many circumstances. So, we had a twitter discussion with pretty opposing standpoints: I think this in JavaScript is quite simple, versatile and really useful.

But in the next days, it got me thinking …


Of Love and Hate: TypeScript, Redux and immutable.js

I love Redux. It’s such an elegant and simple concept that solves so many problems. But like every other solution, adding new concepts to your code base can also introduce the occasional headache.

One of these headaches is that Redux does not enforce a lot of it’s conventions, but when you don’t adhere to them, things start breaking further down the road in strange ways.

Today, I’m going refer to one of Redux‘ three principles: State is read-only

React gets Context & Suspense. Quo vadis, Redux?

Disclaimer: this article targets developers that are using Redux with React. If you are using Redux with another Framework, this article might not be important for you.

Last thursday, Dan Abramov gave a talk on JSConf Iceland called „Beyond React 16“. A few hours later, featured an article titled RIP Redux: Dan Abramov announces future fetcher API. While I agree with almost nothing that article has to say about Redux, the article got one thing right: Somewhere between 6 or 12 months from now, the way we are using Redux (at least when starting a new project) will be drastically different from the way we are using it today.

But before we take a gaze into the crystal ball, let’s take a step back and see what happened.


Noch ein VPN? vagrant up!

These: Aufsetzen von VPNs für ein ganzes Team ist Zeit- und Geldverschwendung!

Aber von vorne:

Wenn wir ein Projekt für einen neuen Kunden starten, steht für uns ganz am Anfang der Zugriff auf dessen Infrastruktur.

Viele Kundeninterna (Jira, Confluence, Sharepoint, SQL-Server, Dateifreigaben) liegen im Netz des Kunden, und wir brauchen erst mal ein VPN, um aufs Netz des Kunden zugreifen zu können.

Hier wird es bunt gemischt: Einige Kunden setzen auf IPsec, wieder andere auf OpenVPN, Tinc oder ein halbes Dutzend herstellerspezifische Lösungen. Weiterlesen