3 ms·

I’m sure Haskell is great, just saying its a bit of a risk to add to your stack if you don’t already have Haskell developers in house. That, and the AGPL issue

by mikl 8y ago

I’m sure Haskell is great, just saying its a bit of a risk to add to your stack if you don’t already have Haskell developers in house. That, and the AGPL issue are both more important in this case (compared to MongoDB), because of the position in the stack that Hasura GraphQL Engine (HGE) would have. In the MongoDB case, we would almost always have an application server between Mongo and the GraphQL client, where custom business logic could be implemented, so Mongo can be treated as an external system whose source code we do not need to modify (like PostgreSQL in the case of HGE). In case of HGE, the GraphQL client would talk directly to HGE, and thus any customisation would most likely need to happen inside HGE, whether by plugins or patches or whatnot, making it tricky to avoid having to open source your custom business logic (as well as probably having to write it in Haskell).

tango12 8y ago
Ah! That's interesting. We didn't intend for Hasura to be something like a boilerplate that you would modify. Mostly because it's harder to work with upstream changes when you work with OSS software like that unless it's an explicit library type dependency. What OSS service type component do you use (know of?) that is used in this way? Currently, we encourage users to use GraphQL schema stitching to customise their GraphQL schema/resolvers treating HGE almost as an external GraphQL service.
- mikl 8y ago
  I see. Maybe I’m too much of a pessimist, but I imagine most products would need custom server-side business logic, and that business logic would also need to talk to the database. So I guess you could put your own GraphQL server in the middle and just proxy some queries to Hasura and answer others with your own custom code. But if you’re already building a separate GraphQL server with database integration, the business case for HGE is weakened, since you might as well build the same logic in the other system.

by mikl 8y ago

tango12 8y ago

Ah! That's interesting. We didn't intend for Hasura to be something like a boilerplate that you would modify. Mostly because it's harder to work with upstream changes when you work with OSS software like that unless it's an explicit library type dependency. What OSS service type component do you use (know of?) that is used in this way? Currently, we encourage users to use GraphQL schema stitching to customise their GraphQL schema/resolvers treating HGE almost as an external GraphQL service.

mikl 8y ago
I see. Maybe I’m too much of a pessimist, but I imagine most products would need custom server-side business logic, and that business logic would also need to talk to the database. So I guess you could put your own GraphQL server in the middle and just proxy some queries to Hasura and answer others with your own custom code. But if you’re already building a separate GraphQL server with database integration, the business case for HGE is weakened, since you might as well build the same logic in the other system.