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.
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.
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?
Bandwidth is not the only factor affecting the thick/thin client economics [2]
Compute is the big factor , unless your app needs fast load times to make money like e-commerce, cmses etc the trade off of paying for additional compute on the server side is not worth it .[1]
Today the browser handles most of the app and Auth state token refreshes, inflating data into an UI, a lot of the validations , all these components on the server costs more compute cycles which someone has to pay for.
If is always cheaper for the user than application developer , the app developer is renting every cycle compared to the user who has already bought a powerful device
Same reason Stadia and similar stacks have hard time proving their economic viability, if they are not able to create a large enough market of users who will not buy a high end device but will be ready to pay for a sub for somewhat poorer experience then they fail .
Also from development point of view you would need to likely maintain a separate API anyway for your native mobile apps , building a server rendered [1] app and API is not worth the development cost usually.
[1] SSR and various hydration tooling blur this line ever in favor of SPAs but I am ignoring that to keep the point simple
[2] hardly everyone has always on 5G or fiber access in developed G-20 economies let alone the world , YouTube and dozens app charge for downloading for a reason
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.
Could you expand on how security is an afterthought in Postgraphile? My experience of using RLS and the graphile pro plugin was nice and secure imo. Curious if I missed something here
So I have a list of my own stuff but I want for other people who are in my circle to be able to see outfits I've shared with them. If all the lists of stuff are created in an automated way doing things like this is somewhat harder than the default crud stuff and managing passing tokens and doing the filtering is fine but feels like a use case that should be as automatic as possible. I haven't used the Pro plugin, I'm not sure if we knew about it or what it does.
- 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)
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:
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.
Yeah sorry will address it directly. Graphweaver is different in a number of ways:
- Graphweaver is not just Postgres, you can run it connected to only MySQL
- Graphweaver can connect to one or more datasources. You can even connect both MySQL and Postgres together. Sounds crazy but could be good for a migration.
- Graphweaver has two layers the API layer and the Data layer. Both of these are represented by coding classes in Typescript. You have full control over how these are exposed and defined in the entity files.
- Graphweaver does not automatically reflect the database. Instead you run an import command in our CLI tool that creates Typescript class files for your database. From there you can edit them as needed.
Nice, interesting approach. I like Mikro ORM, I was thinking about building on top of it recently, I think it's a good idea.
Looks like you went for the ORM equivalent of the Shadcn/ui approach. "We generate your code so you can customize it" instead of the more traditional "You use a library and can provide options to it to customize it". I like it!
Postgraphile has a bunch of very cool filtering/grouping capabilities (with plugins), would be nice to have that at some point