javascript Tag

Learning how to write a GraphQL server is one of the biggest challenges I've seen for those who are new to GraphQL. This is because it requires a change in mindset, especially if you are accustomed to writing REST servers. Specifically, instead of thinking in terms of implementing individual endpoints in isolation, you have to think in terms of implementing an entire GraphQL schema that can be queried in any way.

This need for flexibility can cause anxiety for some developers, especially when it comes to performance. To deal with these concerns, some developers panic and pre-emptively reduce the flexibility of their GraphQL schema to head-off anticipated issues. But in doing so, they start to negate the chief benefit of using GraphQL in the first place: being able to flexibility and efficiently access data over a network as slow and laggy as the internet. Taken to the extreme, developers can even end up in a situation where they're paying all of the additional cost of using GraphQL, but not reaping any of the benefits.

It's true that strictly speaking, the easiest way to write a GraphQL server isn't necessarily the most performant, especially in comparison to writing an equivalent REST server. This is part of the trade-off of using GraphQL. However, it's also true that the majority of the time, this performance difference won't be noticeable to the end user. Furthermore, even if it turns out that there is an actual performance problem, there are plenty of mechanisms available to deal with it, without compromising your schema.

In this post I'm going to show you an example of a common source of performance anxiety for GraphQL server developers, and how it can trick them into thinking that they're going to have to make adjustments to their schema to deal with it. I will then present an alternate approach that allows the best of both worlds - a performant solution and the simplest schema possible. In this case I'll be using Apollo Server to write the server. I'll be assuming you have some knowledge of both GraphQL and Apollo Server.

Shine’s TEL group was established in 2011, like the date is important. We publicise the great technical work that Shine does, and raise the company’s profile as a technical thought-leader in the community through blogs, local meetup talks, conference presentations, and tattooing our logo on drunk developers. We curate all the noteworthy things that Shiners have been doing and publish a newsletter that nobody reads. Join us for a slightly festive edition. After all, nobody does Christmas better than corporate blogs.
Shine’s TEL group was established in 2011, initially as a three-piece old-school-bebop Jazz combo but expanded to include a horn section during our worldwide tour of Iceland. We publicise the great technical work that Shine does, and raise the company’s profile as a technical thought-leader in the community through blogs, local meetup talks, conference presentations, and driving around shouting out of car windows. We curate all the noteworthy things that Shiners have been up to and publish a newsletter that nobody reads.
Shine’s TEL group was established in 2011, initially to share jam-making recipes. We publicise the great technical work that Shine does, and raise the company’s profile as a technical thought-leader in the community through blogs, local meetup talks, and conference presentations. We curate all the noteworthy things that Shiners have been up to and publish a newsletter, this very one that you're reading right now. Hey, when you read this, whose voice do you hear in your head? Is it mine? Or yours? Everything I read is in Frank Walker from National Tiles' voice, please help me. Read on for this edition.
Shine’s TEL group was established in 2011, initially as a money-laundering operation. We publicise the great technical work that Shine does, and raise the company’s profile as a technical thought-leader in the community through blogs, local meetup talks, and conference presentations. We curate all the noteworthy things that Shiners have been up to and publish a newsletter, in accordance with a mystical schedule that you wouldn't understand. Read on for this edition.
Shine’s TEL group was established in 2011 with the aim of publicising the great technical work that Shine does, and to raise the company’s profile as a technical thought-leader in the community through blogs, local meet up talks, and conference presentations. Every now and then (it started off as being monthly, but that was too much work), we curate all the noteworthy things that Shiners have been up to, and publish a newsletter. Read on for this month's edition.

Intro

Post update: My good friend Lak over at Google has come up with a fifth option! He suggests using Cloud Dataprep to achieve the same. You can read his blog post about that over here. I had thought about using Dataprep, but because it actually spins up a Dataflow job under-the-hood, I decided to omit it from my list. That's because it will take a lot longer to run (the cluster needs to spin up and it issues export and import commands to BigQuery), rather than issuing a query job directly to the BigQuery API. Also, there are extra costs involved with this approach (the query itself, the Dataflow job, and a Dataprep surcharge - ouch!). But, as Lak pointed out, this would be a good solution if you want to transform your data, instead of issuing a pure SQL request. However, I'd argue that can be done directly in SQL too ;-) Not so long ago, I wrote a blog post about how you can use Google Apps Script to schedule BigQuery jobs. You can find that post right here. Go have a read of it now. I promise you'll enjoy it. The post got quite a bit of attention, and I was actually surprised that people actually take the time out to read my drivel. It's clear that BigQuery's popularity is growing fast. I'm seeing more content popping up in my feeds than ever before (mostly from me because that's all I really blog about). However, as awesome as BigQuery is, one glaring gap in its arsenal of weapons is the lack of a built-in job scheduler, or an easy way to do it outside of BigQuery. That said however, I'm pretty sure that the boffins over in Googley-woogley-world are currently working on remedying that - by either adding schedulers to Cloud Functions, or by baking something directly into the BigQuery API itself. Or maybe both? Who knows!
Shine’s TEL group was established in 2011 with the aim of publicising the great technical work that Shine does, and to raise the company’s profile as a technical thought-leader in the community through blogs, local meet up talks, and conference presentations. Every now and then (it started off as being monthly, but that was too much work), we curate all the noteworthy things that Shiners have been up to, and publish a newsletter. Read on for this month's edition.