join-monster
join-monster | pycon-graphql | |
---|---|---|
3 | 1 | |
2,656 | 3 | |
0.3% | - | |
6.6 | 0.0 | |
1 day ago | about 2 years ago | |
JavaScript | HTML | |
MIT License | MIT License |
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.
join-monster
-
Understanding TTFB Latency in DJango - Seems absurdly slow after DB optimizations even locally
GraphQL could be efficiently translated into SQL and things certainly try, but the only thing close to a "bulletproof" implementation I found was Join Monster (https://github.com/join-monster/join-monster) in NodeJS-land and even that I think is now mostly abandoned. GraphQL as a system was built assuming random-access to data stores is ~free because that's what Facebook has, but the rest of us don't :)
-
Ask HN: Nested Resources in REST/HTTP API URLs?
REST is not a strict specification and it's not a single implementation, you can just start doing it.
That said, I wouldn't recommend going the allow everything flexible resolver way like GraphQL: it's terrible for performance (eg. most APIs use N+1 queries unless you have something like https://github.com/join-monster/join-monster), the complexity of the codebase skyrockets and having to specify all the fields you want is not exactly ergonomic in most situations.
- GraphQL Is a Trap?
pycon-graphql
-
GraphQL Is a Trap?
I just got done doing a talk on GraphQL for PyCon2022 and I do agree with some of the points here. Performance work can be tedious and is not bi-directional in the graph so the number of dataloaders can blow up making debugging hard. Identifying where n+1 queries are in the API can also be difficult, but I used this open source package to help: https://github.com/tatari-tv/query-counter. I think the article failed to mention two of the things that GraphQL does really well: dense queries and built-in pagination. You're able to do the work of many serialized REST queries in one query using the node context of the GraphQL graph structure, which is a huge win if you're hitting performance issues related to requests per second to your API. Also pagination using the cursor, before/after, etc. is very helpful and Flask_Graphene enables some slick caching there to make subsequent queries at that cursor to be extremely performant. I have code with my sample implementation which simple, but shows the power of DataLoaders: https://github.com/lame/pycon-graphql.
What are some alternatives?
ent - An entity framework for Go
edgedb - A graph-relational database with declarative schema, built-in migration system, and a next-generation query language
trustfall - A query engine for any combination of data sources. Query your files and APIs as if they were databases!
genql - Type safe TypeScript client for any GraphQL API
query-counter - SQLAlchemy model N+1 debugger!
graphql-directive-rest - GraphQL directive for easy integration with REST API
postgrest - REST API for any Postgres database
Sqlmancer - Conjure SQL from GraphQL queries 🧙🔮✨
graphql-cached-get
objection-filter - Filter objection.js models over HTTP using complex search queries
restQL-core - Microservice query language