Panel Discussion: GraphQL for non-JS Languages

Hi everyone. It's good to see you all. This is a very, I'm really excited to have this panel discussion. I think it's a very interesting subject and I think this discussion actually could continue not only here but in general more. So I hope we all can learn from each other. This discussion is about basically graphql in languages that are not javascript. So I'll be talking least and as little as possible and give everyone here the stage to actually talk about their expertise and their languages and how graphql fits into their languages as well. Because graphql, the whole point of graphql, it's language agnostic and can connect actually between different languages and different ecosystems. So I think that this panel has at least the potential to be very interesting and very productive and very cool. And all my fellow panelists here are amazing people. So I think it will be, I hope it will be great. We'll do a short introduction for everyone, each person. Each person can talk about the language of their choice or languages of their choice and what they do in the day to day. And then we'll just start talking and chatting. I'll start very briefly. I'm Uli, I'm a member of a group called the Guild and we work mostly around javascript, typescript, and rust. So I'll shut up most of the time and I'll hand it over to the rest of the group. So starting with Gabriel. Hey everyone. My name is Gabriel and I'm from Sweden. I work at Arison, which is an IT consultancy and startup incubator here in Stockholm, Sweden. I maintain an open source library called Rescript Relay, which is connecting Facebook's graphql client Relay together with Rescript, which is a programming language. So I'm kind of cheating here because my programming language compiles to javascript. So I guess I'm halfway a member of the panel. I also run an online meetup for Relay, which is called RelayMeetup.com. And yeah, that's pretty much all for me, I'd say. Thanks Gabriel. Alex, and then I'll shut up between the introductions. You can just go one by one. Yeah. Hi, my name is Alex on the firewack. I'm lead frontend engineer at OpenSocial. We build a community experience platform and we're currently in the process of adding graphql to our existing products that is built with PHP and Drupal. One of the things that I've spent a lot of time working on has been building our real time chat, which was trying to make PHP do real time subscriptions was quite an interesting challenge. I bet. That's it. Over to Marcin. Hey, hi everyone. My name is Marcin Gambala and I'm from Wrocław in Poland. So I am a lead backend developer at Sailor Commerce and Sailor is basically an headless e-commerce platform. So I've been using Python for eight years now and graphql for five years. So most of my career with Python, I've been actually using it with graphql. We use Django primarily with Graphene framework, so I can talk a little bit about that. Yeah, I think that's it. Hey everyone. So my name is Jeremy. I am a huge rust fan. So I've been using quite a lot of languages ranging from, I don't know, Python, javascript, typescript, and all this stuff. And I've contributed quite a bit to open source, mainly in rust lang, and I got a chance to join apollo graphql a couple of months ago to work on the rust router, which is super exciting and I can't wait to share more. Hey there, I'm Robert Masalgo. I'm a Ruby on Rails developer and the maintainer of graphql Ruby. And gosh, I live in Virginia in the day to day. I have three young daughters and I like to ferment things. That's it for me. That covers a lot. Hey, I'm Ellen. I am a mobile developer advocate at apollo graphql. I also worked on the iOS SDK for quite a while. I'm going to be talking about Swift and Kotlin. And yeah, I live in Madison, Wisconsin. And yeah, this guy behind me is George Michael. This is great. I mean, there's so much knowledge here, I think. Also different languages and ecosystems with also both client and server and like different languages and ecosystem of the server and different language and ecosystem on a client. There's a lot to talk about. Now I know that usually, especially on Twitter, like starting a discussion about why your language is best is the worst thing to do. But I think here... But I think here, at least in the spirit of learning and everything, I think what I want to maybe make the first question would be, and we can go all around everyone here, what do you think is, let's say, unique about the language you're using? And what do you think are the, let's say, advantages that you get from this language when using graphql compared to other languages? And maybe even not compared to other languages. Just why do you think there's something special there? Because then everyone else can learn from it. So I don't know. Maybe we'll start with Jeremy. Yeah, sure. Wow, that's a good question. I think the main advantages of rust would be, like it's described in the motto, it's hack without fear. I am super happy to have a language that actually helps me to write sound code. And by that I mean once it compiles, it runs. And it runs pretty well. And it's super fast. And I have a compiler that really has my back, right? On the other hand, the learning curve is quite steep at first. So for quite a while, until a couple of months, maybe six months ago or something, I would hack most of my stuff maybe in javascript or using another language where I could just get stuff done. And once I actually understand exactly what I'm trying to do, I would rewrite it eventually. So yeah, I would say it really shines once you know kind of what you're doing and where you're trying to go. But I would probably not use it as the first language in my kit, to be honest. And when you say shines, let's say once you go over that hurdle, what do you think are the main differences, let's say, compared to other languages? And what are the benefits that you get from it, especially related to graphql? Well, when it comes to graphql, basically being like in my previous jobs, for example, the reason why we actually pushed for rust and actually we did rewrite a couple of things from Python or Golang to rust is that the companies I used to work for were cloud native and they had a cloud build. And basically every time you actually shove a couple of CPU cycles, your build goes down. So at a large scale, it actually makes sense to try to find the most performant languages. And there are very performant languages out there, but then you would need to do some heavily multi-threaded stuff and async stuff. And in that space, it's really hard to get it right and to not have your production catch fire on a Sunday. So this is basically why we actually wanted to play around with rust. And yeah, we knew like when the compiler tells you that something is not correct, you basically trust it because at some point it's right, there's some concurrency issue or whatever. So yeah, there's a whole lot of confidence and speed that you gain once you actually understand how to use it, I guess. Cool. Thanks. Alex, what is your experience? Yeah. So I mean, why PHP? PHP still powers like 75% of the web. So it's still ubiquitous. If I start a new project, would I choose it for graphql? Possibly. I think there's a lot of other interesting languages out there. For us, it was also because we were already building a product with PHP and even before we started with OpenSocial as an organization, we were doing PHP. So that is from an organizational standpoint, where the knowledge was. And thankfully, before we began adopting graphql, there were already a lot of people out there building things with graphql. I think one of the things that disappoints me slightly is that the prevailing image of PHP is the image of PHP from five to 10 years ago, which was a lot more difficult to write large scale applications in. But especially with like the most recent releases, you can put types all throughout your system. There's strong static analysis tools that can help you spot bugs. So I think, yeah, even though we were already quite large, we've learned a lot from different languages to improve the developer experience there. That's really cool. Marcin? Yeah. So I think that when it comes to Python, from my perspective, it's like one of the most easy to write and easy to read languages. So it's definitely easy to build and maintain code bases. And I think that it's also a good choice if you want to start with programming, basically. So if you want to just start playing around with the back end stuff and building the graphql server, like using frameworks that are available in Python, it's rather easy to start and easy to use at the beginning. I think that flexibility of Python is also very important here. We have two types of frameworks in Python, schema-first and code-first. Actually there are four frameworks currently in Python that I know about, like Graphene, which is the most popular one, Ariadne, and Strawberry, and Tartiflet, which are a bit smaller ones. But you have a lot of options here. I think most of those frameworks support basically the same features. And Python is also very popular when it comes to web development, I think. At least when I looked at the GitHub survey of programming languages last time, I think it was the second language. But it's also used in machine learning stuff like that. So it plays nice with this topic. So there is a lot of good web frameworks in Python, and all of them support those graphql frameworks. So if you want to start with building web apps, Python is a good choice as well. But we are successfully running a big production e-commerce platform with that as well. That's really cool. Thanks. Robert and Ruby. Sure. I mean, in practice, Ruby's biggest strength is Ruby on Rails. And it sounds like a complementary paradigm to rust. I don't come from a technical background. So for me, you just type some things and you get a website. Tons of businesses begin that way. And if I was going to start a new one, it would begin with Rails new. And if anybody liked it and I started making money, then I would make a graphql api on it. And that's why I loved Ruby to start with. It was just easy to get going. You don't have to understand everything. I think there was a middle period of darkness for me where I was frustrated with how hard it was to analyze statically, to be sure that the code was right. All those things are still true, but I think I have come to terms with it and made peace with it. Some of the bigger companies out there, shopify, Stripe especially, are making investments in language tooling there. But personally, I have come back around to my first love. And I just love that it's easy to get going and you can tune it up and make it fast when you need to. It will never be as fast as multi-threaded rust. There's no compiler to catch errors for you. They're getting there. But I just love how practical it is to get something that works well enough to keep moving. Thanks. Let's do a bit of client-side. Ellen wants to share a bit. Yeah, I'll talk about Swift and Kotlin. Swift and Kotlin are kind of like cousins that were born at the same time. They both sort of came into existence around the same time in 2010, at the end of 2010. And they've both taken a lot of interesting pieces out of a lot of other languages. But there are different things that each of them has baked in that the other one doesn't. So it's interesting to see, even on these sort of cousin languages, just like, here's one cousin that has a Mohawk and here's one cousin that's going to be an investment banker or something. It's definitely one of those things where it's interesting to see. Because again, as a compiled language, you definitely get a lot of the benefits of a compiler. Particularly if you're leveraging the schema to generate code, which is what we do at apollo, that's a huge, huge benefit to being able to use a strongly typed language is essentially being able to know at compile time, hey, is this thing that I'm getting back actually going to go in the place that I'm trying to put it? That's really hugely possible in both Swift and Kotlin. There's definitely some disadvantages to trying to take something that originates from a loosely typed language like typescript, where there's definitely some escape hatches in typescript if you're just like, well, this says that I should be doing this, but I kind of don't want to, so I'm going to do it this other way. I certainly am familiar with that from my years of doing Objective-C, but it's something where you do have to do a lot of work to sort of jam it into a more concrete type system for both Swift and Kotlin. I think one thing that I found that is a particular difference between the two of them is that Kotlin has a lot more built-in support for covariance and contravariance with generics, and that gives you a whole bunch of options in terms of particularly Fragments's interfaces in Kotlin in a way that they just do not work in Swift, which took me like a year to figure out, but yeah, they don't. Maybe with some of the changes that are coming to Swift, maybe, possibly, I don't know. But it's definitely something where, you know, I'm certainly a huge partisan for strictly typed languages and for compiled languages, just because as Jeremy was saying, if it compiles, it's going to run. Like that, I think much more so with rust than with Swift or Kotlin, but it's definitely something where having the computer looking over your shoulder and just being like, hey, that's not right. That one? Nope, nope, I don't think so. It's interesting because when I talk to people who work with untyped languages, they get really annoyed with compilers because they're just like, why are you telling me what to do? But for people who are used to working with compiled languages, it's definitely something where I'm like, no, I wanted to tell me what to do. Like I'm not good at this. The computer is probably a lot better at it. So I can agree with that because that's one of the things that I'm missing in Python. Like we do have some tools that allows you to add static type analysis, but they are not as good as, for example, typescript, because I do typescript occasionally and it's much better than what Python can offer in this field. Yeah, absolutely. I think it's funny that the javascript ecosystem is often trying to eliminate the build step where I think maybe we should all embrace the build step because it can save you so much headaches down the line. Yeah. And if we're talking about the build step in javascript, I think Gabriel has a lot to say about that. Yeah. Well, I would like to divide my answer into two parts. Like the first part is the general support for graphql in ReScript itself. And I would say that's pretty good. ReScripted language has very solid pattern matching and a very strong type system and very good type inference, which means that like graphql being a contract telling you, okay, this is what you asked for, this is exactly what you're going to get back. That lends itself really well to ReScript. And also working with deep optional structures is also pretty easy thanks to pattern matching and those things. There's also a thing called PPXs, which is the type of compiler plugins, kind of like a bubble transform, but type-checked, which lets you inject things into the compiler and rewrite syntax and whatnot. It's a very dangerous weapon, but for some things it enables a few interesting use cases, graphql being one of them, which basically there's a project called graphql PPX, which is more or less like a graphql code generator baked into the compiler itself, kind of. So that's very interesting and that's very nice. But there's also, like for me, yeah, I guess it all ends up with, I want to build UI. That's what I want to do. That's why I use graphql. I like graphql. It's by far my favorite way of communicating and getting data from the server and whatnot, but I still want to build stuff. That's what I want to do. And ReScript language is very good for building UI, just because to me, building UI is 90% conditionally rendering stuff. That's like, you have a bunch of state and then you decide, depending on what it is, you render A, B, C, or D. And ReScript is really good at that because of pattern matching and because of things like you don't have to annotate types that much, like only in certain places you can rely on the inference very much. So it ends up being very, you write fairly little code and it still gives you full type safety, which is very nice. And then it also enables kind of building a lot of tooling, which is quite fun. I've been building a lot of tooling around like, so in ReScript, since it's fully sound, you can always trace back a single value back to its origin inside of a graphql query or a fragment or whatever. And that enables a couple of pretty interesting tooling things, like being able to auto-complete unselected fields from inside of the values in the code and removing unused fields that aren't referenced in code, like project-wide. So even if you pass something around through five different files, you can still trace it down, whether it's used or not and those types of things. So I would say that's, I wouldn't say like unique because I know nothing's ever unique in this world anymore, but it's still like, it's a nice feature of ReScripting and graphql together. I see. So you mean like, even if I'll, not only that I'll use some value of a query, but also if after, you know, that query, like I'll get the value from the query and then I'll process it in like all kinds of different ways at the end of the day, I still know, and then I remove it later on. I'll still know that I'm not using actually that query anymore, like that field anymore originally. So like, as long as any value stemming from a query or a fragment, as long as that's referenced somehow in your code, so as long as it's used somehow, passed into function or whatever, then you can trace it. It's actually used. But if it's not, like it could be as easy as like you passing around a user with an ID, a name and an avatar URL, and then you don't use, like you pass that around five times, this never happens, but for the case of example, you pass it around and in that you don't use the name. For instance, it'll be able to trace that all the way and figure out that you're not using the name and where we can remove that safely from the fragment or the query. It's cool. It leads me to another question, which is, well, I have two big questions I think for in general, like for us to talk about. Like one, I think that for to learn, like one thing is I want to hear about the javascript ecosystem in your languages. Like how is it there? Because you're not only just users of your language, you're actually like graphql developers in your language and also leaders in that. So I wanted to hear, how is it for you to be like, for me, for example, being a graphql developer in the javascript world, it's like you're a certain person and then like, and then you would try to convince people why it's good, why it's bad and things like that. So I want to hear a bit about that for each of your languages and how many people are adopting it in these ecosystems, why and why people are not adopting it. And the other question, and I'm just throwing them, but then we can just discuss about them is actually, what do you think that like other, all of us can learn from the specific capabilities, just like what Gabriel said right now, like could we reuse these ideas in other languages as well or things you recognize that we could use, like you're looking at other languages and you're like, why aren't you doing that? Like this is really good. So all of this, just let's start, I mean, we can go one by one, but maybe we can just start anyone who wants to start, let's just start because there's a lot to talk about them. Not too much time. Yeah, there's a lot to unpack here, isn't there? I think the two things that I'm looking for as the more general foot guns I'm trying to avoid basically would be, I would love to have pattern matching of some sort and hopefully, yeah, exhaustive pattern matching. Like I want to know if I'm missing a default and if there's a variant that I'm not actively chasing or that I did not take into account. And the other thing, which is a little bit related, I mean, it depends on the languages, of course, that would be nulls. It's like I'm super scared of nulls and I want to maybe type, I want something and that with exhaustive pattern matching allows me to know that, yeah, you forgot that this could be null actually and you might have a hard time afterwards. So yeah, that's probably one of the things that I'm looking for as much as possible. And on the other hand, it's something that has been talked about already. It's like the ability to be hacking on stuff. I just want to do stuff, okay? There are moments where it needs to be super tight and there are moments where I just want to do stuff. And I feel like we have all spent a lot of time trying to trade off between our ability to develop stuff and our ability to have stuff that runs really well or really fast. And yeah, this is basically the kind of tradeoff that I'm probably chasing. And that comes to the ability to write plugins, monkey patch stuff, write extensions. And that's probably maybe for another meeting or something, but there's probably a nice best of all worlds to be found in the WASM space or in the interoperability between all of the languages having the same runtime and this kind of stuff. So yeah. How is write-away graph? Oh, sorry, Kristin. Oh, no, I was going to say, it's funny that you mentioned the nullability stuff, just because I think one of the things that Swift and Kotlin developers have a really bear of a time wrapping their heads around is that in typescript and schema definition language, if you have just string with nothing after it, that's optional. Whereas if it's string with an exclamation point, that is non-optional. In both Swift and Kotlin, unannotated is non-optional. You use a question mark to indicate optionality. And then if there's a exclamation point in Swift, that's called a force unwrap, and I'm blanking on what it's called in Kotlin when you use the double exclamation point. But it's basically something that is a huge code smell for Swift and Kotlin developers, where it's just like, no, you're basically saying, ignore all the type information that I gave you. And so trying to get people to be like, no, I swear to God, the exclamation point does have to be there. It's going to be okay, all of your code is not going to blow up if there's an exclamation point, I promise. That's a thing that is really big. And then, yeah, I think it would be one of the things that I'm really excited about is the proposal for client-side nullability. That's something that is going to be really, really important for mobile clients in particular, because there's definitely a lot of situations where, okay, there is some reasonable world in which this could be nullable, but by the time it gets to your iOS or Android app, it probably shouldn't be. And so being able to have that ability at the client side, I think, is going to be big. I'm a big fan of the option type, too. I've tasted it when playing around with rust. Our client for the chat is actually written in Rescript, so I know it as well. And I think in PHP, either we've just got it or they're still working on it. One of the downsides of PHP is that we have to support multiple versions of the language. So in terms of what we actually write, we have to go for the least common denominator, even though that is rapidly picking up the pace. And I think static analysis for us has been great once we enabled that now a few years ago, the amount of places where it said, hey, this can be null. And we're like, oh, yeah, well, we've seen bugs like that in production that has dramatically declined. Yeah. And now that you folks have Void support and all these kind of things, I think that ends up like a bit more verbose, but much more powerful language, in my opinion. I look at the new PHP code, what it looks like. It has nothing to do with the PHP 5.4 that I used to do before. So it's really, really nice to see how it evolves. No, definitely. I think one of the interesting things you said is that you were looking for something that can be strict and hackable as well. I do think personally that that's difficult because you have to make tradeoffs in the language. So either you allow one or you allow the other. I'm not sure if we can have both. I guess in javascript, they use strict keywords that kind of tighten stuff a little bit. I suppose this might be one of the options there, but there's maybe a problem space or something to be done in that respect. Yeah. I think Python has a good balance between being able to hack stuff and at the same time build stuff that works rather fast. But like I said before, we don't have this strict type checking and we still find bugs in productions where you forgot to handle null in this one place. So this happens regularly. So definitely it would be better to have some better type checking here. I think so. Maybe we have seven more minutes. I think for me, it's interesting how it is for you inside your own ecosystem advocating for graphql specifically. What is the perception for people for graphql? Why do you think in your own ecosystem, graphql is very valuable and how big it is in your community? Jeremy, maybe, sorry, Robert, maybe you can start. Oh, sure. Yep. Personally, I find that I don't have to do a lot of talking about graphql in general. People show up at the project knowing what it is, wanting a graphql api, which is, I love that. I would rather be sort of heads down, slapping things together, tightening things up. And so I enjoy, I mean, what I mostly hear is people who are, they want a graphql api often sometimes for internal clients or Facebook style, sometimes for a public api. And my world is, hey, my old Rails app works like this. It looks like graphql works like this. Can we, is this going to work and trying to make the answer yes. Sometimes the answer is no, but that's definitely the biggest thing. And then managing from a Rails standpoint, we're very much used to like, here's a page that we're going to render. Here's all the code that's going to run. The way you load data from the database is this. With graphql, we're going to serve a request. The data that you're going to load is, don't know. And so helping folks find and implement data loading patterns and then application logic that uses data in a dynamic way that responds to the fact that it's going to be dynamic is most of my work there. I think you get to some degree a bad rap on graphql because that work is so hard that if people don't see it as worth it, then they say, well, we should have just kept rendering html pages with Ruby on Rails. And there's something to be said for that. But you also get the sweet spot of once it's running, you have happy clients that are getting the data they need and able to manage their queries with great client libraries. So that's always a sweet time there too. I think the getting people over the, but we've been doing it this way for a really long time and it works mostly fine is one of the biggest things that is hard for mobile. I think particularly because mobile applications tend to have a much, much, much longer lifespan than websites. You can deploy a website with a click of a button. You can deploy an iOS app by sending it to Apple and then waiting for a week and then fighting with Apple for another two weeks. It is something where the friction is a lot higher. And so having something that is very, very flexible is not always necessarily what iOS or Android developers want. I think at this point, I do feel like on the web, the argument for graphql has mostly been like, oh no, we understand why this is. Whereas on mobile, it is something where there's still a level of having to educate people about what is this? What are the problems? What are the basic problems that this solves specifically on mobile? Because so much of the documentation about what are the problems this solves is super, super focused on either web or backend. I think there are definitely huge specific problems that it solves on mobile, mostly communication issues with your backend team. But it is definitely something where that tends to be more where I'm spending a lot of my time rather than like, hey, let's talk about this specific usage of graphql. That's interesting to hear, particularly given the backstory on graphql from Facebook, which was invented to serve mobile applications with a specific advantage of, as you add new behavior to the backend, you want old clients to keep running the way they always did without incurring the overhead. And I've seen the other approach to that, which is you take the same REST endpoint and add new things. And eventually you have a very slow REST endpoint that you can't delete. Yeah, you have the world's largest REST endpoint. And I also find that fairly ironic, but it is definitely something where I think it has been adopted more quickly in the Android ecosystem. The iOS ecosystem has a weird amount of not invented here syndrome, where people are just like, well, but if I could rewrite it myself, why don't I just do that? And I can give you many reasons why you don't want to, but, you know, yeah, it's definitely something where, yeah, like the irony of it being much, much more on web than it is on mobile is definitely not lost on me. In the part of the PHP ecosystem where we're operating, which is on top of the Drupal CMS, there was actually a discussion between graphql and Json api, and the people working on the core of Drupal actually decided to go with Json api, which is interesting because you're looking from a server perspective where we already have a lot of structured data storage. And it's of course much easier to automatically generate a Json api for that. At OpenSocial we looked at, okay, are we going to force the client to do the work and talk to five endpoints to assemble a webpage? Or are we going to move all the work to the server and choose graphql and encourage third party applications to easily fetch all the data that they need? So it's, I think in the server, it's not non-obvious for some people, but yeah, it really depends on where you want to push the work to. Yeah, it sounds to me like something very similar maybe between all of us here is that graphql brings like a new paradigm of thinking. And that's like the hardest thing to do. I don't know if educating is the right word, but just like talking about what graphql is and why do you need that? And this relationship between the backend or the data sources and the client and like who's responsible for what and all of these things. We really need to finish like really soon, but I hope we can have many more of these discussions somehow, because I think there's like so much to talk about and so much to learn from each other. But thank you so much for sharing everything here. It was fascinating for me and I wish we had more time. Thank you so much. Thanks a lot. Thank you. Thank you.