graphql-spec
connexion
graphql-spec | connexion | |
---|---|---|
37 | 23 | |
14,226 | 4,420 | |
0.2% | 0.2% | |
5.8 | 8.2 | |
25 days ago | 3 days ago | |
Shell | Python | |
- | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
graphql-spec
-
Show HN: REST Alternative to GraphQL and tRPC
GraphQL's first draft release was 8 years ago. [1]
It's first non-draft release was 5 years ago. [2]
It's first release under a community foundation was 2 years ago. [3]
[1] https://spec.graphql.org/July2015/
[2] https://github.com/graphql/graphql-spec/releases/tag/June201...
[3] https://github.com/graphql/graphql-spec/releases/tag/October...
-
Intro to PostGraphile V5 (Part 3): Introspection and Abstraction
I'm a big believer in GraphQL (in fact, at time of writing I'm #2 contributor to the GraphQL spec itself) so it pains me that a tool I built doesn't always have easy ways to achieve the "versionless schema" design that GraphQL encourages when it comes to making significant breaking changes to your underlying database tables. (Personally, I think you should aim for your database schema itself to be versionless, but this is not always possible.) Of course you can build your PostGraphile schema over views instead of tables, but views have their own problems that I won't go into here…
-
Migrating Netflix to GraphQL Safely
I created a proposal for Map type but didn’t make it through.
https://github.com/graphql/graphql-spec/pull/888
The issue with GraphQL is it tries to appease too many masters.
Similar to jsx. The language isn’t evolving.
The good thing is the spec is (almost) frozen, so there’s many implementations, the bad is it can encompass the flexibility of json schema can do.
-
GraphQL Live Queries with live directive
Longer thread - Subscriptions RFC: Are Subscriptions and Live Queries the same thing?
https://github.com/graphql/graphql-spec/issues/284
-
Ask HN: Tutorials Written with Heavy Dependencies
You’ve probably figured it out by now, but for others who may be in a similar position; GraphQL is a specification (with various implementations) and you can read up on the spec here: https://spec.graphql.org/
-
GraphQL object schemas - how to represent (and query?) Graph (hierarchical objects) in GraphQL?
If you're asking whether GraphQL supports anonymous objects that can be arbitrarily nested then no, it doesn't.
- Union for an input to a mutation arg
-
Thanks graphql, I hate it.
show this feature request some love https://github.com/graphql/graphql-spec/issues/174
-
Deprecation Notice: GraphQL for Packages
* Performance: It's just hard to track down what makes an operation slow. The waterfall nature of resolvers is a big contributor
[1] https://github.com/graphql/graphql-spec/issues/488
-
GraphQL error handling to the max with Typescript, codegen and fp-ts
:::note GraphQL Union is available for Types only, not for Inputs. However, the oneOf directive will bridge the gap in the future.
connexion
-
Write OpenAPI with TypeSpec
I like the idea, especially the TS-like syntax around enums and union types. I've always preferred the SDL for GraphQL vs writing OpenAPI for similar reasons.
I echo the sentiment others have brought up, which is the trade-offs of a code-driven schema vs schema-driven code.
At work we use Pydantic and FastAPI to generate the OpenAPI contract, but there's some cruft and care needed around exposing those underlying Pydantic models through the API documentation. It's been easy to create schemas that have compatibility problems when run through other code generators. I know there are projects such as connexction[1] which attempt to inverse this, but I don't have much experience with it. In the GraphQL space it seems that code-first approaches are becoming more favored, though there's a different level of complexity needed to create a "typesafe" GraphQL server (eg. model mismatches between root query resolvers and field resolvers).
[1] https://github.com/spec-first/connexion
-
Connexion 3 released!
Connexion is a popular Python web framework (~ 5 million downloads per month) that makes spec-first and api-first development easy. You describe your API in an OpenAPI (or swagger) specification with as much detail as you want and Connexion will guarantee that it works as you specified.
- Connexion 3.0 Released
-
Show HN: REST Alternative to GraphQL and tRPC
> While REST APIs don't generally provide the same level of control to clients as GraphQL, many times this could be seen as a benefit especially in scenarios where strict control over data access and operations is crucial.
Rest is more secure, cacheable, and more performant on the server side as field resolution doesn't need to happen like it does with GraphQL. It is not more performant on the client side, and this is a trade-off, but I favor rest applications over GraphQL ones as a DevOps engineer. They are much easier to administer infrastructure-wise, I can cache the requests, etc.
Data at our company suggests that several small queries actually do better performance-wise than one large one. We switched to GraphQL a year and a half ago or so, but this piece of data seems to suggest that we might have been better off just sticking with REST. My suggestion to that effect was not met with optimism either on the client or server side. Apparently there are server-side benefits as well, allowing for more modular development or something like that.
I have used OpenAPI using connexion[1]. It was hard to understand at first, but I really liked that the single source of truth was one schema. It also made it really easy to develop against the API because it came with a UI that showed the documentation for all the rest end points and even had test buttons.
1: https://connexion.readthedocs.io/en/latest/
-
Ask HN: Why is there no specification for Command Line Interfaces?
What's the use case? I was thinking about this exact issue because my product ships several CLI tools, but I wasn't convinced it would be worth the effort.
An OpenAPI specification describes an HTTP interface, and I see it as useful because it makes it easier to write code in language-of-choice to generate HTTP requests (by generating client libraries from the OpenAPI spec).
For a CLI, the interface is the command-line. Usually people type these commands, or they end up in bash scripts, or sometimes they get called from programming language of choice by shelling out to the CLI. So I could see a use case for a CLI spec, which would make it easier to generate client libraries (which would shell out to the CLI)... but it seems a little niche.
Or maybe, as input to a documentation tool (like Swagger docs). I would imagine if you're using a CLI library like Python's Click, most of that data is already there. Click Parameters documentation: https://click.palletsprojects.com/en/8.1.x/parameters/
Or maybe, you could start from the spec and then generate code which enforces it. So any changes pass through the spec, which would make it easy to write code (server and client-side) / documentation / changelogs. Some projects like this: Guardrail (Scala) https://github.com/guardrail-dev/guardrail , and Connexion (Python) https://github.com/spec-first/connexion .
But without this ecosystem of tooling, documenting your CLI in a specification didn't really seem worth the effort. Of course, that's a bootstrapping problem.
-
Flask is Great!
Connexion is a framework on top of Flask that automagically handles HTTP requests defined using OpenAPI/Swagger.
-
What is the best practice for mapping JSON requests to objects and back to JSON?
I recommend you create a OpenAPI Specification and implement a python module that you expose via connexion or on the cli via click(for easy testing).
-
Flask-Powered APIs: Fast, Reliable, and Used by the World's Top Companies
I'm here because Swagger-CodeGen created flask-Connexion boilerplate for python.
- Python REST APIs With Flask, Connexion, and SQLAlchemy – Part 1 – Real Python
-
Does anybody know any good resources I could use to study ISP architecture?
Personally we just prov them using librouteros and flask-connexion/openapi.
What are some alternatives?
apollo-server - 🌍 Spec-compliant and production ready JavaScript GraphQL server that lets you develop in a schema-first way. Built for Express, Connect, Hapi, Koa, and more.
flask-restful - Simple framework for creating REST APIs
Hasura - Blazing fast, instant realtime GraphQL APIs on your DB with fine grained access control, also trigger webhooks on database events.
Flask RestPlus - Fully featured framework for fast, easy and documented API development with Flask
graphql-ws - Coherent, zero-dependency, lazy, simple, GraphQL over WebSocket Protocol compliant server and client.
flasgger - Easy OpenAPI specs and Swagger UI for your Flask API
Neo4j - Graphs for Everyone
django-rest-framework - Web APIs for Django. 🎸
graphql-shield - 🛡 A GraphQL tool to ease the creation of permission layer.
eve - REST API framework designed for human beings
gRPC - The C based gRPC (C++, Python, Ruby, Objective-C, PHP, C#)
falcon - The no-magic web data plane API and microservices framework for Python developers, with a focus on reliability, correctness, and performance at scale.