Show HN: Json2graphql – From a JSON file to Postgres-backed realtime GraphQL
github.com
github.com
Server side frameworks are obsolete. ORMs are decrepit meta-models and log hewing busywork. Mapping an already powerful model onto one that is less powerful, eating gigabytes of ram to run JVM/Python stacks, countless rolling and restarting of processes. So many hand-rolled loops of code that could just be joins. Multiple queries to smash together two datum that could just be views all in so many thousands of lines of pointless code.
Postgres is already object-oriented, and has been for decades. It already speaks JSON and has for almost 10 years now. It can speak a number of languages, including Python and Javascript, right in the database. Postgres not only stores your data, it knows your data, the statistical distribution and selectivity of queries. No ORM system maintains this kind of optimization state when they generate SQL.
The real power of tools like Hasura is that they get out of the way. They encourage the use of views, functions, extensions, all the powerful stuff that's native to Postgres.
Who cares if it runs on MySQL? The idea is so simple that MySQL can have its own version that gets out of the way and leverages the core power of MySQL. The idea is not to have more frameworks, but to have fewer.
https://dev.to/lineup-ninja/deploying-hasura-on-aws-with-far...
Out of curiosity, did you face trouble trying to get something like Mongo running in the same enterprise context? Especially back when they were AGPL?
We've put up an explanation reg. our AGPL licens here: https://github.com/hasura/graphql-engine/wiki/License-Explai...
AGPL only makes a difference if you link that program and your own code together into one executable (including through dynamic linking). If you're calling from another executable over an API then it makes no practical difference whether it's AGPL, regular GPL or even BSD-style. This is, by definition, a remote API so you'd really have to make an effort to infect your code with the licence.
Just saying "it's too risky" sounds like ignorance. Like if I refused to compile my code with GCC because I heard GCC has a GPL licence. There's not much that vendors can do to counter an attitude like that.
"The AGPL explicitly prohibits the deployment of AGPL software in a SaaS (Software as a Service) environment unless all of the software on the server (including the operating system software) is also released under the AGPL with full source code."
BS like this confuses the otherwise very clear language of the license itself. Removing the arms-length uses of GS from our SaaS because nobody wants any possible legal problems.
AGPL just doesn't work for anyone downstream who has to answer to enterprise customers. Pivotal, where I work, is the main sponsor for Concourse and so finds itself in that position.
(Am I allowed to describe an API business as SaaS? My [technical, without a business background] partner says no.)
SaaS companies were (ab)using that bug by using GPL'ed software in their stack, but never distributing the code: they just rent out use of their machines to others. Therefore they don't need to distribute their own source code.*
The AGPL fixes that "bug" by including the SaaS "software on demand" in the definition of "distribution".
That's my understanding, as a layman AGPL fan. :)
*Where relevant. There are many scary stories about the overreach of the (A)GPL, but it's not always that bad. E.g. if you just use an AGPL'ed database, not embedded or linked but really like a DB with a separate connection, then your code is not under AGPL. Again, from my understanding as a layman.
Sorry for the insistence, but is an API-only product still SaaS as far as the Affero license goes?
To understand the GPL family, here's a rule of thumb: they try to ensure to freedom of the software user, not the software developer. The GPL restricts the freedom to restrict freedom. It goes out of its way to ensure users retain their freedom when using software, including the freedom to see the source code and modify it. In interviews, RMS often talks about his frustrations as a software user. From this point of view, the GPL makes more sense. This is also why the GPL is constantly being updated to fix "bugs" which publishers exploit, to circumvent it (TiVoization, SaaS, something else will surely follow).
MIT/BSD, on the other hand, are about developers. They let me, as a developer, do what I want, including restrict my users. This is why they're popular among... developers! :) But if you look at it as a user, it's actually not ideal.
This is a gross oversimplification, but I find it helps put things in perspective. YMMV!
Also, as a developer without much legalese, MIT/BSD are easier to read and understand.
https://github.com/hasura/graphql-engine/wiki/License-Explai...
(The wording is odd, but I parse that as "Commercial licenses ... are available on request.")
EDIT: I have to say, the entitled attitude I'm seeing in this thread towards free software, irks me. It's literally dual licensed. Perhaps if your company is so petrified of contributing back to the community (perish the thought), you could bring yourself to pay money? Closed source software never gets this crap, but woe you if you dare offer your code under the same license family that brought us GCC and Linux! Give me a break. Pay money or accept the AGPL, but please don't bully people who offer the fruits of their labour to the open source community under the most freedom license.
Sorry for the negativity. And many thanks to Hasura.
Well, I like to look at it a different way. The best way for me to comply with the wishes of AGPL licensors is to avoid their code. I am never going to break their terms if I never use their software. I do not intend this in a points-scoring way. I mean it: I am trying to respect their wishes.
Now, if I was the end consumer for graphql-engine, and if it gave me a strong commercial advantage to do so, I think it's fine for Hasura to ask me to choose between the AGPL or a private license. I would probably consider the commercial license because I expect it would come with add-ons, support, influence over the roadmap and so on.
But my use case is to bundle it as a dependency, meaning it would affect people downstream of me. That I can't do.
Each permission rule can reference a session variable that comes in from your authentication system (whatever it is).
Docs: https://docs.hasura.io/1.0/graphql/manual/auth/index.html
Examples: https://docs.hasura.io/1.0/graphql/manual/auth/common-roles-...
{
"user": [
{ "id": 456, "name": "Sita K", "user_id": 123 },
{ "id": 123, "name": "John Doe", "user_id": 123 }
]
}
PS: Co-author here
query {
user {
id
name
childUser: userByUserId {
id
name
}
}
}
{
"data": {
"user": [
{
"id": 123,
"name": "John Doe",
"childUser": {
"id": 123,
"name": "John Doe"
}
},
{
"id": 456,
"name": "Sita K",
"childUser": {
"id": 123,
"name": "John Doe"
}
}
]
}
}
I was thinking you could replace or supplement the real user IDs with their indices in the array of returned users.
https://stackoverflow.com/questions/6163683/cycles-in-family...
I'm curious though, with Postgres, how does the realtime aspect work?
Well, today it is fairly dependent on postgres, but we can add more SQL backends eventually. We also leverage some neat Postgres performance tricks which would have to change depending on the database.
Do you have a database in mind?
Hasura is structured as a compiler that takes GraphQL queries, adds access control rules configured by the user and then generates a SQL query. Adding more SQL backends is supporting more SQL dialects.
I'd love MySQL support!
Not sure if this will help, but one of our users mentioned using symmetricds [1] to sync data from sql-server to postgres and then using Hasura.