Hey everyone, host of the localfirst.fm podcast here (and previously founder of Prisma).
In collaboration with Jess Martin, we've been working on the Local-First Landscape resources which provides an overview and comparison of various local-first technologies. It's meant to provide orientation to people new to local-first app development.
We hope this is useful and welcome any form of feedback and suggestions! Thank you!
Hi folks, I'm the user from the screenshot above (thanks for sharing this btw).
I have to say, this was a quite unpleasant and unwelcoming interaction as my question was genuine and I indeed did do some extensive research before asking this question in Discord.
As a devtools founder myself (co-founded www.prisma.io) I highly value welcoming and helpful communities and offered my help to the people behind the Tauri project to turn it into a more welcoming community. I hope they are open to it since I actually really enjoy using Tauri as a project.
Denjell here from the founding team of Tauri. Thanks for reaching out directly, and I just wanted to state for the HN record, that we are going to be having a board discussion surrounding the unpleasant event raised here, and will make a public statement very soon.
That said, on a personal note, I am quite sorry this happened. We do support and uphold our Code of Conduct, and this is not an appropriate response and the community tone we want to nurture.
I'm excited to hear you're looking into this and take it serious. I think this is a great opportunity to for the Tauri community to become a more welcoming and inclusive place. Happy to help!
I disagree. Some points are really valid. It adds complexity to your system, especially at the server. It is a costs/benefits thing, not only benefits. The benefits are minimal for simple CRUD-like applications.
Co-creator of How to GraphQL here. I’m very excited to tell you that we’re currently working on a new iteration of the page and content that will include more in-depth chapters about dataloaders, authentication, authorization and other advanced topics.
Would be great to hear more thoughts on which topics you’d like to see covered.
For me to even start thinking about GraphQL instead of REST, there needs to exist Java, .NET and C++ mature libraries for GraphQL at the same level of available REST ones.
Using JavaScript ones is not an option. So that is the kind of thing I would care about.
I would add Python and Go to that set of required, mature server-side libraries.
If there's solid libraries for each of the common languages used to write serverless code, then I think that'd be a big plus for decision makers who are on the fence about adopting GraphQL
I've yet to go beyond a cursory skim of graphql - but my first impression is that in the end you get to write your very own query planner/optimizer - with the "benefit" of optimizing across wildly different data stores like unifying a few different sql databases, a few filsystem graph/hierarchies of meta-data and a handful of semi-structured document stores in the form of json/soap services... So a lot harder than the already pretty hard problem of writing a query planner for "just" an rdms.
But I think there's something "there" - graph dbs, datomic, web prolog - they all seem to point to clients asking a "what" with the server figuring out the "how" [ed: and not in the least: whence (from where)] .
GraphQL is finally an API standard that strikes the right balance between simplicity and flexibility and has the potential to be the only query language most developers have to learn – and could therefore fulfil the idea of ODBC.
In regards to other SQL databases, we're currently working on a GraphQL database proxy that turns your database into a GraphQL API. We're starting with MySQL but have other databases like PostgraphQL, SQL Server, Oracle, DynamoDB on the way.
Yes, this simply runs in the same Node.js process (or any other programming language really) and doesn't add any complexity. Under the hood it's simply delegating your GraphQL queries to another GraphQL API (e.g. PostGraphile or Graphcool) – think of this as a smart HTTP request forwarder.
In terms of the API you're using, you can either use a "dynamic" GraphQL binding which uses method introspection (e.g. via JS proxies) or a generated "static" GraphQL binding which maps the GraphQL type system to your programming language. This way you can catch errors at build/compile time and get auto-completion functionality like in GraphiQL/Playground.
In collaboration with Jess Martin, we've been working on the Local-First Landscape resources which provides an overview and comparison of various local-first technologies. It's meant to provide orientation to people new to local-first app development.
We hope this is useful and welcome any form of feedback and suggestions! Thank you!