In any other situation I'd recommend it since it really was the tool of choice for decentralized git repos with lots of cool features. (Despite the "Empowering developers with DeFi building blocks like NFTs, token streams, and more" mentioned on the home page which throws me off)
Edit: It seems like the download page is up and working now.
Hmm, great idea. We could build on Git as a storage medium, and we'd need a durable and reliable way to exchange patches. Something like ...email?
$ man -k patches
git-am(1) - Apply a series of patches from a mailbox
git-format-patch(1) - Prepare patches for e-mail submission
git-imap-send(1) - Send a collection of patches from stdin to an IMAP folder
git-send-email(1) - Send a collection of patches as emails
Ironic that you're pondering Git as a solution to Github's self-created centralization problem.
That would be great. But Github is a massive coordination point with network effects and free tiers so it's not so easy to compete. Some other challenges:
- despite being decentralized, you still need moderation and access control
- open source projects typically aren't great at frontend UI/UX
It would be neat if I could publish git repos on IPFS and receive patches from people. It's just hard to compete with a centralized, CDN'd service where you can click and get a result in 100ms.
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 took away the pain of managing types? You didn't have to explicitly parse or cast "0.001" into 0.01.
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.
I'm not totally against GraphQL in general. As an alternative to REST it can sometimes make sense. And let's be real, most REST APIs are absolute garbage. Anything would be better than a bad REST API.
And if, in fact, you are storing a graph in a graph database, the QL makes a bit of sense.
But nothing in the post makes any sense out of any of that. It's just Python bad; REST bad; I read too much hacker news, and I feel like it's time for a change.
Like, when I complain about other people's REST APIs, that's out of my control. This guy is saying that his API is garbage, and instead of fixing it to make it better, he's just going to redo everything with a worse result. I don't get 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 require gql and go, I did some digging around, thinking, there has to be a better alternative to this. I have worked with jQuery, React, GraphQL.
I have seen too many front end developers write queries equivalent to "select * from users, t1, t2, ... tn, left outer join on users.id = t1.user_id... etc etc etc".
I think that is just bullshit.
I prefer to tell the frontend people - these are the endpoints that backend team provides, go live with it. If you really have issues, talk to them, and they might just add a new endpoint for you.
If you let frontend developers dictate backend queries, all you will get is a big master cluster fuck. I am talking average joe developers that we usually find to work on startups.
I think Frontend has the right to take over certain domains of the backend. A very clear example of this is templating. Templating used to be a backend task, but it became very clear it was the frontend developers that needed power over this domain. Going over to a backend dev to make adjustments to the templates is an inefficiency that had to be solved, period.
I agree with you that writing optimal queries or data modeling should not be shifted over to the frontend. With that said, there are basic aspects of this equation that can be factored out. There should be a layer where frontend can at the very least pick or mix the data they need. That doesn’t necessarily mean Graphql, but could also mean a simple middle stack layer where one can do this basic thing without being able to shoot themselves in the foot.
There’s a responsible way to do this, and most likely will be an ongoing discussion.
k8s and even docker are trying to solve a problem not many people will ever face. However, being the sexy new things loads of people get sucked into integrating it into their stack from the word go.
Being reluctant to adopt new technology unless you really really need might be a more sensible thing to do.
