7 ms·

A Case for Clojure and GraphQL: Replacing Django

83 points by rlander 9y ago

Areading314 9y ago
Error establishing database connection lmao
- abledon 9y ago
  It was a performance art web blog post where the page is down to show the case for switching
jefurii 9y ago
Error 502 Bad Gateway
- vitchor 9y ago
  It's back up.
ivan_ah 9y ago
google-cached version: https://webcache.googleusercontent.com/search?q=cache:Rd2bFx3HUAgJ:https://cheesecakelabs.com/%3Fp%3D5590+&cd=1&hl=en&ct=clnk&gl=ca https://webcache.googleusercontent.com/search?q=cache:Rd2bFx...
- mping 9y ago
  google cache is forwarding to the real site, which is down. weird...
  - KingMob 9y ago
    If you jam Esc fast enough, it won't redirect. Having read the article, it's actually pretty nuanced, despite the headline. "These are the good parts, these are the bad parts, etc."
  - qeternity 9y ago
    Text only version doesn't redirect - http://webcache.googleusercontent.com/search?q=cache:Rd2bFx3HUAgJ:https://cheesecakelabs.com/%3Fp%3D5590&num=1&hl=en&gl=ca&strip=1&vwsrc=0 http://webcache.googleusercontent.com/search?q=cache:Rd2bFx3...
dizzystar 9y ago
Outside of very special circumstances, I don't think it is a good idea to replace Python code with Clojure code. In fact, judging from my own contracting experience and seeing the many mistakes made by first-time Clojure programmers, I more often than not suggest moving from Clojure to anything else. The problem with using esoteric languages is multi-fold. First, you have to trust that the original programmers actually know the language enough to not create a massive disaster. Are they comfortable working without a framework, are they knowledgeable about all the issues that arise from building closer to the metal, so to speak? It seems to me that the answer is "no" more often than "yes." Once this happens, you end up in a read-only code situation, and this is a problem because they leave the project with tons of bugs and downright stupid decisions. You are then left in the position to ask 15 people if they can make dollars or sense of anything written, and if you are fortunate, you will get one "yes." I joke that I know all 50 Clojure programmers in the US, and sadly, that's not much of an overstatement. If you want your code to exist, and you aren't a real somebody, then good luck. If you aren't located in SF, LA, or some other city that attracts talent, definitely do not use Clojure or any other esoteric language! Of course, I didn't read the article, as it isn't loading at all.
- wellpast 9y ago
  I don't see how Clojure is "close to the metal". To me it seems pretty high up in the ladder of abstractions. In Java, we have Lambdas and Streams and some concurrency APIs and Clojure only seems to build _on top_ of these, making them much more ergonomic, simpler, AND encouraging immutability, to boot. Novice programmers love mutability, but in Clojure you kind of have to go out of your way to solve something with mutation. So to me (as long as users aren't getting carried away with writing macros) it seems you should land in a better spot with Clojure. If you're not seeing that's the case, then what is it? What are the common mistakes that you see these novices making that make for unmaintainable code---that somehow is not found in the same proportion in something more mainstream? Would seriously love to hear.
  - jtmcmc 9y ago
    Clojure is much 'closer to the metal' than django in the sense that you have to rebuild all of the pre-built, fairly hardened pieces that django has.
rburhum 9y ago
503 Service Temporarily Unavailable
- gracietti 9y ago
  Seems it's back up!
douglaswlance 9y ago
You can use GraphQL with Django.
douglaswlance 9y ago
You can implement GraphQL using django-graphene pretty easily. Django Rest Framework + graphene is fantastic for auth and easily maintained endpoints.
- rlander 9y ago
  Author here. Yes, Graphene is awesome (we're actually experimenting with it too) and, in a perfect world, I'd be comparing Clojure/GraphQL with Python/Graphene. But it is what it is and, even though the project I could compare to wasn't ideal, I still think we were able to draw valuable lessons for our use cases. Also note, we didn't choose Clojure because of GraphQL, it simply came as a bonus in the form of Lacinia.
- yen223 9y ago
  One piece of advice: if you're implementing a GraphQL server on top of Django, you're better off building your schema with graphene, and avoiding graphene-django altogether. graphene-django is pretty buggy, mainly because both Graphene and Django have a lot of implicit behaviour that don't play well together - a common theme among popular Python libraries, sadly. A nasty example (that is now fixed) was that connection fields generated from m2m fields would return every single instance of the target model!
  - whalesalad 9y ago
    Frankly ALL of the GraphQL/Python stuff is a mess. It’s a wonderful contribution to the community but clearly, none of it was designed by a Python hacker. I do agree with your sentiment. Django is less and less valuable to me due to the lock-in. The ecosystem is such that lately you can compose your own system (ie, Flask, Flasql and Graphene, and pick your ORM poison of Peewee or SQLAlchemy) and have a much more modular setup where each part can be replaced more easily.
lilbobbytables 9y ago
One concern I have with Graphql is security and access to data. I'm sure there are plenty of ways to control it, but I'd wager that most will be ignored outside of basic ACL’s. Often times certain user types should only have access to certain fields in data or be able to query it in certain ways. Too often I see apps where the developers just assume they have full control since they're making the interface, while it's trivial to watch the API calls and intercept or modify them.
- whalesalad 9y ago
  This isn’t a GraphQL concern. The same issue happens with REST or any other communication strategy.
- southpolesteve 9y ago
  I see this comment a lot. The issues are the same with any REST API. Often they have been solved many times by the community or are baked into whatever backend framework you happen to be using. GraphQL (and community) are still converging on a set of best practices, but you can still solve the issue yourself using the same techniques from REST. Here is how we do it at Bustle: 1. Wrap the entire query execution in an auth check. This is similar to whatever happens in a REST auth flow. Check the caller is legit before moving on. Nothing graphQL specific here. 2. Check auth on fields. This is a neat thing about graphQL. You can statically analyze the fields in the query to make sure the caller is only accessing fields they are supposed to. We do this by adding an `auth` property to the standard graphQL-js field object. When we build the schema we do some fanciness to wrap the resolvers in a new function that checks that field and behaves accordingly[1] 3. Throw errors on unauthorized data. Same as you would in a REST API. If you get back data the caller can't access, check it before replying. Obviously not ideal, but sometimes this is the only option. At someone on twitter's request I wrote up some more thoughts a while back about running graphQL in production: https://gist.github.com/southpolesteve/08edb6a481c07f66eb71e4df619827ae https://gist.github.com/southpolesteve/08edb6a481c07f66eb71e... I also gave a talk on this at Node Interactive last week: https://youtu.be/vI9ERvz9WWU https://youtu.be/vI9ERvz9WWU [1] https://gist.github.com/southpolesteve/e190e9572d060b515836666610b858a9 https://gist.github.com/southpolesteve/e190e9572d060b5158366...
- 9y ago

83 points by rlander 9y ago

Areading314 9y ago

Error establishing database connection lmao

abledon 9y ago
It was a performance art web blog post where the page is down to show the case for switching

jefurii 9y ago

Error 502 Bad Gateway

vitchor 9y ago
It's back up.

ivan_ah 9y ago

google-cached version: https://webcache.googleusercontent.com/search?q=cache:Rd2bFx3HUAgJ:https://cheesecakelabs.com/%3Fp%3D5590+&cd=1&hl=en&ct=clnk&gl=ca https://webcache.googleusercontent.com/search?q=cache:Rd2bFx...

mping 9y ago
google cache is forwarding to the real site, which is down. weird...
- KingMob 9y ago
  If you jam Esc fast enough, it won't redirect. Having read the article, it's actually pretty nuanced, despite the headline. "These are the good parts, these are the bad parts, etc."
- qeternity 9y ago
  Text only version doesn't redirect - http://webcache.googleusercontent.com/search?q=cache:Rd2bFx3HUAgJ:https://cheesecakelabs.com/%3Fp%3D5590&num=1&hl=en&gl=ca&strip=1&vwsrc=0 http://webcache.googleusercontent.com/search?q=cache:Rd2bFx3...

dizzystar 9y ago

Outside of very special circumstances, I don't think it is a good idea to replace Python code with Clojure code. In fact, judging from my own contracting experience and seeing the many mistakes made by first-time Clojure programmers, I more often than not suggest moving from Clojure to anything else. The problem with using esoteric languages is multi-fold. First, you have to trust that the original programmers actually know the language enough to not create a massive disaster. Are they comfortable working without a framework, are they knowledgeable about all the issues that arise from building closer to the metal, so to speak? It seems to me that the answer is "no" more often than "yes." Once this happens, you end up in a read-only code situation, and this is a problem because they leave the project with tons of bugs and downright stupid decisions. You are then left in the position to ask 15 people if they can make dollars or sense of anything written, and if you are fortunate, you will get one "yes." I joke that I know all 50 Clojure programmers in the US, and sadly, that's not much of an overstatement. If you want your code to exist, and you aren't a real somebody, then good luck. If you aren't located in SF, LA, or some other city that attracts talent, definitely do not use Clojure or any other esoteric language! Of course, I didn't read the article, as it isn't loading at all.

wellpast 9y ago
I don't see how Clojure is "close to the metal". To me it seems pretty high up in the ladder of abstractions. In Java, we have Lambdas and Streams and some concurrency APIs and Clojure only seems to build _on top_ of these, making them much more ergonomic, simpler, AND encouraging immutability, to boot. Novice programmers love mutability, but in Clojure you kind of have to go out of your way to solve something with mutation. So to me (as long as users aren't getting carried away with writing macros) it seems you should land in a better spot with Clojure. If you're not seeing that's the case, then what is it? What are the common mistakes that you see these novices making that make for unmaintainable code---that somehow is not found in the same proportion in something more mainstream? Would seriously love to hear.
- jtmcmc 9y ago
  Clojure is much 'closer to the metal' than django in the sense that you have to rebuild all of the pre-built, fairly hardened pieces that django has.

rburhum 9y ago

503 Service Temporarily Unavailable

gracietti 9y ago
Seems it's back up!

douglaswlance 9y ago

You can use GraphQL with Django.

douglaswlance 9y ago

You can implement GraphQL using django-graphene pretty easily. Django Rest Framework + graphene is fantastic for auth and easily maintained endpoints.

rlander 9y ago
Author here. Yes, Graphene is awesome (we're actually experimenting with it too) and, in a perfect world, I'd be comparing Clojure/GraphQL with Python/Graphene. But it is what it is and, even though the project I could compare to wasn't ideal, I still think we were able to draw valuable lessons for our use cases. Also note, we didn't choose Clojure because of GraphQL, it simply came as a bonus in the form of Lacinia.
yen223 9y ago
One piece of advice: if you're implementing a GraphQL server on top of Django, you're better off building your schema with graphene, and avoiding graphene-django altogether. graphene-django is pretty buggy, mainly because both Graphene and Django have a lot of implicit behaviour that don't play well together - a common theme among popular Python libraries, sadly. A nasty example (that is now fixed) was that connection fields generated from m2m fields would return every single instance of the target model!
- whalesalad 9y ago
  Frankly ALL of the GraphQL/Python stuff is a mess. It’s a wonderful contribution to the community but clearly, none of it was designed by a Python hacker. I do agree with your sentiment. Django is less and less valuable to me due to the lock-in. The ecosystem is such that lately you can compose your own system (ie, Flask, Flasql and Graphene, and pick your ORM poison of Peewee or SQLAlchemy) and have a much more modular setup where each part can be replaced more easily.

lilbobbytables 9y ago

One concern I have with Graphql is security and access to data. I'm sure there are plenty of ways to control it, but I'd wager that most will be ignored outside of basic ACL’s. Often times certain user types should only have access to certain fields in data or be able to query it in certain ways. Too often I see apps where the developers just assume they have full control since they're making the interface, while it's trivial to watch the API calls and intercept or modify them.

whalesalad 9y ago
This isn’t a GraphQL concern. The same issue happens with REST or any other communication strategy.
southpolesteve 9y ago
I see this comment a lot. The issues are the same with any REST API. Often they have been solved many times by the community or are baked into whatever backend framework you happen to be using. GraphQL (and community) are still converging on a set of best practices, but you can still solve the issue yourself using the same techniques from REST. Here is how we do it at Bustle: 1. Wrap the entire query execution in an auth check. This is similar to whatever happens in a REST auth flow. Check the caller is legit before moving on. Nothing graphQL specific here. 2. Check auth on fields. This is a neat thing about graphQL. You can statically analyze the fields in the query to make sure the caller is only accessing fields they are supposed to. We do this by adding an `auth` property to the standard graphQL-js field object. When we build the schema we do some fanciness to wrap the resolvers in a new function that checks that field and behaves accordingly[1] 3. Throw errors on unauthorized data. Same as you would in a REST API. If you get back data the caller can't access, check it before replying. Obviously not ideal, but sometimes this is the only option. At someone on twitter's request I wrote up some more thoughts a while back about running graphQL in production: https://gist.github.com/southpolesteve/08edb6a481c07f66eb71e4df619827ae https://gist.github.com/southpolesteve/08edb6a481c07f66eb71e... I also gave a talk on this at Node Interactive last week: https://youtu.be/vI9ERvz9WWU https://youtu.be/vI9ERvz9WWU [1] https://gist.github.com/southpolesteve/e190e9572d060b515836666610b858a9 https://gist.github.com/southpolesteve/e190e9572d060b5158366...
9y ago