6 ms·

I may plea the fifth, i.e. I'm not sure what this entails but would love to hear more. Also feel free to file a feature request. Naively, I would argue that be

I may plea the fifth, i.e. I'm not sure what this entails but would love to hear more. Also feel free to file a feature request. Naively, I would argue that being idiomatic in the respective ecosystem is more important than perfect consistency. Only few users will likely use 2 or more languages and probably even then there's a balance to be struck.

bigiain 2y ago
Pretty sure you'll want to consider usage by teams writing in all of Swift, Java, and Javascript as relatively common. You're likely to encounter people doing "fringe" stuff like transpiling Go or Rust into Wasm, but those folk are all most likely capable of dealing with idiomatic impedance mismatches themselves.
- trailbase 2y ago
  Absolutely. In terms of new clients targeting mobile teams Swift and Java/Kotlin would make the most sense. I mostly meant that even folks who code in Swift, Java and JS, would likely prefer the respective clients to be idiomatic than the APIs exactly matching each other.
Guillaume86 2y ago
I agree I would generally prefer clients to be idiomatic for the target language but in the case of LINQ providers I understand not doing them since they are quite involved to implement. You can probably leverage something like https://linq2db.github.io/ https://linq2db.github.io/ and replace some parts of their SQLite provider with HTTP calls to avoid coding most complicated parts. This would be for the raw sql API, for the records API I'm not sure LINQ makes sense since from what I saw in the docs it would be a pretty small subset of LINQ anyway. An easy way to generate the model classes from the DB schema would be nice too (a source generator accessing the schema via some endpoint?). Edit: it's nice seeing C# getting some love early in a project, I'm used to fallback to js/ts to try the new stuff :)
- trailbase 2y ago
  The raw query API is an admin-only API at least for now, since SQLite doesn't have a built-in concept of row-level security. From a client's perspective it's only RESTful APIs at the moment. That said, you absolutely can generate code from the DB schema already. There are `/examples` (just none in C# yet). I'm optimistic that C# will become increasingly important with respect to cross-platform mobile/desktop development and thus receive higher priority treatment in general.

bigiain 2y ago

Pretty sure you'll want to consider usage by teams writing in all of Swift, Java, and Javascript as relatively common. You're likely to encounter people doing "fringe" stuff like transpiling Go or Rust into Wasm, but those folk are all most likely capable of dealing with idiomatic impedance mismatches themselves.

trailbase 2y ago
Absolutely. In terms of new clients targeting mobile teams Swift and Java/Kotlin would make the most sense. I mostly meant that even folks who code in Swift, Java and JS, would likely prefer the respective clients to be idiomatic than the APIs exactly matching each other.

Guillaume86 2y ago

I agree I would generally prefer clients to be idiomatic for the target language but in the case of LINQ providers I understand not doing them since they are quite involved to implement. You can probably leverage something like https://linq2db.github.io/ https://linq2db.github.io/ and replace some parts of their SQLite provider with HTTP calls to avoid coding most complicated parts. This would be for the raw sql API, for the records API I'm not sure LINQ makes sense since from what I saw in the docs it would be a pretty small subset of LINQ anyway. An easy way to generate the model classes from the DB schema would be nice too (a source generator accessing the schema via some endpoint?). Edit: it's nice seeing C# getting some love early in a project, I'm used to fallback to js/ts to try the new stuff :)

trailbase 2y ago
The raw query API is an admin-only API at least for now, since SQLite doesn't have a built-in concept of row-level security. From a client's perspective it's only RESTful APIs at the moment. That said, you absolutely can generate code from the DB schema already. There are `/examples` (just none in C# yet). I'm optimistic that C# will become increasingly important with respect to cross-platform mobile/desktop development and thus receive higher priority treatment in general.