[HN Gopher] Show HN: Graphweaver - Instant GraphQL API on Postgr...
___________________________________________________________________
Show HN: Graphweaver - Instant GraphQL API on Postgres, MySQL,
SQLite and More
Graphweaver is an open-source GraphQL API Server that can connect
many data sources to create a single API. Create a headless CMS,
API Gateway, BaaS or use it as a BFF.
Author : graphweaver
Score : 51 points
Date : 2023-08-27 11:00 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| revenga99 wrote:
| does this support aggregations? ie sum, count etc.
| graphweaver wrote:
| Nothing out-of-the-box for this yet. We have actually done this
| for our clients, but it has been a custom field resolver:
|
| https://graphweaver.com/docs/graphql-entities-and-resolvers#...
| pyrolistical wrote:
| Watch somebody use this as a public API and complain they got
| hacked
| graphweaver wrote:
| We agree, with any GraphQL API you need to make sure it is
| hardened for production.
|
| We are looking to add more on documentation on this soon and
| maybe a tutorial series on exactly this.
| gumballindie wrote:
| How does this lib handle GQL Injections?
| skeep wrote:
| We use MikroORM behind the scenes and keep up-to-date with
| versions and vulnerabilities.
|
| There is always more to do and we do accept PRs for
| improvements!
| SoftwareDev4 wrote:
| How is this different from WunderGraph?
|
| https://wundergraph.com/
| graphweaver wrote:
| With Wundergraph, you define schema first. This generates types
| and hooks that you can then use on the front end. The
| production API is not a GraphQL API its Rest I believe.
|
| Graphweaver also generate types and react hooks for the front
| end, when running `graphweaver watch`. But Graphweaver is a
| GraphQL API and that is deployed into production. We wrap
| GraphQL Codegen and also do our own datasource introspection.
| More on that in this article:
|
| https://dev.to/tnodell/exploring-the-benefits-of-graphql-cod...
| captn3m0 wrote:
| The REST API connector docs is blank right now, but curious about
| it. How does it work (how is it configured?), and what's the
| usecase for it?
| graphweaver wrote:
| You're right we need to improve the documentation on this. We
| do have an example though:
|
| https://github.com/exogee-technology/graphweaver/tree/main/s...
|
| We have also added the OpenAPI spec on the roadmap however,
| every REST API we have integrated so far has been custom.
|
| The REST connector allows you to have full-control over how it
| connects to the API:
|
| https://github.com/exogee-technology/graphweaver/blob/main/s...
| ushakov wrote:
| What's the difference between GraphQL Mesh?
|
| Is this thing any relevant if I'm using React Server Components
| to fetch the data from the db directly?
| graphweaver wrote:
| The main difference is Graphweaver is code-only approach with
| Typescript. GraphQL Mesh is a schema-first approach.
|
| Both great projects, different philosophies.
| gedy wrote:
| Nice, is this comparable to Hasura? What are some differences if
| so?
| graphweaver wrote:
| Yeah it is comparable:
|
| - We are 100% open source. - Written in Typescript. - We
| support any data source directly in the server process, either
| with pre-built data providers or build your own. - We support
| cross data source filtering (get orders from database with CRM
| username)
| krosaen wrote:
| Anyone have experience with this and postgraphile? The additional
| data sources is clearly a benefit of graphweaver, but wondering
| for the postgres use case how they compare.
| graphweaver wrote:
| We have used postgres with every client deployment so far, it's
| our go to relational db.
|
| We have also needed to connect to a 2nd or 3rd data source on
| every project. So the power is when you combine these data
| sources.
| crubier wrote:
| Do you know about Postgraphile? Your comment did not address
| that part, I'm curious too
| ehutch79 wrote:
| I didn't go to deep, but I don't immediately see how you add
| business logic and custom validation.
|
| Not like this varchar can only be these values, but like if this
| field is X, then field Y can only by these values, and field Z is
| now required.
|
| Or, if this date has changed, then it must be a week or more in
| the future.
| graphweaver wrote:
| We add validation using https://github.com/typestack/class-
| validator.
|
| I will make sure we get this documented.
| skeep wrote:
| Super excited that this is finally released! It's been a great
| project to work on, can't wait to see what people build with it.
| graphweaver wrote:
| Thanks for all your hard work skeep!
| timcobb wrote:
| The first thing I look for in these kinds of systems is access
| control, like Hasura has. Not seeing that here. Is that planned?
| Did I miss it?
| graphweaver wrote:
| We have some docs on that here:
|
| https://graphweaver.com/docs/implementing-authorization
|
| The auth is at the access control is at the API layer.
| eddd-ddde wrote:
| Would something like Postgres RLS be enough?
| andy_ppp wrote:
| Every piece of magic in your application has the possibility of
| completely screwing you over when you least expect it. This
| includes all your dependencies and especially your backend. Given
| how trivial it is to write a real GraphQL API in frameworks these
| days, where you have complete control, it's likely better to add
| that to your skill set rather than trusting a one size fits all
| solution that unlikely to solve every problem.
| jrockway wrote:
| I don't think a GraphQL to SQL compiler is strictly a bad idea.
| It is kind of like allowing forum users to post HTML-formatted
| comments; you absolutely can't pass it through unmolested, but
| you can parse the HTML and walk the AST to emit a safe subset
| when you're displaying the comment. Basically, this sort of
| thing is very easy to get wrong, but it's not an intrinsically
| unworkable idea. At the end of the day, the backend database
| does the same thing; a connection says "SELECT foo FROM bar"
| and it has to decide whether or not the current user is allowed
| to do that.
|
| To some extent, this is kind of reverting to "old times". Back
| in the day, client applications connected directly to the
| database and the database handled auth. There is no real reason
| to not let Javascript apps running in the browser to do that,
| modulo implementation details (hello popular database with a
| 100 connection limit out of the box). With that said, I remain
| unconvinced about whether the modern SPA architecture is the
| right thing. In a day and age where everyone has gigabit fiber
| or 5G running over HTTP/3 to a replica of your website hosted
| in the same city as your ISP, is downloading HTML on every
| click really that bad compared to making power-savvy devices
| parse and compile your application every time they visit it?
| graphweaver wrote:
| This is true but like with any build there are many decisions
| to make. We have settled on this stack for our API's and we
| think others will find it useful.
___________________________________________________________________
(page generated 2023-08-27 23:01 UTC)