Here is another TypeScript library for validating types of SQL queries: https://github.com/MedFlyt/mfsqlchecker

It uses the actual PostgreSQL parser against your project's database schema to give 100% accurate results. Guarantees that all of your queries are valid, and that all input and output types are correct (and will also auto-generate/quickfix the output types for you in VSCode)

Hah a few months back I released https://github.com/ivank/potygen

Similar idea - statically typing queries. Mine was mostly me playing around with recursive decent parsers seeing if I can actually parse SQL with it, and it seems to work OK, at least for Postgres.

It does require a "build" pass to generate the types, but I've added some additional bells and whistles like auto formatters and on hover info about columns / views / tables etc. Once you have the sql AST its pretty easy to build a lot of cool stuff around it.

It's all pure TS and doesn't use parser generators like ANTLR. We've been using it in prod for a while now and seem to be working alright - its mostly types anyway, but does have a runtime component, since sql parameters in node Postgres are too basic for our use case.

It all started from the amazing https://github.com/dmaevsky/rd-parse which showed me that you could build crazy complex parsers with like 100-200 lines of code.

PgTyped is another high quality alternative: https://github.com/adelsz/pgtyped.

Looks like a great start.

My own library Zapatos[1] is less ambitious (it doesn't try to parse raw SQL) but has similar goals. It also has no truck with runtime types.

[1] https://jawj.github.io/zapatos/

author of ts-sql[0] here, this looks great (and a way more practical approach!)

[0] https://github.com/codemix/ts-sql

This is very slick!

> Time will tell if it's feasible to also type-check mutating queries.

What do you mean by "mutating queries"? When the underlying schema changes? For instance when a new column is added to the `video` table, or if `video.id` changes to a varchar?

Haven't dived in deep enough yet, but is this using the DB engine's explain query, or I guess my question is how does it interrogate the underlying db/schema if the schema isn't supplied as code in the setup? Or at least, how would you envision all that happening?

Wow, I was literally thinking about this like a week ago, wondering how viable it would be. This is great work. The ability to compile ANTLR to TypeScript types would potentially be a game-changer.

Great to see a new option in the TypeScript ecosystem. A fully featured framework. Brilliant. Could be a great alternative to Adonis.js which is one of my favourite nowadays: https://adonisjs.com/

TypeScript's type system can be very powerful and flexible - creating types at build time in a manner of speaking. Here's an article I wrote on an aspect of this called mapped types. You can see how types can be composed of other types.

https://www.lloydatkinson.net/posts/2022/going-further-with-...

> MongoDB ORM. It's a fine database, but it's also proxy indicator of web developers who only breath JavaScript.

Yet the author appears to be writing the parser in C++: https://mobile.twitter.com/MarcJSchmidt/status/1534323199147...

> considering information the dozen listed libraries don't have documentation.

I don’t think this is a “Show HN” or “Launch HN” posting. It’s possible the author is still working on code and docs, and has no idea the site’s been posted here.

It’s an in-progress project. Regarding topsort, my guess is the algorithm was useful for some part of the project, and the author decided to make it available generally.

> Don't you think Google has the resources and the incentive to make gRPC faster?

You’d think that, but A) Gmail, and B) having worked for a Google competitor, I can assure you a passionate developer can write more performant code than what a massive corporation will generally produce.

> I would heed caution at trying to solve every problem all at once.

Agreed, but I hope the author throws caution to the wind. I’m tired of having either A) 1 million npm dependencies or B) boiling the ocean in my own projects, so it’d be nice to have a batteries included project you can rely on.

Yes, it covers a lot. But that is in my eyes necessary to provide high performance throughout the whole application and is necessary to offer something that is fundamental unique. It's a matter of providing very fast basic building blocks to get that. For example, you can not make ORMs faster without first having a very fast deserialiser, or a fast RPC implementation without having very fast binary validation and encoding. So, it all works together, is decoupled and split up in multiple packages so they can be used separately.

A lot of stuff is not yet documented, but they will. We are already writing new documentation/book which is roughly 40% done that covers already a lot more than what is currently seen on the website, but this HN post was posted at a somewhat bad timing.

> - its claimed their RPC implementation is 8x faster than gRPC, specifically gRPC-js. Don't you think Google has the resources and the incentive to make gRPC faster? It's likely this is not an apples-to-apples benchmark.

Yes, gRPC is fast. But not gRPC-js. I invite you to test it yourself, all our benchmarks are in the git repository. It is explained here on how to run them: https://deepkit.io/documentation/benchmark. Feel free to join our discord so I can guide you through the process. On the reasons why gRPC-js is slower: It uses Proto Buffers which is binary, and parsing binary is notoriously slow in JavaScript. By utilising the runtime type information of TypeScript we can generate JIT binary encoder/decoder for very specific types which are much faster.

> - why is a very specific sorting algorithm bundled in?

Why is providing something as a dedicated package a red flag? It's fundamental necessary for an UoW ORM for example and itself very useful. My other topsort package in PHP has 4 million installations, so it's only logical to bring the same functionality to TypeScript.

> Message broker. Very opaque, but it's likely this is coupled to a very specific pubsub provider.

It uses its own server, but will probably be replaced soon. Again, somewhat bad timing of that post.

> - API console for testing HTTP calls. This is a solved problems with tools for testing APIs like Postman

It doesn't solve what Postman solves. It's a way to automatically document your HTTP and RPC API plus allows to execute/try them right in the browser. There is Swagger UI which comes closer to what API Console is.

> - For the view layer, it seems hard-coded to Angular

There is actually no view layer. It has a server-side DI-enabled template engine based on JSX and a desktop UI kit (which is based on Angular). Both have their own use-case and are not required.

I never understood the "single developer" argument. React itself does not even have more than 5 active developers (https://github.com/facebook/react/graphs/contributors), Vue literally have a single one (https://github.com/vuejs/vue/graphs/contributors). You can apply this to almost any library. I mean, what's that argument for?

One man's cobbling together is a another's choosing the best library for the job ;)

thank you so much!

They do have the option to just pick and [choose from a variety of libraries](https://deepkit.io/library). I like the look of @deepkit/type

That is a non-goal. One of the biggest advantages of Deepkit and its runtime type feature is that you can reuse TypeScript types throughout your whole application stack. This does not work with Fastify and Prisma. Let me give you an example.

Let's say you build a little user management app and need a `User` type. So you define one:

  interface User {
    id: number;
    username: string;
    created: Date;
    email: string;
  }

If you want to build a REST API that returns that user, you can just do that:

  router.get('/user/:id', (id: number & Positive): User => {
    //...
  });

Deepkit automatically serialises the object into JSON using the type information in `User`.

You want to accept a User object for creating a user in the database? No problem:

  router.post('/user', (user: User): User => {
    //...
  });

You probably want to enrich the interface with additional constraints:

  interface User {
    id: integer & Positive;
    username: string & MinLength<3> & MaxLength<32>;
    created: Date;
    email: Email;
  }

And with that the framework automatically validates all incoming requests against the User object and its containing validation constraints. It also deserialises it automatically from JSON for example. If the `User` is a class, it instantiates a class instance.

But you don't want to require all fields, like id and created should be set by the server:

  router.post('/user', (user: Omit<User, 'id' |'created'>): User => {
    //...
  });

This works equally well. And the best part: you get API documentation for free with the Deepkit API Console, just like you know from Swagger UI.

Ok, but we need to save the User in our database, right? We do not need to duplicate the User in yet another language like with Prisma. Just re-use the User interface and annotate the fields.

  interface User {
    id: integer & PrimaryKey & AutoIncrement;
    username: string & MinLength<3> & MaxLength<32> & Unique;
    created: Date;
    email: Email & Unique;
  }

We still use the very same interface, but have added additional meta-data so you can use that exact same type now also for the ORM.

  router.get('/user/:id', async (id: number & Positive, db: Database): Promise<User> => {
    return await db.query<User>().filter({id}).findOne();
  });

Next, let's go to the frontend. We obviously have to request the data from our rest API. We can just do that and reuse the `User` interface once again.

  const userJson = await fetch('/user/2');
  const user = cast<User>(userJson);

`cast` automatically validates and deserialises the received JSON. We import `User` wherever needed and this works because the meta-data is not tightly coupled to any library, so you won't pull in for example ORM code just because you use database meta-data. You can literally use TypeScript's powerful type-system to your full advantage in many small to super complex use-cases and let the framework handle all the validation, serialisation, and database stuff.

And like that you are able to reuse types everywhere: From database to http router, configuration, RPC, API documentation, dependency injection, message broker, frontend, and more. That's not possible in this form in any other framework or when you combine lots of third-party libraries and glue them manually together.

Deepkit separated the functionality in libraries which would allow you to use their features in Fastify and Prisma, too, but that would mean you lose one of the biggest advantage of all: Reusing types.

    sig UserDatabase(user, db)

    create: UserDatabase =>
      db.write(“users”, user)

    update: UserDatabase =>
      db.get(“users”, user.id).update(user)