Akshaya Acharya

Besides the fact of its popularity, did using the TypeScript compiler have any other benefits? I've been thinking that it should be possible to encode many constraints in the type system. Does the system generate any types that describe the real current state of the system? Looks incredible :) like a declarative mash up of Terraform and Migration tooling. And it builds forms?

Are there any frameworks that get OpenAPI tooling right? What about Spring Boot that's statically typed? What about something in TypeScript? Can frameworks use types to 1. ensure response types match the OpenAPI spec 2. validate request types to match the spec?

Would love to hear more about why exposing database as graphql endpoint is bad! (I'm from Hasura). I'm going to add some reasons myself, but I'm looking to understand what your specific reasons are. // Performance 1. Unless your engineers are always writing hand optimized sql queries, there's always an impedance mismatch 2. The main deal with using any higher abstraction is the work it saves you i.e. works in most cases 3. There should always be an escape hatch to go down to hand optimized stuff anyway 4. Yes, graphql is different. Your graphql server should allow for things like timeouts, and query complexity based limits. 5. Hasura generates deterministic query plans // Existing microservices You can attach rpc to the graph with Hasura, though admittedly it's not that much fun. This is going to get way better in v3 though (declarative joins, serverless functions). // API contracts 1. API contract should not change when underlying implementation changes 2. With any technology, you have to write the compatibility layer 3. Graphql has a really good versioning story 4. Graphql is actually really good from a data integration pov because the server can require contracts of the underlying implementations, which means you can swap them out (like any data bus approach). // Authorisation 1. The concern is that it's too complex, but graphql model-level authz is actually cool 2. If you define authz at the table level, then you can write any arbitrary query and know that the graphql server enforces the permission rules 3. Which means you don't have to worry about locking down each api endpoint Data permissions belong next to the data. A way neater model in my mind. // It seems that some of these things are just different, not necessarily worse. And other things get way better. Please do let me know what you think.