A: In 5 years time there are so many features planned to be added to Hasura. Have you seen our new Remote Joins feature? It already gives you an ability to basically connect your GraphQL API to anything you want - third party microservices, other dbs, your custom servers etc.
# Q: Is there any timeline for Hasura potentially supporting other major DBMS besides PostgreSQL? Many huge enterprises still seem to use things like MS SQL Server. – Shaikat
# Q: Any plans to support MySQL? – krvajal
A: There is a plan to support MySQL, but I don’t know about the exact timeline. Right now we are focused more on Remote Joins, so you can join your GE with literally anything. MySQL joins is also possible btw.
# Q: Do you imagine the world without GraphQL, if not, why? Any specific example… – web2.0opensource
A: Well it’s easy to imagine a word without this or that tech. After all we all saw how tech has evolved. But with modern application demands GraphQL and serverless is absolutely must.
# Q: Are there any ETA on an official stable version of HGE? I’ve been using alpha 13 in production for a year without any bugs. Make an official release would help me selling HGE easier to my customers. – thangngoc89
A: For v1 release ETA is 4-6 weeks. hopefully 😉.
A: Prisma and Hasura are in the same ecosystem but way different. Prisma is basically an ORM when Hasura is an API engine that your apps can use directly and an event engine for your backend code. Also it has granular access control, authentication support and recently remote joins that will give you an ability to connect any of your microservices/third party apis or databases. We wrote a blog post a while ago about the differences: https://blog.hasura.io/hasura-vs-prisma-9ffc7271eda8/.
# Q: How can Machine Learning use GraphQL to assist people on daily activities… Any specific example? – web2.0opensource
A: Machine learning can use GraphQL for anything on data layer. So basically your Machine learning will use let’s say something like TensorFlow, but you will still need to get and store the data, interact with your backend and so on.
# Q: Is there any recommendation from your experience to people working on the newspaper platforms? These are very dynamic and need to represent information from a wide domains. – web2.0opensource
A: Yeah, there is actually a blog post from David Eads from ProPublica about newspaper platform which is built in Gatsby, Hasura and PostgreSQL. https://www.propublica.org/nerds/the-ticket-trap-news-app-front-to-back-david-eads-propublica-illinois
# Q: How would you handle files upload in Hasura? AWS AppSync makes it extremely easier to do so. Currently, my workflow would be hitting an endpoint to get a signed url for uploading to AWS S3. and then use a different code path to upload the file. I wish I could do everything via Hasura and GraphQL. – thangngoc89
A: Since you cannot send binary files with GraphQL, you will still need to upload them somewhere using regular REST endpoint, but what you can do is fire a lambda once S3 upload is done. Lambda will execute a mutation into Hasura and you will get subscription on file uploaded.
Follow up: Ah hah, that is something I don’t need to do. because I upload the files directly to S3 on the client. but using lambda to notify the database about the uploaded file is an interesting idea. Thank you @vladnovick.
# Q: Currently using Prisma for a multi-tenant application. I am using the tenant_id approach. Since Prisma 2.0 is now using Rust; do you still think that Hasura has a competitive edge over performance? Lastly how easy is it to migrate from Prisma to Hasura (keeping in mind I have multiple Prisma resolvers). – kc
A: Well as for performance I haven’t checked Prisma 2 performance yet, but you can check our performance benchmarks here: https://github.com/hasura/graphql-engine/blob/master/architecture/live-queries.md. As for if you can use any Prisma resolvers or migrate, you can basically can use any GraphQL endpoint to add remote joins to Hasura, so you can just reuse your existing resolvers with Hasura adding them as remote joins and connecting them to database. Moreover if you are running on PostgreSQL, engine will auto generate everything for you so you will need to focus only on business logic. I don’t think the difference is the language as much as it is the approach. If you can create a single SQL query from a complex GraphQL query you will see Hasura like performance. Hasura can do this because Hasura can mix access control and auth rules into the single SQL query directly. If you have resolvers that call an ORM, it would be hard to construct that one query I think.
# Q: What are the best package choices in the React Native ecosystem? – Niz
A: For interaction with GraphQL you can use an Apollo client. Actually we created tutorial series how to do that, so you can check them out on learn.hasura.io. And if you are asking generally about React Native packages not related to GraphQL, then I would go with ignite cli tool by the infinite.red team for best practices.
A: As we move into GraphQL ecosystem people tend to migrate to SQL/PostgreSQL because it has so much to offer in various things. First of all SQL is really mature language, second Postgres and it’s extensions are just amazing and really performant. You can check the following benchmarks for example: https://www.enterprisedb.com/news/new-benchmarks-show-postgres-dominating-mongodb-varied-workloads.
A: What would you be interested into? We have integrations with cloud vendors, but all of them use Docker under the hood so you don’t use it directly. Also soon we will provide a binary version to run locally.
# Q: What’s your number one tip for GraphQL schema design? – Oli
A: Auto generate schema 😉. Powerful APIs are hard to build and especially manage by hand. Also make sure you solve n+1 problem. BTW we don’t have this problem in Hasura because Hasura is basically a compiler and we compile to one single SQL statement and execute it using PostgreSQL native features.
# Q: Hi! do you think in a world leaning towards NoSQL databases, what is in your opinion the future of Relational RDBMs? – nicandro
A: I would argue on the fact that a world leaning towards NoSQL databases. While they have their own use cases, recently there is a major switch towards relation RDBMS such as PostgreSQL and its extensions such as PostGis or TimescaleDB. MySQL is also evolving to support multiple types of workloads.
A: I would better share a blog post about that, since it’s a pretty broad topic to write about in chat. https://blog.hasura.io/architecture-of-a-high-performance-graphql-to-sql-server-58d9944b8a87/
# Q: It is known that Browser DOM is slower then Virtual DOM (IDK exactly why but I assume rendering stuff), but there is one thing I don’t understand: When there is a state update React is diffing the old VDOM with the new VDOM (which is created completeley from scratch with the updated state right? (side question)). In the and React calculates a “patch” to update the browsers DOM. So in the end you still have to update the browser DOM. Why is it so much more expensive (performance wise) to update the browsers DOM directly? You wouldn’t even need the diffing and so on… – Flaneder
A: React has its specific mechanism called React Fiber. You can read more about it here: https://github.com/acdlite/react-fiber-architecture.
A: I would suggest learning React on egghead.io. Amazing platform with amazing courses. And the best way to keep up with React updates is to follow people on twitter, go to confs / watch conf talks.
A: Hasura with Gatsby is amazing. Gatsby gives you server rendered static site and Hasura gives you real time GraphQL API that connects with Gatsby so smooth. Recently we also did a stream about Authentication with Hasura and Gatsby.
A: We haven’t thought about it yet actually.
A: You can implement two-factor using various services. Let’s continue discussion on discord.gg/hasura about that.