How porting to TypeScript solved our API woes

&gt; That means that when one side of the API changes, the other side won&#x27;t even compile until it&#x27;s updated to match.<p>Coupling your front end and back end in this way can give you false confidence in making API changes. If you control both sides of the API on a web app that doesn&#x27;t have too many users yet, then this can be very productive, but consider this situation:<p>You&#x27;ve made a breaking API change on the back end, and thanks to your type system, you make the corresponding front end changes as well, which is great. You deploy your code, and the back end changes take effect immediately. Visitors who were in the middle of a session are still running the old front end code, and their requests start failing. Cached copies of the front end start failing too.<p>You can engineer around this but it&#x27;s better to have a system that doesn&#x27;t make introducing breaking API changes too easy. It should be painful.

Note that Stripe is working on a type checker for Ruby: <a href="https:&#x2F;&#x2F;sorbet.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sorbet.org&#x2F;</a><p>I second the sentiment though. I wouldn&#x27;t choose to use plain JavaScript over TypeScript for any significant project.<p>You might ask why I wouldn&#x27;t just use a more fully typed language like Java. My main response is that I love having the flexibility to choose how strict the types should be. Sometimes, typing something out fully is not worth the trouble. Having escape hatches lets me make that choice. While I enjoy using types to turn runtime bugs into compile time errors as much as possible, it&#x27;s not the right thing to do 100% of the time.

If you control both ends of an API, there&#x27;s no reason not to use Thrift or equivalent (gRPC) rather than untyped JS. Even if you don&#x27;t believe in typing in general, an API boundary is exactly where it&#x27;s most important to make sure both sides agree on what the interface is.

Do I read the chart correctly and their whole Codebase (minus dependencies) is less the 15k lines of code? Porting 6.5k likes of ruby in 2 weeks sounds reasonable, but how doing migrations 10x or 100x that size is far more challenging.

TypeScript has been on HN for different reasons over the last few days. The main thing that has stood out, from the flame wars erupting over it is that it is a truly divisive idea. To some, it gives the same securities and checks provided when working with a statically typed language. To others, it curtails the power and expressiveness inherent in JS, the dynamic, functional language it compiles down to.<p>TypeScript does provide a lot of benefits, but for it to truly succeed and take over in the JS world would mean it has to truly also reflect, and enable JS&#x27;s functional and dynamic roots. JS got where it is by being JS.. an extremely flexible and accommodating language. HTML got this far today by doing the same, just google XHTML if you doubt that. So for TypeScript to succeed where CoffeeScript failed, this may be the direction it needs to lean more towards: being less divisive, and inviting all kinds of programming paradigms to the party.<p>That, after-all is how JS succeeded.

How times are changing. The person who is famous for his amazing Ruby&#x2F;Rails screencasts rewrote his Ruby backend to TS...

Wow porting the entire backend in two weeks is impressive. I guess he knew the domain well and both languages well but I&#x27;m impressed.

How does one deal with remote data in typescript? I really like typescript, but not having any guarantees on the returned data is kind of frustrating.

this is <i>ruby</i> -&gt; TS<p>was expecting JS -&gt; TS

But Ruby is so much more fun that JS or TypeScript.<p>&#x2F;opinion

I watched them go through this process via twitter, and it sounded like inventing that shared api model was a type puzzle i wouldn&#x27;t be able to figure out myself. also they&#x27;re the only people i know of doing it?

Did it not occur to them to, I don&#x27;t know, &quot;test&quot; the API when they make changes? A compiler or stricter type system may help prevent certain careless errors, but not all (or even most) of them, while a proper test scheme will catch all such errors.

Swift on the Server!

Porting to a typed language helped prevent type errors in a typeless language. Who woulda thunk?<p>I am currently also working on a project written in a JS backend that&#x27;s slowly porting to TS, for the same reasons, but I still would prefer to go back to C# and take it a level further. I just don&#x27;t enjoy the TypeScript language all that much.

I can&#x27;t imagine not using class-transformer[0] or class-validator[1] in any TypeScript project that deals with external&#x2F;third-party APIs, remote or not.<p>[0] <a href="https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;class-transformer" rel="nofollow">https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;class-transformer</a> [1] <a href="https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;class-validator" rel="nofollow">https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;class-validator</a>

The title is misleading because TypeScript does not implicitly do any kind of runtime type checking on data which was sent by remote clients - If the client and server both happen to be written in TypeScript by the same team, the TypeScript type system can give those developers false confidence that the API endpoints on their server enforces runtime type validation on remote user input (I&#x27;ve seen this too many times), but it does not.<p>To implement API endpoints correctly in TypeScript, you&#x27;re supposed to assume that the arguments sent by the remote client are of &#x27;unknown&#x27; type and then you need to do some explicit schema validation followed by explicit type casting. Some TypeScript libraries can make this easier but it&#x27;s misleading to say that this is a native feature of TypeScript; in fact, it is no different from doing explicit schema validation with JavaScript (there are also libraries to do this). You should always validate remote user input regardless of what programming language you use.<p>Merely getting the compile-time static type checker to shut up because the types in your client code match the types in your server code is not good enough unfortunately - In fact, it may conceal real issues by giving developers false confidence that runtime type validation is happening when in fact it is not. A hacker could write a client in a different language and intentionally send incorrect input to crash your server unless your server explicitly validates the schema.<p>The reality is that there is no guaranteed type continuity&#x2F;consistency between the client and the server. Any tool which gives the illusion that there is any kind of continuity is deceptive by design.<p>This is why I like plain JavaScript; it requires real discipline and it doesn&#x27;t give any sense of false confidence. Developers should always be on their toes. The only way to improve code quality and security is by exercising more caution, not using more tooling.<p>The benefit pointed out by the author of this article is in fact one of the few genuine gaps in TypeScript&#x27;s type safety capabilities. Praising TypeScript for this fictitious feature is only going to give developers false confidence that TS somehow takes care of input validation for them and this is going to lead them to getting hacked.