I would have thought GraphQL was much worse in performance compared to an ORM. The second surprise is how close the ORM and GraphQL is. What is a surprise though is how much worse the mapper performs compared to handwritten SQL. The overall picture is no surprise, plain SQL is fastest, GraphQL is slowest and the SQLX mapper and the ORM in between. Looking at the performance of each of the solutions yields some surprises. I’m thankful for any feedback on how to make code run faster or optimize configurations. I’m not interested in faking a benchmark but in getting some insights. I’m also no specialist in pgx, sqlx, GORM or Graphjin. PerformanceĬaveat: I"m not a specialist in benchmarking Go. The query returns JSON which we can directly feed into the template. I use Golang with Graphjin for GraphQL, GORM for the ORM and PGX for the bare-bones SQL solution. We compare a GraphQL solution to bare-bones SQL and to an ORM. Lets evaluate how to use GraphQL to render server side HTML templates. We implement a page that displays all Tasks for one user with the User and the Status. We want to see the read part of a web application can benefit from GraphQL.Īs an example we use a simple Task app, with Tasks that have a User attached and a Status. Why would one use different code for reading and writing to the database? From my experience reads and writes scale differently, and while it may seem advantages to use the same code for reading and writing, it often complicates changing code. We focus on the reading side of data, not writing it. In the best case you write an HTML template and a GraphQL query without any other code. So with the rise of GraphQL I’ve wondered if GraphQL would be even better than an ORM to write data views in applications. But GraphQL seems a concept that makes reading data from one or more data sources easy. Direct SQL is faster and has fewer model lines of code, but is more difficult to change.Īlthough many developers reflex today is to go to React and a SPA with GraphQL, it is much less code to write an server side application that produces HTML. The ORM saves writing SQL code but costs performance and increases the need for more classes. When writing server side code to read data from a database developers usually use either direct SQL or an ORM. So should we use SQL as the simplist thing or something different? Radical Simplicity doesn’t mean to use Assembler code or C. This keeps maintenance costs down and makes changes cheap and easy. Radical Simplicity is about having the fewest systems possible and the least lines of code and configuration. I did the best on the article but I might have made mistakes in the code or testing setup and appreciate all feedback. Stephan Schmidt Comparing SQL, SQL JSON, ORM and GraphQL performance in Golangĭoes using GraphQL for Radical Simplicity work? □ We see the AI Endgame for Software Engineering.⌚ Why Everything Takes Longer and Longer in Growing Startups.Startup CEOs learned Engineering Management from Captain Kirk.Scrum is no longer fit with remote work.Comparing SQL, SQL JSON, ORM and GraphQL performance in Golang.Remote Work and Fair Developer Salaries.How to Outsource Development Successfully.AMAZING CTO Newsletter - 6 reasons to signup.
0 Comments
Leave a Reply. |