I've tried Hasura and really liked it, but there were a few quirks that led me to another tool, but in general, the whole idea that tools like Hasura, PostgREST, pREST and PostGraphile are trying to solve are the future.
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.
Hasura is a boon to productivity and keeps gaining very useful features. I really wish they had a hosted version (like netlify); I don't want to manage servers.
Just for clarity: they offer a commercial license, for money. If you work for a company that doesn't like AGPL, perhaps they're more comfortable with paying money for software? Those two tend to go hand in hand, in my experience.
(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.
> 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?
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.
AGPL is pretty much a non-starter for us. It's simply viewed as too risky a license. Thanks to jacues_chester for pointing out the license. The project sounds super cool but there is simply no point in my looking into it on account of that licensing decision. You're shaking my confidence in your decision making, Hasura.
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.
Are you a lawyer? A great deal many lawyers have reviewed the AGPL and labeled it too risky for their companies. While I tend to agree with your interpretation of it, I still am extra cautious and avoid AGPL software when I can for infrastructure products like this. I am cautious because of the lawyers opinions on it, and I am also cautious because many companies that adopt an AGPL license turn out to be not very good open source stewards, and they put up roadblocks to community contributions that weaken the project and make having a real open source community behind the projects nearly impossible. There are some exceptions, but they are rare, so I exercise extreme caution around AGPL licensed products.
"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.
Many, many companies have blanket bans on AGPL software because they'd rather not take on the risk of accidentally violating it. It might be silly, but it's true.
I was interested in whether it could be used in Concourse, which is Apache 2 licensed. I wanted a better way to extract data without adding lots of new endpoints.
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.
That's the GPL, which only concerns itself with the distribution of (derivative) works. If you modify GPL'ed software for your own use, without distributing it, you can keep your modifications for yourself.
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.
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!
No. The tool also creates relationships based on foreign key references using Hasura. So to query all the users with the child users, you would make a GraphQL query like:
query {
user {
id
name
childUser: userByUserId {
id
name
}
}
}
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've tried Hasura and really liked it, but there were a few quirks that led me to another tool, but in general, the whole idea that tools like Hasura, PostgREST, pREST and PostGraphile are trying to solve are the future.
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.
Can you share what tool was the final choice and what were the quirks that influenced your decision?
Hasura is a boon to productivity and keeps gaining very useful features. I really wish they had a hosted version (like netlify); I don't want to manage servers.
This looks setup pretty compelling, but it would still be nice to have an easy to use abstraction on top of it:
https://dev.to/lineup-ninja/deploying-hasura-on-aws-with-far...
I was excited to see graphql-engine, but unfortunately the AGPL is a bit hard to pitch to folks in an enterprise software context.
Just for clarity: they offer a commercial license, for money. If you work for a company that doesn't like AGPL, perhaps they're more comfortable with paying money for software? Those two tend to go hand in hand, in my experience.
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.
> 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?
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.
Hey, I'm from Hasura.
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 is pretty much a non-starter for us. It's simply viewed as too risky a license. Thanks to jacues_chester for pointing out the license. The project sounds super cool but there is simply no point in my looking into it on account of that licensing decision. You're shaking my confidence in your decision making, Hasura.
(I am not from Hasura.)
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.
Are you a lawyer? A great deal many lawyers have reviewed the AGPL and labeled it too risky for their companies. While I tend to agree with your interpretation of it, I still am extra cautious and avoid AGPL software when I can for infrastructure products like this. I am cautious because of the lawyers opinions on it, and I am also cautious because many companies that adopt an AGPL license turn out to be not very good open source stewards, and they put up roadblocks to community contributions that weaken the project and make having a real open source community behind the projects nearly impossible. There are some exceptions, but they are rare, so I exercise extreme caution around AGPL licensed products.
Things like this, https://www.ghostscript.com/faq.html in the 'Can I embed Ghostscript in my own apps?' section:
"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.
Many, many companies have blanket bans on AGPL software because they'd rather not take on the risk of accidentally violating it. It might be silly, but it's true.
That last sentence took things from constructive/informative to not helpful.
I was interested in whether it could be used in Concourse, which is Apache 2 licensed. I wanted a better way to extract data without adding lots of new endpoints.
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.
I thought the AGPL was corporate-friendly, RMS-unfriendly. Doesn't it allow for the "nonfree" distribution in SaaS/API context?
(Am I allowed to describe an API business as SaaS? My [technical, without a business background] partner says no.)
That's the GPL, which only concerns itself with the distribution of (derivative) works. If you modify GPL'ed software for your own use, without distributing it, you can keep your modifications for yourself.
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.
I had the names mixed up.
Sorry for the insistence, but is an API-only product still SaaS as far as the Affero license goes?
Certainly.
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!
>MIT/BSD, on the other hand, are about developers.
Also, as a developer without much legalese, MIT/BSD are easier to read and understand.
Is there some way to make data available to specific users, but unavailable to others? Basically enforcing an ACL or similar?
Yep! Hasura allows you to configure access control rules which are namespaced by "roles" that you can attach to your tables.
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-...
This is awesome but how do you deal with circular references?
It works with circular references. For example, this works:
Do you have anything else in mind?PS: Co-author here
But then to go from user 456 to user 123 via the field user_id do I have to do a linear search of all users to check their IDs?
No. The tool also creates relationships based on foreign key references using Hasura. So to query all the users with the child users, you would make a GraphQL query like:
The response would be: Did I answer your question?Those child users don't then have their own child users (because it's cyclic) so do you have to choose one option of the two, both with a drawback?
I was thinking you could replace or supplement the real user IDs with their indices in the array of returned users.
I am sorry, but if possible, could you elaborate @chrisseaton? (preferably with a bit more punctuation :D)
With more punctuation? What's that supposed to mean? I've written two short sentences. It's not some wall of text.
So, is a hypothetical scenario, an employee that is their own supervisor?
Yes, but I'm not sure if you're implying that it's a nonsensical situation with that example. Lots of real-world graphs have genuine cycles.
For a good example of unexpected cycles you can see this classic question on genealogy software:
https://stackoverflow.com/questions/6163683/cycles-in-family...
... wouldn't the second line have to be "user_id": 456, in order to really be circular?
Circular references basically mean that a table is referencing itself. Any row in the table could reference any row.
For other related automatic GraphQL tools that create realtime subscriptions to queries, check out https://github.com/brysgo/graphql-gun
I'm curious though, with Postgres, how does the realtime aspect work?
Is your code heavily dependent on Postgres or it works with any SQL store ?
(I'm from Hasura)
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'm exploring GraphQL for a legacy MySQL database right now and the only option I can see is based on Sequelize, which we don't use.
I'd love MySQL support!
Noted!
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.
[1] https://www.symmetricds.org/
Would you consider a noSQL query language?