5 ms·
A way to think about that question is to ask whether typelessness in general is bad because a lot of the schemaless databases come from that side of the divide.
by foobiekr 8y ago
A way to think about that question is to ask whether typelessness in general is bad because a lot of the schemaless databases come from that side of the divide.
I’d personally answer yes, but that’s because I believe that typed, schema-generates structures should be pushed all the way from the database to the typescript code on the front end. Changes become something you can deal with with high confidence and things like typos, etc. become impossible. Relational structures enforced in the database (and imho sadly lacking in the intervening layers which is something I’d like to get the time to deal with; though the FoubdationDB record layer certainly has an interesting if unexploited take on it) is a natural extension of this.
But there’s a whole other world where people just don’t want to be tied to constraints. I suspect it’s a personality thing.
- mlevental 8y agohow do you do this? tie it all the way from the DB to the client? incidentally I believe this is the difference between being an engineer and being a product person. I straddle the line. in theory I want a strong type system so I can be confident about the future. in practice I don't want to pay the upfront cost and I'm more interested in shipping now and taking on debt.
- jacques_chester 8y agoWhat upfront cost?
- atombender 8y agoLook at GraphQL. It lets you enforce a single schema from the front end down to the data layer. In my company's product, we specify the data models as JSON Schema, and then generate the necessary language code -- we generate the GraphQL schema from it as well as Go data types, with some database glue. Our front end code is currently JavaScript, but we hope to migrate to TypeScript, which will make everything statically types all the way through. (gRPC fills a similar role, though the web story is lacking. gRPC is brilliant for APIs between backend services, but browser support is not there yet. GraphQL is more convenient for the app-facing layers.)
- mlevental 8y agohttps://github.com/grpc/grpc-web https://github.com/grpc/grpc-web
- atombender 8y agoYes, you can make it work. But you have to run this special shim or proxy, because browsers still don't all support HTTP/2, header trailers, etc. Hence "lacking".
- foobiekr 8y agoWe wrote it. Everything is derived from proto for us. Some of that is hand-written tooling, some is off the shelf. Mostly you have to be aware at design time of what this approach entails. Proto is not elegant and the data model and implementation (especially the very poor performance of maps in the Go implementation) can leave a lot to be desired, but it's a thing that pretty much supports everything. It has good enough performance without headaches. Lowest common denominator can be quite useful and so can constraints.
- int_19h 8y agoStrong typing and schemas are a bit different. They're often conflated, but once you start thinking about more complicated examples, this makes sense. Look at Clojure for a good example - it is strongly (but dynamically) typed, but then it also has schemas with automatic validation on top of it (Spec).
- vp8989 8y ago"I suspect it’s a personality thing." I do too. And also probably a lack of experience dealing with outages and remediation of mistakes. If it's always someone else's problem to clean up your mistakes then you can't appropriately appreciate how valuable it is that a machine can help you make less of them.