6 ms·
I didn't read the post that way. I feel scaling is a small issue more so organization. Graphql does make sense for something like source hunt. Why not use type
by searchableguy 6y ago
I didn't read the post that way. I feel scaling is a small issue more so organization. Graphql does make sense for something like source hunt.
Why not use type hints in python? Isn't that a good enough substitute?
I wonder why go instead of rust if he wanted static typing, long term ease of maintanence and performance. Go's type system is not great especially for something like graphql. Gqlgen relies heavily on code generation. Last time I used it, I ran into so many issues. I ditched go together after several painful clashes with it that community always responded with: oh you don't need this.
(yeah except they implemented all those parts in arguably worse ways and ditched community solutions in the next few years)
One major benefit the GP fails to mention is that with graphql, it is easy to generate types for frontend. This makes your frontend far more sane. It's also way easier to test graphql since there are tools to automatically generate queries for performance testing unlike rest.
There is no need to add something for docs or interactivity like swagger.
- CameronNemo 6y ago>One major benefit the GP fails to mention is that with graphql, it is easy to generate types for frontend. This makes your frontend far more sane. By GP (grandparent?) do you mean the article / blog post? Because if so I see no indication that Drew plans to adopt a SPA architecture -- he seems intent on continuing to use server side rendering with little javascript, which would make "frontend types" sort of irrelevant.
- searchableguy 6y agoYou don't need spa to take benefits of the generated types from graphql. If you use something like typescript on the backend (SSR app), the types will be stripped out in the end so it doesn't affect your bundle size.
- CameronNemo 6y agoYou must understand my confusion when your original comment explicitly states that frontend types can be generated, but your reply here seems to be talking about a javascript/typescript backend service.
- searchableguy 6y agoSorry by backend, I mean your SSR app.
- vertex-four 6y agoWhat bundle size? There's no javascript being shipped to the client.
- gbear605 6y agoTechnically there is some used for a few things, like a text editor (for writing build manifests) and for payments. But those are very limited and aren’t relevant to the use of GraphQL.
- TeeWEE 6y agoCode generation (of types and clinet/server stubs) can be done with any IDL (interface definition language). OpenAPI, GRPC, Thrift etc etc all support it. No reason to choose GraphQL only because of this. The power in GraphQL comes from the graph and flexibility in fetching what you need. Usefull in general purpose APIs (like GitHub has).
- searchableguy 6y agoI never said it was the only reason. I said it is one of the benefits that GP failed to mention in the post. Other benefits that GP mentioned still applies. You can of course do this with other standards but ime, it's easier to do this with graphql since you only have to build the api. There is less overhead overall since type information is part of the standard, not necessarily something people add afterwards or choose to. Introspection, graphiql and all the tooling is easier to use and doesn't need integrating something like swagger. It comes setup by default on most solid graphql frameworks.
- erk__ 6y agoAs for the reason to use Go instead of Rust it is probably just down to the creator of Sourcehut he has multiple times expressed that he dislikes rust quite a bit. He has written a blog post about how he chooses programming languages as well https://drewdevault.com/2019/09/08/Enough-to-decide.html https://drewdevault.com/2019/09/08/Enough-to-decide.html
- Kuinox 6y agoIt's the first time I hear that haskell has awful package management...