6 ms·

IMHO what makes or breaks a paradigm like REST or GraphQL in real-life is the state of tooling made by third-parties to enable its adoption in the workplace or

IMHO what makes or breaks a paradigm like REST or GraphQL in real-life is the state of tooling made by third-parties to enable its adoption in the workplace or personal projects. Working in Python-land I'm pretty confident REST wouldn't have been as ubiquitous if it wasn't for tools like Flask, marshmallow, and the myriad of other tools. Having taken up GraphQL in personal projects I can say that at least in Python the tooling just ain't there so until it gets there I don't see GraphQL killing anything.

y4mi 8y ago
Last year around this time I tried to implement a bare bones graqhql API with Django. I kept having to write boilerplate code to get it working. I quickly learned why Django rest framework is the defacto standard... The tooling is just uncomparibly better
chrisco255 8y ago
I think serverless GraphQL is the future of the backend. And honestly, not as familiar with the Python landscape but if you use tools like Prisma (Node-based) or AppSync (AWS Lambda based), a lot of your GraphQL queries and mutations can be generated automatically based on a typed schema file.
- k__ 8y ago
  Have any good resources to get into AppSync, especially with CloudFormation?
  - chrisco255 8y ago
    https://read.acloud.guru/deploy-an-aws-appsync-graphql-api-with-amazon-cloudformation-9a783fdd8491 https://read.acloud.guru/deploy-an-aws-appsync-graphql-api-w... https://andrewgriffithsonline.com/blog/serverless-websockets-on-aws/ https://andrewgriffithsonline.com/blog/serverless-websockets...
    - k__ 8y ago
      Very good, thank you :)
BerislavLopac 8y ago
Have you tried Graphene? [1] I haven't, but have read its documentation a lot, and it looks quite powerful. I'm not happy that it introduces yet another data object library, but at least it's possible to build plugins for existing ones -- SQLAlchemy and Django are already there, and it would be nice to add ones for attrs, Schematics and of course the 3.7 native data classes. Regarding the popularity of REST -- even if it wasn't intended for CRUD originally, it fits perfectly with that paradigm, and I think this is why many people were able to implement it easily when they started using it. [1] http://graphene-python.org/ http://graphene-python.org/
- somada141 8y ago
  I've actually worked with both Graphene and Graphene-SQLAlchemy a fair bit. Honestly I found that the documentation , albeit well-written, was insufficient (especially for the SQLAlchemy extension). That being said, having to expose an SQLAlchemy ORM via Graphene did not lead to much code-duplication as much of the ORM is automatically accounted-for in the GraphQL schema (there's a fair bit of duplication when it comes to mutations but I reckon that's just a matter of someone doing the work in the extension). Moreover, the community around it in both its GitHub and StackOverflow isn't as active as the equivalent GraphQL communities in other languages/ecosystems. All in all I believe that increased adoption of GraphQL will lead to even better tooling and I'm sincerely hoping it'll catch on :). My primary 'beef' with REST has always been the "10 ways to do 1 thing" especially when it comes to less standardised features like pagination, type-definition/validation, etc. GraphQL introducing some of these things out-of-the-box would hopefully reduce the comfort-zone-based bikeshedding that comes with any new REST API being developed.
pjmlp 8y ago
Same applies to Java and .NET. I haven't seen anything that would make me advise GraphQL over REST, specially now that REST tooling is finally catching up with validation and graphical generation. All the presentations I have seen about how productive GraphQL is, seem to live in JavaScript with NoSQL databases silos.
- somada141 8y ago
  Admittedly JS-land has some fantastically developed and documented tooling for GraphQL. I reckon that increased adoption, however, will see equivalent efforts being made in other ecosystems.

y4mi 8y ago

Last year around this time I tried to implement a bare bones graqhql API with Django. I kept having to write boilerplate code to get it working. I quickly learned why Django rest framework is the defacto standard... The tooling is just uncomparibly better

chrisco255 8y ago

I think serverless GraphQL is the future of the backend. And honestly, not as familiar with the Python landscape but if you use tools like Prisma (Node-based) or AppSync (AWS Lambda based), a lot of your GraphQL queries and mutations can be generated automatically based on a typed schema file.

k__ 8y ago
Have any good resources to get into AppSync, especially with CloudFormation?
- chrisco255 8y ago
  https://read.acloud.guru/deploy-an-aws-appsync-graphql-api-with-amazon-cloudformation-9a783fdd8491 https://read.acloud.guru/deploy-an-aws-appsync-graphql-api-w... https://andrewgriffithsonline.com/blog/serverless-websockets-on-aws/ https://andrewgriffithsonline.com/blog/serverless-websockets...
  - k__ 8y ago
    Very good, thank you :)

BerislavLopac 8y ago

Have you tried Graphene? [1] I haven't, but have read its documentation a lot, and it looks quite powerful. I'm not happy that it introduces yet another data object library, but at least it's possible to build plugins for existing ones -- SQLAlchemy and Django are already there, and it would be nice to add ones for attrs, Schematics and of course the 3.7 native data classes. Regarding the popularity of REST -- even if it wasn't intended for CRUD originally, it fits perfectly with that paradigm, and I think this is why many people were able to implement it easily when they started using it. [1] http://graphene-python.org/ http://graphene-python.org/

somada141 8y ago
I've actually worked with both Graphene and Graphene-SQLAlchemy a fair bit. Honestly I found that the documentation , albeit well-written, was insufficient (especially for the SQLAlchemy extension). That being said, having to expose an SQLAlchemy ORM via Graphene did not lead to much code-duplication as much of the ORM is automatically accounted-for in the GraphQL schema (there's a fair bit of duplication when it comes to mutations but I reckon that's just a matter of someone doing the work in the extension). Moreover, the community around it in both its GitHub and StackOverflow isn't as active as the equivalent GraphQL communities in other languages/ecosystems. All in all I believe that increased adoption of GraphQL will lead to even better tooling and I'm sincerely hoping it'll catch on :). My primary 'beef' with REST has always been the "10 ways to do 1 thing" especially when it comes to less standardised features like pagination, type-definition/validation, etc. GraphQL introducing some of these things out-of-the-box would hopefully reduce the comfort-zone-based bikeshedding that comes with any new REST API being developed.

pjmlp 8y ago

Same applies to Java and .NET. I haven't seen anything that would make me advise GraphQL over REST, specially now that REST tooling is finally catching up with validation and graphical generation. All the presentations I have seen about how productive GraphQL is, seem to live in JavaScript with NoSQL databases silos.

somada141 8y ago
Admittedly JS-land has some fantastically developed and documented tooling for GraphQL. I reckon that increased adoption, however, will see equivalent efforts being made in other ecosystems.