3 ms·

While I'm very excited about the emergence of type checking in "modern" web development the triad of GraphQL / Typescript Types / JSON-Schema is a real cluster

While I'm very excited about the emergence of type checking in "modern" web development the triad of GraphQL / Typescript Types / JSON-Schema is a real cluster and I hope we engineer ourselves beyond a solution that requires endlessly translating between them in the next few years. After having iterated through a bunch of permutations of Rust frameworks, Typescript frameworks and ORMs here is a stack that I'm particularly excited about (that mirrors this article a fair bit): - Design a Postgres database in whatever means you prefer (I prefer SQL, since it's easy to design constraints in using the full power of the DB engine). - Use Postgraphile to auto-derive a CRUD GraphQL Schema for your database (this is similar to Hasura, but encourages using Postgres row-level security if you need fine grained access control). - (Also) Use pgTyped for extensions to Postgraphile's schema when you want to implement mutations outside of DB functions. - Use Apollo GraphQL Codegen in your front-end to auto-generate types for your GraphQL Queries. The net effect of this is you get full type safety and your DB Schema is your singular source of truth (Note that I'm not auto-generating forms from JSON-Schema like this post, but this isn't necessary for our particular use case).

breytex 5y ago
I like to start with code. If you use typeorm and type-graphql you can write a Type once and generate the database as well as the resolvers out of it. You can then even import the same type in frontend (as part of a mono repo). This stack does not need any generation routine for types. You just have to generate a migration if the postgres target schema changes, but that's normal and I don't see a way around this for the future.
- newhouseb 5y ago
  SQL is code too :), but I follow your point. Typeorm looks nice, but I need polymorphism for some of our "business" logic and have pretty specific requirements about how I want correctness enforced that typeorm doesn't appear to support (but raw SQL does).
  - pkilgore 5y ago
    Typeorm does not scale to large datasets. Real nice for MVPs. Just a warning. Hydration times explode for lists and joins that postgres barely registers on the query side, and hydration is blocking.
AmericanChopper 5y ago
The way I see it, we got here by abandoning OOP for web development. There’s a lot of reasons that MEAN, NoSQL, no-schema… is so appealing, because OOP is so tedious. But we’ve just been slowly recreating OOP in a piecemeal fashion, with ORMs, TypeScript, JSON Schema, GraphQL… because the new approach didn’t actually provide an alternative solution to the problems that OOP attempts to address, it was just based on the premise that you could ignore them. I don’t think we’re that far away from coming full circle back to OOP, even if the “framework” ends up having a different name.
- newhouseb 5y ago
  I'm not sure I follow, what is the "OOP" solution as you imagine it here (that all these technologies are alternative to)?
  - AmericanChopper 5y ago
    The OOP approach is to define your entire data model as a collection of classes and interfaces before you write a line of business logic. This approach is designed to support a systemic methodology for modifying and extending the codebase. But it also adds a complexity that requires large quantities of boilerplate to be written, and requires maintainers to navigate through several layers of abstraction if they’re trying to read or modify the code. From my perspective, I see the rise of Node and Python for web dev as a rejection of OOP, largely on the basis that web apps don’t need such a complicated set of structural abstractions. However if you look at how that domain has been innovating, my argument is that they’ve simply recreated all of the old OOP abstractions with different names. If you look at the types of abstractions used, and their associated complexity, in a typical GraphQL + TypeScript application, how are they substantially different from full OOP C# app for example? Especially if you’re using an RDBMS, or ORM, or some sort of schema for a NoSQL DB. For devs that don’t like TypeScript, JSON Schema might be appealing. But if you look at the JSON Schema spec on GitHub, one issue you see repeatedly raised is “please add full inheritance”, followed by a debate around “but that’s just OOP”. The community’s raised that issue so many times that I think they’re actually considering it now.

breytex 5y ago

I like to start with code. If you use typeorm and type-graphql you can write a Type once and generate the database as well as the resolvers out of it. You can then even import the same type in frontend (as part of a mono repo). This stack does not need any generation routine for types. You just have to generate a migration if the postgres target schema changes, but that's normal and I don't see a way around this for the future.

newhouseb 5y ago
SQL is code too :), but I follow your point. Typeorm looks nice, but I need polymorphism for some of our "business" logic and have pretty specific requirements about how I want correctness enforced that typeorm doesn't appear to support (but raw SQL does).
- pkilgore 5y ago
  Typeorm does not scale to large datasets. Real nice for MVPs. Just a warning. Hydration times explode for lists and joins that postgres barely registers on the query side, and hydration is blocking.

AmericanChopper 5y ago

The way I see it, we got here by abandoning OOP for web development. There’s a lot of reasons that MEAN, NoSQL, no-schema… is so appealing, because OOP is so tedious. But we’ve just been slowly recreating OOP in a piecemeal fashion, with ORMs, TypeScript, JSON Schema, GraphQL… because the new approach didn’t actually provide an alternative solution to the problems that OOP attempts to address, it was just based on the premise that you could ignore them. I don’t think we’re that far away from coming full circle back to OOP, even if the “framework” ends up having a different name.

newhouseb 5y ago
I'm not sure I follow, what is the "OOP" solution as you imagine it here (that all these technologies are alternative to)?
- AmericanChopper 5y ago
  The OOP approach is to define your entire data model as a collection of classes and interfaces before you write a line of business logic. This approach is designed to support a systemic methodology for modifying and extending the codebase. But it also adds a complexity that requires large quantities of boilerplate to be written, and requires maintainers to navigate through several layers of abstraction if they’re trying to read or modify the code. From my perspective, I see the rise of Node and Python for web dev as a rejection of OOP, largely on the basis that web apps don’t need such a complicated set of structural abstractions. However if you look at how that domain has been innovating, my argument is that they’ve simply recreated all of the old OOP abstractions with different names. If you look at the types of abstractions used, and their associated complexity, in a typical GraphQL + TypeScript application, how are they substantially different from full OOP C# app for example? Especially if you’re using an RDBMS, or ORM, or some sort of schema for a NoSQL DB. For devs that don’t like TypeScript, JSON Schema might be appealing. But if you look at the JSON Schema spec on GitHub, one issue you see repeatedly raised is “please add full inheritance”, followed by a debate around “but that’s just OOP”. The community’s raised that issue so many times that I think they’re actually considering it now.