Might I suggest taking a look at FastAPI?
It’s been a 10x+ improvement on Flask, in my experience.
How and why GraphQL will influence the Sourcehut alpha
71–80 of 232 posts
Re: How and why GraphQL will influence the Sourcehut alpha
#72Re: How and why GraphQL will influence the Sourcehut alpha
#73Where are the GraphQL lessons learned? The author hasn't even implemented a solution with it yet, but that hasn't stopped him from declaring it to the world. I don't find an announcement useful.
Maybe GraphQL adopters aren't sharing their experiences with it in production because they're realizing its faults? People are quick to announce successes and very reluctant to own, let alone share, costly mistakes. Also, people change jobs so often that those who influence a roll-out won't even be around long enough for the post-mortem. GraphQL publicity is consequently positively biased. If the HN community were to follow up with posters who announced their use of GraphQL the last two years, maybe we can find out how things are going?
Re: How and why GraphQL will influence the Sourcehut alpha
#74Tbh I'd expected a little better than framing this question in a "REST vs GraphQL" discussion coming from sourcehut.org. If you control your backend, you can aggregate whatever payloads you please into a single HTTP response, and don't have to subscribe to a (naive) "RESTful" way where you have network roundtrips for every single "resource", a practice criticized by Roy Fielding (who coined the term "REST") himself a…
If you don't like REST, don't use it. Whatever you do, don't even think that GraphQL will solve your problems. You were on the right track staying away from it till now. I can't also advise enough to stay away from a typed language (Go in this case) serving data in a different typed language (gql). You will eventually be pulling your hair out jumping through hoops matching types. After my last web project that requir…
> stimulus (https://stimulusjs.org/).
And here I thought Basecamp was still 100% rails. Interesting to see that they're also developing backend JS frameworks.
Re: How and why GraphQL will influence the Sourcehut alpha
#75So I've now had the opportunity to use both GraphQL and protocol buffers ("protobufs" is the more typical term) professionally and I have some thoughts on this. 1. Protobufs use integer IDs for fields. GraphQL uses string names. IMHO this is a clear win for protobufs. Changing the name of a field of GraphQL is essentially impossible. Once a name is there it's there forever (eg mobile client versions are out there for…
> People who talk about auto-generating GraphQL wrappers for Postgres database schemas (not the author of this post, to be clear, but it's common enough) are missing the point entirely. The whole point of GraphQL is to span heterogeneous and independent data sources;
I don't think they are missing a point; rather, they have a completely different point: eschew a backend and use GraphQL on a DB + a frontend that gets all that data. If you're developing rapidly and don't have complex backend logic, I can see why you'd want to do that.
Re: How and why GraphQL will influence the Sourcehut alpha
#76Earlier quoted context omitted.
Why? I am currently converting a Flask/SQLAlchemy application to Go and gRPC. Go has not been that much of a win from my perspective. Lots of rough edges and missing functionality in libraries available, a lackluster type system that does enough to get in the way but not enough to properly express programmatic intention, and an atypical non-ideal error handling model have left me with little reason to champion Go. No…
Had a similar experience. Typed languages are great for systems development, and I think, not so good for writing web applications. I also think, Ruby, Python, JS have dominated web dev world largely cause they don't come in the way of the developer having to constantly convert HTML (untyped) and JS (untyped)into types for the backend programming language. Remember how ActiveRecord (not sure about SQLAlchemy) simply…
ActiveRecord is parsing those types, you just don't do it explicitly. IME, a dynamic language may not get in your way when you need to go between JS and the backend, but it also certainly won't get in your way when you're about to shoot yourself in the foot in a large-ish project with errors that could've been caught at compile.
Re: How and why GraphQL will influence the Sourcehut alpha
#77The author says that he has soured on Python for “serious, large projects”. While it’s clearly personal opinion, and that’s fair enough , I can’t help but think his choice of framework hasn’t helped him and has likely caused significant slowdown when delivering features.
Looking through some of the code for Sourcehut, there’s an insane amount of boilerplate or otherwise redundant code[1]. The shared code library is a mini-framework, with custom email and validation components[2][3]. In the ‘main’ project we can see the views that power mailing lists and projects[4][5].
I’m totally biased, but I can’t help but think “why Flask, and why not Django” after seeing all of this. Most of the repeated view boilerplate would have gone ([1] could be like 20 lines), the author could have used Django rest framework to get a quality API with not much work (rather than building it yourself[6]) and the pluggable apps at the core of Django seem a perfect fit.
I see this all the time with flasks projects. They start off small and light, and as long as they stay that way then Flask is a great choice. But they often don’t, and as the grow in complexity you end up re-inventing a framework like Django but worse whilst getting fatigued by “Python” being bad.
1. https://git.sr.ht/~sircmpwn/paste.sr.ht/tree/master/pastesrh...
2. https://git.sr.ht/~sircmpwn/core.sr.ht/tree/master/srht/emai...
3. https://git.sr.ht/~sircmpwn/core.sr.ht/tree/master/srht/vali...
4. https://git.sr.ht/~sircmpwn/hub.sr.ht/tree/master/hubsrht/bl...
5. https://git.sr.ht/~sircmpwn/hub.sr.ht/tree/master/hubsrht/bl...
6. https://git.sr.ht/~sircmpwn/paste.sr.ht/tree/master/pastesrh...
Re: How and why GraphQL will influence the Sourcehut alpha
#78In my experience GraphQL can be much nicer to implement than REST, and it offers a good structure around things that many REST APIs implement in particular ways (like selecting which fields you want). The pain you'll experience depends heavily on your data model and the abuse potential that brings. I think the biggest problem with GraphQL is the JavaScript ecosystem around it, and all of its implicit context. It seem…
I don't think Relay is used that much outside of Facebook. The community seems to have settled on Apollo. Personally I find Apollo over-engineered. When I couldn't delete things from the cache, because of a bug, and was faced with digging into the complex code-base, I ended up just using straight JSON with a HTTP client/fetch and caching in a simple JS object.
Other users of my API [1] just use straight HTTP with JSON as well. GraphQL clients seem to solve something we are not encountering. If urql [2] or gqless [3] work well when I try them I'd be up for changing my mind though.
[1]: https://github.com/kitspace/partinfo
[2]: https://github.com/FormidableLabs/urql
[3]: https://gqless.dev/
Re: How and why GraphQL will influence the Sourcehut alpha
#79I don't understand the attraction to Graphql. (I do understand it if maybe you actually want the things that gRPC or Thrift etc gives you) It seems like exactly the ORM solution/problem but even more abstract and less under control since it pushes the orm out to browser clients and the frontend devs. ORM suffer from being at beyond arms length from the query analyzer in the database server. https://en.wikipedia.org/w…
> I don't understand the attraction to Graphql. It's attractive primarily to frontend developers. Instead of juggling various APIs (oftne poorly designed or underdesigned due to conflicting requirements and time constraints) you have a single entry into the system with almost any view of the data you want. Almost no one ever talks about what a nightmare it becomes on the server-side, and how inane the implementations…
As a full-stack dev, I'm going to always reach for things like Hasura for building my backend from now on. It auto generates a full CRUD GraphQL API from my Postgres DB schema. Most of the backend boilerplate is eliminated this way. If I need to add additional business logic, I can use serverless functions that run between the GraphQL query from the front end and the DB operations (actions in Hasura). Most of the heavy lifting is through the front end anyways, and this keeps everything neatly in sync.
Re: How and why GraphQL will influence the Sourcehut alpha
#80The author says that he has soured on Python for “serious, large projects”. While it’s clearly personal opinion, and that’s fair enough , I can’t help but think his choice of framework hasn’t helped him and has likely caused significant slowdown when delivering features. Looking through some of the code for Sourcehut, there’s an insane amount of boilerplate or otherwise redundant code[1]. The shared code library is a…
Exactly agreed. I basically only use Flask for things I want to explicitly be single-file these days. For anything larger, I reach for Django, because I know that if I need at least one thing from it (and I always need the ORM/migrations/admin), it will have been worth it.
My current favorite way of building APIs is this Frankenstein's monster of Django/FastAPI, which actually works quite well so far:
https://www.stavros.io/posts/fastapi-with-django/
FastAPI is a much better way of writing APIs than DRF, I wish it were a Django library, but hopefully compatibility will improve as Django adds async support.