5 ms·

GraphQL is such a quality of life upgrade coming from this environment, especially at the scale where your frontend teams are potentially larger and shipping mo

by nrb 5y ago

GraphQL is such a quality of life upgrade coming from this environment, especially at the scale where your frontend teams are potentially larger and shipping more than the teams closer to the SQL can provide.

tored 5y ago
GraphQL is a consequence of the SPA design, a bad design leads to a worse fix. The drawback is that the frontend now has its own schema, often it starts as a naive direct mapping of the real schema. Thus any changes in the real schema also need to change the frontend schema and every use of it, or the mapping to the frontend schema needs to change. Eventually these two schemas will diverge because it is not feasible that every schema change results in frontend change. Especially if the idea is to have two different teams working from either side, then the backend team can’t wait for the frontend team therefore the schema mapping will change. And the thing is that the frontend shouldn’t be aware of how the backend schema is constructed, if the User model is separated into three different tables, because of some technical reason, that should not change how the frontend operates. The frontend understanding of what a User is shouldn’t be the same as the backends. Therefore ideally frontend schema and the backend schema will always differ. They don’t view the world the same way. However what you now have is a slow mapper between the frontend schema and backend schema. The point of relationship databases is that you can view your data from different perspective by doing different SQL queries. That is already built in. But now we have invented yet another layer on top of SQL, usually in combination with the already monstrosity called ORM.
- tekknik 5y ago
  What a tortured usage of GraphQL. Schema files are automatically generated by the backend, and components pull data that they need, and know more. If you find yourself changing schemas constantly, then you’re not defining them in a scalable manner. You’ve basically misused the tech, and blamed it on the tech instead of your misuse.
  - tored 5y ago
    That is even more horrible what I thought. Automatically generate schemas 1:1 and then expose it. Let me guess tons of information leakage, ddos attacks and queries not hitting indexes. This is absolutely the worst idea I come across in web development. Horror.
midrus 5y ago
GraphQL is just another artificial solution to a problem created by SPAs themselves. Same as SSR, hydration, server components, client side routers, dynamic bundles loading, dynamic translations loading, etc, etc, etc. A whole industry of workarounds for a broken idea. Now 10 years after SPAs became popular we starting to approach a point were we almost have what we already had.
int_19h 5y ago
What I really don't get is why we don't just expose SQL directly at this point. Is it just security? Database servers have fairly extensive authentication and authorization models.
- tored 5y ago
  Just give the end user an account to phpMyAdmin. Done. No complex frontend framework required.
  - littlecranky67 5y ago
    You wouldn't belive how often companies use excel with external datasources like this. Excel basically is the common-ui for a lot of people. And most of the projects I worked on in my professional career as a webdev, were replacing such workflow with a proper web application, because excel does not scale and eventually people fuckup their data.
- qw 5y ago
  Even if you solve the security issue, a query can easily bring down the server if it has a complex join query. This could be solved by only exposing stored procedures, but that just moves the code to the database server instead of the REST service with the same problems as before.
  - tored 5y ago
    You can also use a VIEW. How does GraphQL make sure to respect table indexes? If not you get a super slow query.
    - qw 5y ago
      You can still get performance issues with a view if you "select *" on a large amount of data, or join with other views. By exposing the SQL to a web page, you also open up for DDoS attacks more easily, as you can write complex SQL queries You can get the same problems with GraphQL or stored procedures too of course, if the queries are not optimized correctly

by nrb 5y ago

tored 5y ago

GraphQL is a consequence of the SPA design, a bad design leads to a worse fix. The drawback is that the frontend now has its own schema, often it starts as a naive direct mapping of the real schema. Thus any changes in the real schema also need to change the frontend schema and every use of it, or the mapping to the frontend schema needs to change. Eventually these two schemas will diverge because it is not feasible that every schema change results in frontend change. Especially if the idea is to have two different teams working from either side, then the backend team can’t wait for the frontend team therefore the schema mapping will change. And the thing is that the frontend shouldn’t be aware of how the backend schema is constructed, if the User model is separated into three different tables, because of some technical reason, that should not change how the frontend operates. The frontend understanding of what a User is shouldn’t be the same as the backends. Therefore ideally frontend schema and the backend schema will always differ. They don’t view the world the same way. However what you now have is a slow mapper between the frontend schema and backend schema. The point of relationship databases is that you can view your data from different perspective by doing different SQL queries. That is already built in. But now we have invented yet another layer on top of SQL, usually in combination with the already monstrosity called ORM.

tekknik 5y ago
What a tortured usage of GraphQL. Schema files are automatically generated by the backend, and components pull data that they need, and know more. If you find yourself changing schemas constantly, then you’re not defining them in a scalable manner. You’ve basically misused the tech, and blamed it on the tech instead of your misuse.
- tored 5y ago
  That is even more horrible what I thought. Automatically generate schemas 1:1 and then expose it. Let me guess tons of information leakage, ddos attacks and queries not hitting indexes. This is absolutely the worst idea I come across in web development. Horror.

midrus 5y ago

GraphQL is just another artificial solution to a problem created by SPAs themselves. Same as SSR, hydration, server components, client side routers, dynamic bundles loading, dynamic translations loading, etc, etc, etc. A whole industry of workarounds for a broken idea. Now 10 years after SPAs became popular we starting to approach a point were we almost have what we already had.

int_19h 5y ago

What I really don't get is why we don't just expose SQL directly at this point. Is it just security? Database servers have fairly extensive authentication and authorization models.

tored 5y ago
Just give the end user an account to phpMyAdmin. Done. No complex frontend framework required.
- littlecranky67 5y ago
  You wouldn't belive how often companies use excel with external datasources like this. Excel basically is the common-ui for a lot of people. And most of the projects I worked on in my professional career as a webdev, were replacing such workflow with a proper web application, because excel does not scale and eventually people fuckup their data.
qw 5y ago
Even if you solve the security issue, a query can easily bring down the server if it has a complex join query. This could be solved by only exposing stored procedures, but that just moves the code to the database server instead of the REST service with the same problems as before.
- tored 5y ago
  You can also use a VIEW. How does GraphQL make sure to respect table indexes? If not you get a super slow query.
  - qw 5y ago
    You can still get performance issues with a view if you "select *" on a large amount of data, or join with other views. By exposing the SQL to a web page, you also open up for DDoS attacks more easily, as you can write complex SQL queries You can get the same problems with GraphQL or stored procedures too of course, if the queries are not optimized correctly