Season 2 Episode 2 Nov 5, 2020

iOS Accessibility Features, GraphQL Editor 3.0, Raspberry Pi 400, Stripe Climate, and CodeSandbox

Pitch

Back tap into learning about accessibility.

Description

In this episode, we cover Raspberry Pi 400, Stripe Climate, and CodeSandbox's series A funding. Then we speak to Kaya Thomas, senior iOS engineer at Calm, about iOS’s new back tap feature, and other accessibility features on iOS that developers might not know about. Finally, we chat with CTO of GraphQL Editor, Artur Czemiel (Cha-mial), about the release of GraphQL Editor 3.0.

Hosts

Saron Yitbarek

Saron Yitbarek is the founder of CodeNewbie, and host of the CodeNewbie podcast and co-host of the base.cs podcast.

Josh Puetz

Josh Puetz is Principal Software Engineer at DEV

Guests

Kaya Thomas

Kaya is a senior iOS engineer at Calm, formerly at Slack. She also writes and has spoken at conferences all around the world.

Artur Czemiel

Artur Czemiel is the CTO of GraphQL Editor, and CEO of Aexol.

Show Notes

Audio file size

60902416

Duration

00:42:18

Transcript

[00:00:10] SY: Welcome to DevNews, the news show for developers by developers, where we cover the latest in the world of tech. I’m Saron Yitbarek, Founder of Disco. 

 

[00:00:19] JP: And I’m Josh Puetz, Principal Engineer at Forem. 

 

[00:00:22] SY: This week, we’re talking about Raspberry Pi 400, Stripe Climate, and CodeSandbox. 

 

[00:00:28] JP: Then we’ll be speaking with Kaya Thomas, Senior iOS Engineer at Calm, about iOS’s new Back Tap feature and other accessibility features that iOS developers might not know about. 

 

[00:00:37] KT: One of the things that’s been nice about it is it’s actually gotten people to go into the accessibility setting on their phone. 

 

[00:00:44] SY: And then we’ll chat with CTO of GraphQL Editor, Artur Czemiel, about the release of GraphQL Editor 3.0. 

 

[00:00:51] AC: Sometimes you are in the moment that you look for the ideas across the whole internet and you can’t find one. You just have to design it yourself. 

 

[00:00:59] SY: So this week the Raspberry Pi 400 came out and it’s basically the existing Raspberry Pi packed inside of a keyboard. It’s $70, which is pretty good for a standalone machine that has a computer and a keyboard. But they sell it in a kit with a mouse and some other stuff to get you going for a hundred dollars. That’s a hundred bucks total. And essentially, if you were going to make a similar kit with Raspberry Pi for Model B, it would cost you around 117, which is a little bit more expensive, and you’d have a slower CPU than the 400. So getting the kit is probably a good deal. So Josh, you are a Raspberry Pi guy. Would you consider getting this kit for yourself or someone else? 

 

[00:01:37] JP: Yes. You’re right. I do identify as a Pi guy. I’m super interested in this. It’s really, really cute. 

 

[00:01:44] SY: It is really beautiful. 

 

[00:01:45] JP: It reminds me of the home computer push in the mid-eighties. You have the Commodore 64, the Amiga, the Texas Instruments, and they were all these computers that there was a keyboard with the computer stuff underneath the keyboard in the base. It looks very similar to this Raspberry Pi 400. So it kind of ticks some of the nostalgia boxes for me. I do have a Raspberry Pi. I play with it on and off. I’ve made like a home router. I’ve done some home automation stuff. 

 

[00:02:12] SY: Nice! 

 

[00:02:13] JP: It’s really fun to play around with, but the downside is when you’re getting started, when you buy a Raspberry Pi kit, it all comes loose. You’ve got your motherboard and a heat sink and there’s not a lot of parts because this is a tiny computer. But having it all put together at once is really, really attractive. You had mentioned the other day, there was this great quote from Raspberry Pi Founder Eben Upton, “The dream always with Raspberry Pi is to lure people into buying a PC and then trick them into becoming computer programmers.” 

 

[00:02:42] SY: Oh, I love that. 

 

[00:02:43] JP: I love that. There are so many people in my life that I think I want to give this to, to try to see if I could trick them into becoming a programmer. I don’t know if it would work and if it didn’t, then maybe they could give me this back and I would have it. 

 

[00:02:57] SY: Is your daughter one of those people? 

 

[00:02:58] JP: I have tried to trick my daughter several times into becoming a programmer. 

 

[00:03:01] SY: Has it worked? 

 

[00:03:02] JP: She’s not very interested in it. She’s more interested in like the content creation and art creation side. So developing doesn’t really do it for her, but I can see this being really attractive to someone that might want to play with Linux on the cheap. Yeah. 

 

[00:03:17] SY: So it almost feels like this is targeting a slightly different audience because I can imagine for, I don’t know how to describe it, like the pure hacker, if that makes sense, like the version of Raspberry Pi where you do have to put everything together on your own is probably more appealing. Right? Because it’s like a macro, I’m like doing it myself. And this feels like it’s kind of going after a different audience where it’s like people who maybe don’t see themselves as coders and maybe feel a little intimidated by all the parts and just wouldn’t normally do Raspberry Pi. It feels like it’s focusing on a slightly different market. Is that fair? 

 

[00:03:51] JP: Yeah, I think so. I think maybe it’s focusing more on the software hobbyist or the software hacker versus the hardware hobbyist hacker. You shouldn’t say though. This has all of the hardware expansion ports that the regular Raspberry Pi has. So you’re not giving up anything with this. 

 

[00:04:08] SY: Sounds right. Yeah. 

 

[00:04:09] JP: But if you just wanted to like, say, play around with Linux, maybe experiment with like doing your own router, you could buy this kit and just be off to the races. You don’t have to worry about installing and configuring and putting the hardware pieces together. 

 

[00:04:23] SY: Yeah. That makes sense. 

 

[00:04:25] JP: Well, next up, remember last season where we talked about what Google’s doing to try to limit their carbon footprint? 

 

[00:04:30] SY: Yes. We had Senior Engineer at Forem Vaidehi Joshi on and she walked us through some of the actual environmental costs of our data. 

 

[00:04:38] VJ: The reality is that all data has to have some sort of physical presence. And what I mean by that is our data lives somewhere. And a lot of the times we don’t have to think about that because we are using cloud providers, which have their own data centers, which housed that data. So we’re not necessarily directly thinking about it. But those cloud providers that we lean on are storing all of our data in large data centers. And those data centers take a lot of energy to power and maintain. So there’s like a physical aspect to that and there’s an environmental cost to storing all of our data in these data centers. 

 

[00:05:21] JP: So Stripe is getting into the green game as well and launched something called “Stripe Climate”. The idea behind this is that if you’re a Stripe customer, they now allow you to be able to donate some of your revenue that you make through the Stripe app to carbon removal technologies. And you get a badge that you can show off to your customers. Apparently, this place is a portion of your revenue in a fund that goes to the same carbon removal projects that Stripe donates to themselves. 

 

[00:05:48] SY: That’s cool. 

 

[00:05:49] JP: Yeah. So something that a lot of tech companies do is try to offer carbon offsets. Now I’m a little skeptical of carbon buyback programs. It kind of feels like the equivalent of putting a black square profile on your Instagram account to support Black Lives Matter. 

 

[00:06:03] SY: Ooh! Ouch! 

 

[00:06:04] JP: Okay. That’s a burn. Yeah. 

 

[00:06:06] SY: Ouch! 

 

[00:06:07] JP: Well, it’s symbolic and it signals that you want to do something, but the carbon is still going out there. You’re just kind of putting some money off there to offset it. So it just feels like it’s more of a conscience smoothing attempt than something real. 

 

[00:06:21] SY: Okay. I have a better one for you. 

 

[00:06:22] JP: Yeah. 

 

[00:06:23] SY: I have a better analogy. It’s like the equivalent of having a black scholarship or grant program while still not hiring or promoting black employees at your company. 

 

[00:06:36] JP: That’s much better. Yes. 

 

[00:06:37] SY: Do you see what I mean? 

 

[00:06:38] JP: Yes. No. I see what you mean. 

 

[00:06:38] SY: Like technically you were still helping, right? Like you were helping with systemic inequity and you’re doing something and it’s probably going to be helpful in some respect, but one of the core issues is just getting jobs and getting promoted and having successful careers is like a big part of it. And if you’re not doing something about that, then like that’s still going to be a problem. 

 

[00:06:58] JP: Right. The root cause isn’t addressed. 

 

[00:07:00] SY: Right. 

 

[00:07:00] JP: Right. So that’s been my problem with carbon buyback programs. What’s interesting about this program is that it’s not a carbon buyback program. It is supporting what Stripe calls “carbon removal technologies”. So they say that the money that’s going into this fund, instead of just buying carbon offsets, they’re going to take this money and they’re going to pick programs and research that are designed to reduce or eliminate carbon in the atmosphere. Really, really interesting. 

 

[00:07:29] SY: Yeah. 

 

[00:07:30] JP: Also really interesting, they’ve opened source the selection criteria that they use to pick these projects. If you participate in this program, you’ll get transparency reports about where exactly your money is going. I think this is great. 

 

[00:07:40] SY: Yeah. And what I really appreciated about it is, similar to what you said about open sourcing their process, they go into a lot of detail on their website about the journals and the articles they quoted. They have the faces and names of the scientists they’re working with. It’s just very legit. It feels like a very thoroughly vetted, well-thought-out program that I feel like probably took a lot of time and a lot of money to be totally honest. I’m sure bringing all the scientists probably wasn’t a cheap endeavor. I’m a Stripe customer myself. I use their checkout system and it makes me proud to be a Stripe user. You know? 

 

[00:08:17] JP: Yeah. 

 

[00:08:17] SY: So they’re definitely winning me on brand points, but it definitely feels like it’s deeper than that. It really feels like they’ve done the work of really understanding the issue. And I like also that it’s not just them giving us an opportunity to donate. They’re like, “We’re donating alongside you. Here’s what we’re doing and you’re along for that ride,” which I really appreciate too. 

 

[00:08:35] JP: Yeah. It’s very much like investing in like a 401-k fund that’s run by someone else. 

 

[00:08:39] SY: Yeah. 

 

[00:08:39] JP: That’s kind of what it felt like to be like, “Let us take care of investing money.” 

 

[00:08:41] SY: That’s a good analogy. Yeah. Yeah. I like that. Yeah. So we don’t usually cover stories that are about companies, getting money, raising money, but because of what this company is and its relationship to developers, we thought this one was worth mentioning. So this is about CodeSandbox, the collaborative online editor for web applications that received a $12.7 million Series A funding round. They launched three years ago. And according to the company, they are used by over two million developers per month, which is a lot, especially for those three years. And I think this funding is really interesting because usually to receive funding, unless you’re like a social media company that’s trying to get like millions of users before you start generating revenue, you generally need to be making some money. It’s actually pretty tough to get a Series A without generating money and kind of proving your business model. So this shows that there’s definitely some interest in these online editors, from coders, from investors as well. So Josh, you typically use an online editor for when you code on your own iPad. Is that right? 

 

[00:09:43] JP: Yeah. I’m a big fan of my iPad and I’ve done talks on writing code on your iPad, which you actually can’t do. Instead, you have to write your code on the web and run it there. So these online editors, online IDEs are a great way to do that. And CodeSandbox is something that I’ve used in the past. I’m really surprised by this announcement because, how does the old joke go, there are dozens of us. There are just not that many people that are using their iPads for day-to-day coding work because you are kind of jumping through some hoops. So I was really surprised to read that there are over two million users monthly. 

 

[00:10:21] SY: That’s a lot. 

 

[00:10:22] JP: It’s a lot. So I dug into this a little bit and CodeSandbox says that some of their larger clients that they have using their product, I was like, “Oh, maybe it’s companies that are having their teams use it somehow collaboratively.” There’s a little bit of that going on, but what also is going on is that a lot of larger companies are embedding their sample code and their documentation code in online IDEs like CodeSandbox. 

 

[00:10:50] SY: That makes sense. 

 

[00:10:51] JP: Yeah. If you’re offering an API for your company, instead of just having static documentation, you can pay CodeSandbox, you can host your examples in CodeSandbox and then developers can interactively run with them, which is brilliant. 

 

[00:11:06] SY: That is really brilliant. And it reminds me of some, I can’t think of a good example right now, but I remember trying out a couple apps like productivity apps and they will show you a version of the project embedded within the landing page and you’ll be able to play with the features and basically instead of signing up and having a free account, you just get to dive right in and interact with the product within this embed. And it’s really nice and it’s just such an easier way than like manually creating a sign-in page and making a fake project. You know what I mean? It’s so much smoother. And so I can see the same experience working for APIs and for code samples, just being able to just jump right in, start fiddling around, messing around, having an already set up project for you to mess around in. 

 

[00:11:53] JP: Yeah. 

 

[00:11:53] SY: Right? Instead of having to create your own skeleton applications. So yeah. I can see that being really valuable. 

 

[00:11:59] JP: Yeah, I can too. I can’t tell you how many projects are littered on my hard drive, where I was like, “I think I’m going to try this library,” and you get three, four or five steps into setting it up. And you’re like, “Maybe I won’t.” 

 

[00:12:10] SY: Yeah. Exactly. And it’s interesting because as a founder myself, I’m kind of curious about the journey that led them there because I doubt that’s where they thought their product would end up being. You know what I mean? 

 

[00:12:23] JP: Yeah. 

 

[00:12:24] SY: Like they probably have this vision of everyone doing collaborative code together and building these projects online and blah, blah, blah. And I would be very surprised if they saw the application being like testing APIs and documentation. I’m curious to hear the road to getting there. 

 

[00:12:41] JP: Well, the big competitor in the space that is emerging this year is a feature called Codespaces by GitHub, which we’ve talked about on the program before. 

 

[00:12:51] SY: Yes. Yes. 

 

[00:12:52] JP: And GitHub definitely pitches their online editor and IDE as exactly that. You can spin up an entire project on the web. You can edit it. You don’t have to download it. And so it is hitting that IDE in the cloud grand vision. I do think a lot of these companies might’ve had that vision. And this is, A, a great way to pivot in the face of competition for free from GitHub, and B, a natural business opportunity that has just kind of emerged as other companies have come along and said, “We don’t need it for our employees,” but this would be a great use case. 

 

[00:13:31] SY: Yeah, absolutely. So I’m not usually excited about new iOS updates, to be totally honest. I feel like I’m very not a developer in that sense. My husband Rob is always trying to convince me to download the latest update. And I’m always like, “Oh, I don’t like change.” But this one was definitely a game changer for me. So one of the updates of iOS 14, and this blew my mind, is that you are now able to tap on the back of your phone and trigger specific functions. So iOS 14 was released on September 16th, but the general populace is barely learning about some of these features, like the Back Tap is what it’s called. And I feel like Apple does this often with their products. There are so many of these like secret features that are built into their product and people don’t really know about it unless they are like super Apple heads. Is that a thing, apple heads? 

 

[00:14:22] JP: Yeah, Mac fanatics. Yeah. 

 

[00:14:24] SY: Yeah. And then when I heard about this Back Tap feature, the first place my mind went to was that this could be a really great feature for accessibility. So I was really excited about that. I geeked out when I found that Back Tap. I was just back tapping all day. 

 

[00:14:38] JP: And your instinct is totally right. These are accessibility features first and foremost in iOS and their usability outside of the accessibility realm is starting to become more publicized. 

 

[00:14:51] SY: So coming up next, we speak with Senior iOS Engineer at Calm, Kaya Thomas, about accessibility features in iOS that people might not know about and that mobile developers should definitely know about while thinking about building for iOS after this. 

 

[MUSIC BREAK] 

 

[AD] 

 

[00:15:19] JL: Triplebyte is a job search platform that allows you to take a coding quiz for a variety of tracks to identify your strengths, improve your skills, and help you find your dream job. The service is free for engineers and Triplebyte will even cover your flights and hotels for final interviews. 

 

[00:15:34] SY: Vonage is a cloud communications platform that allows developers to integrate voice, video, and messaging into their applications using their communication APIs. Whether you’re wanting to build video calls into your app, create a Facebook bot or build applications on top of programmable phone numbers, you’ll have all the tools you need. Formally known as Nexmo, Vonage has you covered for all API communications projects. Sign up for an account at nexmo.dev/devnews2 and use promo code DEVNEWS2 for 10 euros of free credit. That’s D-E-V-N-E-W-S, in all caps, and the number 2, for 10 euros of free credit. 

 

[AD END] 

 

[00:16:20] SY: Here with us is Kaya Thomas, Senior iOS Engineer at Calm. Thank you so much for joining us. 

 

[00:16:26] KT: Thank you so much for having me. I’m excited to chat with you all. 

 

[00:16:29] SY: So tell us a bit about your developer background. 

 

[00:16:31] KT: So I have been an iOS developer since 2014 and I’ve kind of stumbled upon it, actually. I did a summer internship where my manager asked me if I knew iOS and I didn’t at the time, but I told her I could learn and kind of fell in love with it from that summer. And before that, I started taking computer science classes in college and really loved it then. So that’s kind of how I got into development. 

 

[00:16:58] SY: Nice. 

 

[00:16:58] JP: So can you tell us what is Calm and what kind of work that you do there? 

 

[00:17:02] KT: So Calm is a meditation and relaxation app. So there is meditation content. There are sleep stories. There’s music, like calming and relaxing music. There are masterclasses with different folks on mindfulness practices and life tips and things like that. So very content heavy app. So as an iOS developer, I work on a variety of either new features, maintaining current features and bug fixes, collaborating with product managers and designers to work on kind of new experiments and things that we want to try out with our customers. 

 

[00:17:41] SY: Very cool. So you gave a really awesome talk at UIKonf in 2019, where you were an iOS engineer at Slack titled, “Inclusive and Accessible App Development”. Can you tell us a bit about what you talked about in that talk? 

 

[00:17:56] KT: Sure. So that was probably one of my favorite talks that I’ve given and the premise of really the talk was to get people to understand a baseline of what accessibility is. So creating usable products, services, et cetera, for all people, regardless of their ability, but then also getting them to understand the difference between accessibility and inclusion and that inclusion is being intentional and going the extra mile to make it not only a usable experience, but a good experience for someone regardless of their ability or background. So this talk was really just going into detail about how you can be intentional and put accessibility at the forefront of your product development processes. I also talked about some actual concrete coding things that you can do for iOS using the UI accessibility framework and library. So I think it got the message across for folks to understand that accessibility is a first step of making your software just have a baseline of usability, but then inclusion is actually putting in the effort to make it a good experience. 

 

[00:19:03] SY: Oh, I love that distinction. That’s really good. Yeah. 

 

[00:19:06] JP: So what are some of the most important things that you think iOS developers need to consider about accessibility and inclusion when they’re building their apps? 

 

[00:19:14] KT: I think really the first thing is making sure that you’re familiar with the kind of basics of the UI accessibility library. So understanding what accessibility label is, understanding accessibility traits, accessibility hints. So accessibility label is what is read aloud. So the voiceover user, when they navigate to that element, using swipe gestures on voiceover, and then accessibility trait, it would be like a button or static texts or a slider. It basically indicates to them what sort of element it is. Then you have accessibility hint, which is I think one that a lot of people gloss over and they actually don’t implement, but accessibility hint basically gives them an idea of what’s going to happen when they interact with this element. So for many of us, if we’re using an app and you’re a sighted person, you can just tap and discover and you don’t really have to worry about, you don’t need a hint, you’ll just tap on it and you can see what it does. But for someone using a screen reader, tapping on an element can actually lose them a lot of time. Right? 

 

[00:20:18] JP: Oh, yeah. 

 

[00:20:19] KT: Because if they tap on an element and it brings up another element that they weren’t expecting, then they have to figure out how to navigate out of that element. It’s just a lot. So giving a hint for let’s say a custom button, tapping on this button is going to bring up a search text view or something, right? That lets them know what’s going to happen next when they interact with that element. So I think that’s one that folks forget about and I think that’s a step towards inclusion, right? Because then you’re making a better experience for them, having the label there, having the trait, it usually comes out of the box, if you’re using UI kit elements. So that’s just really a first basic step. But having things like hints, that’s really an inclusive step to make it a better experience so that they can really understand what the different elements in your app are doing and how they interact with each other. 

 

[00:21:07] SY: So where do you think most people go wrong when it comes to accessibility and building apps? 

 

[00:21:13] KT: People go wrong in that they just don’t think about it at all. I think a lot of times some people are just either unaware or a lot of folks, especially if you’re working at a smaller company or a startup, a lot of folks want to move fast. They want to make sure they’re shipping as fast as possible and getting new updates out there. And I think sometimes in the sake of that fast mindset of, “We need to ship, ship, ship,” they put things like accessibility on the back burner and say, “Oh, well, we’ll get to that.” I don’t think we even have that many users who use that kind of stuff. People make excuses. So I think that’s really where people go wrong is that they don’t think that it’s important enough or they don’t see a business case for it or et cetera, et cetera. But I think there is a business case for it, but there’s also just a human element for it. You think about your product, especially if you’re making some type of software that potentially is impacting people’s lives positively, that means that folks who depend on these accessibility tools and to interact with technology wouldn’t have the ability to use your software and be able to have that same benefit from it. So there’s a human element and then there’s a lot of business cases of course for it too. But I think where people really go wrong is they just don’t think about it at all and they gloss over it and they really think of it as a last resort, “We’ll get to that eventually.” 

 

[00:22:41] JP: So the most recent iOS update gives users the ability to tap on the back of the device to activate features. Do you think this could be huge for accessibility? 

 

[00:22:51] KT: Yeah. I think in certain aspects, it’s a really nice feature, especially to increase the speed for folks who actually depend on tap gestures, swipe gestures to interact with the phone. I think one of the things that’s been nice about it is it’s actually gotten people to go into the accessibility settings on their phone. 

 

[00:23:11] JP: Yeah. Yeah. 

 

[00:23:12] KT: Because a lot of folks who don’t actually depend on the accessibility features are like, “Wait! Oh, this is cool. I can just have the tap open up my favorite app or I can have the tap trigger a series shortcut or what have you.” So I think people are going into the accessibility settings more and maybe that will allow people to take a look and maybe understand a bit more about accessibility. 

 

[00:23:34] JP: That’s a great point. I think a lot of people don’t ever visit that panel. 

 

[00:23:37] KT: Exactly. 

 

[00:23:38] SY: So off the top of your head, what are some ways that specifically this Back Tap could be utilized for apps to make them more accessible? 

 

[00:23:46] KT: I don’t know if it’s going to have a huge effect for accessibility users explicitly. I do think that it’s nice and it will allow for some better efficiency because I think that’s the one thing that is tough when you have to depend on either switch control or voiceover or voice accesses. It can be very tedious to do things that if you’re a person who will just interact with the phone as it is on its own, it just takes much longer to do things. So I think with the Tap Back to do an action, I think it’s really trying to also bring that to accessibility you use to allow them the same kind of speed and ease of access to the things that they normally do so often, which I think is really great. It really is going that mile right to that inclusivity to allow them to have a good experience with the phone and allow them to have that same ease of access that we all usually have so much. 

 

[00:24:44] JP: I’d like to talk to you about accessibility features in iOS that people might not know about and that you think developers should definitely know about when they’re building their apps. 

 

[00:24:53] KT: A big one that came out in recent years is differentiating with color. This one is for color blind users. So a lot of designers and folks who designed the UIs for the app, they’ll use color as a way to differentiate between elements. Think of like green for good and red for stop. Right? But if you’re a color blind user and you, let’s say, have invert colors on usually, you wouldn’t be able to know that those elements are supposed to be different from each other because of the color. So what Apple did is they created a setting called “Differentiate with Color”. Basically, if it’s turned on, as a developer you can look for that. And if that user has Differentiate with Color turned on, you know that you don’t want to use color to denote the difference between an element and you can add, let’s say, maybe an icon or you can add some texts or something to denote the difference between elements. I think that was a really big feature because their invert colors have been there for a while, for folks who are color blind so that they can just have either gray scale or there’s not so many colors on the screen, but the Differentiate with Color feature really allowed then us as developers to take note of, “Okay, if our users have this on, let’s make sure that we’re being intentional about how we’re setting these elements and adding maybe some texts or icons that make it clearer.” 

 

[00:26:24] JP: Very cool. 

 

[00:26:25] SY: So do you have any favorite accessibility resources or tools that you’ll recommend other developers to check out? 

 

[00:26:32] KT: I would say definitely the Apple Developer Documentation is really, really great. And I would say for sure, go to look at the old WWDC videos that show different accessibility features and how to implement them. A lot of them are not very long, especially with the new format that they just did with 2020. You can watch a 5 or a 10-minute video that shows you how to implement and take advantage of some of these APIs. So I would highly recommend checking out the accessibility videos from WWDC and checking out the UI accessibility documentation on Apple’s Developer Documentation site. 

 

[00:27:14] JP: And finally, is there anything that we didn’t already cover that you’d like to talk about? 

 

[00:27:19] KT: Definitely coming from an iOS focus, I’m focused as much on iOS, but I would say even for other developers who are either on Android or on the web also thinking about accessibility because there’s a lot there as well for web accessibility. If you’re a web engineer, check out the Web Content Accessibility Guidelines, WCAG. And if you’re an Android engineer, you want to check out Android and Google Documentation around that. Their screen reader is called “TalkBack”. And so no matter kind of what platform that you’re developing on, you should be able to take advantage of these accessibility frameworks, making sure that you’re creating a better and more inclusive experience for folks of different backgrounds and abilities. 

 

[00:28:05] SY: Thank you so much Kaya for joining us. 

 

[00:28:07] KT: Thank you for having me. 

 

[00:28:17] SY: Coming up next, we chat with CTO of GraphQL Editor, Artur Czemiel, about the release of GraphQL Editor 3.0 after this. 

 

[MUSIC BREAK] 

 

[AD] 

 

[00:28:39] JL: Join over 200,000 top engineers who have used Triplebyte to find their dream job. Triplebyte shows your potential based on proven technical skills by having you take a coding quiz from a variety of tracks and helping you identify high growth opportunities and getting your foot in the door with their recommendation. It’s also free for engineers, since companies pay Triplebyte to make their hiring process more efficient. 

 

[00:29:01] SY: Vonage is a cloud communications platform that allows developers to integrate voice, video, and messaging into their applications using their communication APIs. Whether you’re wanting to build video calls into your app, create a Facebook bot or build applications on top of programmable phone numbers, you’ll have all the tools you need. Formally known as Nexmo, Vonage has you covered for all API communications projects. Sign up for an account at nexmo.dev/devnews2 and use promo code DEVNEWS2 for 10 euros of free credit. That’s D-E-V-N-E-W-S, in all caps, and the number 2, for 10 euros of free credit. 

 

[AD END] 

 

[00:29:48] SY: Joining us is Artur Czemiel, CTO of GraphQL Editor. Thank you so much for being here. 

 

[00:29:54] AC: Thank you. 

 

[00:29:55] SY: So before we get into the new GraphQL Editor, tell us a little bit about your developer background. 

 

[00:30:01] AC: Okay. So I started my programming journey as a visual effects specialist 12 years ago. 

 

[00:30:07] SY: Oh, interesting. Cool. 

 

[00:30:09] AC: So I made special effects, composition and animation for several movies. Of course, this kind of job requires programming skills, for example, to program particles. Then I opened a company named Aexol to create mobile apps and I made a wheat scale app. It was used to weigh wheat on a mobile phone. It was 2012. So wheat was prohibited and it was prohibited to use a wheat scale. So I think this app saved some lives for some users. And during my app development challenges, I’ve noticed that the backend code is usually a real mess. I used to use some backend code first platforms, some code generators, but later on two of them closed their companies. So I decided to create my own backend solution or at least organize it somehow. And I switched to TypeScript. It was in 2018 or ’17. I don’t remember. And then I thought, “Okay, I can handle it myself. I can create a good backend platform for all of my companies and for other people, of course.” And in 2018, I created a platform named Slothking with my friend, Robert. We went to a very big company named Devanta to evaluate the idea with them. And then one of the co-owner said, “Why are you basing this whole thing on TypeScript type system when you have GraphQL?” And then I saw GraphQL and I saw it’s a graph language and it’s a description language. And I thought, “Yeah, this is the best fit for our system.” And we really liked this idea. And within two weeks, I prepared a prototype. I released it on GitHub. And the one Saturday morning, I decided to put the idea on Hacker News. And after two days, we had about 1,000 stars on GitHub. 

 

[00:32:12] SY: Wow! 

 

[00:32:13] AC: Yeah. I thought the idea is validated and we need to go this way. 

 

[00:32:20] JP: For the uninitiated, could you tell us what GraphQL Editor is and what its place is in the developer ecosystem? 

 

[00:32:26] AC: So GraphQL Editor, it’s mainly a tool to visualize and create graph data. So it’s a good tool for developers to visualize GraphQL and show it to business people, for example, because you have two options of visualization. One is an organizer graph and one is a real drawn graph where business people can see all the connections between data models and see how the system looks for them. So you don’t have to be a developer to understand how the system works. We also made this GraphQL Editor as an ultimate one source of truth. So whenever you start a project, even if it’s a startup or an internal tool inside a big company or a big portal project, then you need to have one source of truth, for example for mobile apps, for front-end developers, for backend developers and we saw working with other companies that very often this step is skipped. So they just start creating everything from scratch. So the front-end is made from scratch, the backend is made from scratch, the designs are made from scratch and then it's a total mess. We decided that there is a place on the market for a tool that defines your systems. So the more time you spend defining your system, the less time each of the team will spend developing it later. 

 

[00:34:02] SY: So what are some of the biggest new features and updates in this version? What are you excited about? 

 

[00:34:07] AC: Okay. So I’m excited about documentation generator and we are giving it all for free, for our users. It's a really simple tool, but other solutions in the market are paid. And usually, if you want to generate docs and host it somewhere, it’s paid and you have to pay much. So we added a documentation generator for our users. So they can easily generate docs for GraphQL, but not only in this GraphQL way because GraphQL users are used to this GraphQL console. But we also generate docs in a more readable form with just pure document and just pure HTML without this GraphQL console. I’m also proud of libraries because if you heard about GraphQL a lot already, so there are many different methods for joining schemas. There is no method inside the GraphQL’s specification. So there’s schema teaching, for example, where you merge all the types. So if you have two schemas or ten schemas from different server sources, then you can stitch them into one schema, create one middleman. And for example, if the that person exists in five schemas, the schema stitching algorithm will try to merge them, will try to merge the types. We think that this is not a good solution because you can easily get lost. So we introduce also schema libraries. So schema libraries work much more import and when they see two conflicting types, they just won’t let the developer to deploy that. So it’s pretty much a standard for other languages. But GraphQL as a definition, language, it doesn’t have its own import methods. So that’s why everybody makes their own import methods. We are proud of the schema libraries. There is also a JAMstack engine. This one is a new feature and it is experimental right now. So with JAMstack engine, we want to provide a new way to visually test the data coming from the GraphQL backend inside the editor. This was caused by another GraphQL company using our open source tool, GraphQL Zeus, for static site generation. And we thought, “Whoa! This is a great idea,” because just after writing a query with this Zeus engine, you had the types that will return to front and from backend. So they showed us that it’s very easy using this GraphQL Zeus, so our technology to create a static site generator. So that’s why we also included this JAMstack engine. It’s new. It’s experimental right now, but we hope one day it will be a very useful feature. 

 

[00:37:31] SY: What are some of the biggest challenges that you came across when you were building this new release? 

 

[00:37:37] AC: The biggest challenge for me was this new graph engine because it took us about, I think, three months to think how it should look like, because we had some voices telling us that it should look like exactly like GraphQL Voyager, but combined with our graph. When we combined everything, it was a total mess because it was like very big tiles, like from entity-relationship diagram, filling all the screen, hanging the computer. So we created a new version and a new version and a new version and again and again and it was very hard to have an idea how to make this draft to make it readable, to make it possible to edit it, to make it small, but big at the same time. So this was the hardest thing, not developing itself, but thinking about it, how it should look like because sometimes you are in the moment that you look for the ideas across the whole internet and you can’t find one. You just have to design it yourself. 

 

[00:38:47] JP: Was there anything in this release you were hoping would be there but didn’t quite make it? 

 

[00:38:53] AC: Yeah, there is one thing that I hope that will be in this release, but we are not able to make it right now because underneath I have some other companies and we are using a stock engine. It’s another product of GraphQL Editor, but we don’t promote it yet. It’s a serverless engine written in Golang and it works like a very fast GraphQL resolver without the core. So we need to inject the core. It’s open sourced on GitHub so you can look later, but it works like this. So the developer codes in TypeScript or JavaScript right now, but more languages are coming soon. But the whole GraphQL stuff is resolved within the compiled package in Golang and then they communicate via gRPC protocol. So TypeScript communicate with this compiled package and the developer can write in TypeScript or JavaScript, which is widely adopted and faster. What we wanted to do is to add a place inside the editor where you can write your field resolvers in TypeScript or JavaScript within the editor. So for example, if you have small MVP or small back-ends or a small micro service, then in the future, it will be available to do it inside the editor. 

 

[00:40:28] SY: What are some things that are going to be coming down the pipeline for future versions for new features for GraphQL Editor? 

 

[00:40:36] AC: There are some features from our users, of course, that will also be integrated inside and add for, for example, diff editor, so users want to see two graphs with the difference between one version of GraphQL and another. 

 

[00:40:50] SY: That’s nice. Yeah. 

 

[00:40:51] AC: Yeah, which makes it easier to work for backend developers because front-end developers don’t care about versioning so much. But for backend developers, it’s very important because they usually also implement database migrations and that stuff. So they need to know exactly what’s changed inside the GraphQL schema and that is also because we are coming into the direction with GraphQL, in my opinion, where there will be a new position called the “schema architect” and they will do the scheme architecture, not backend developers, but I think that will come in the short future. 

 

[00:41:35] SY: All right. Well, thank you so much for being on the show. 

 

[00:41:37] AC: Okay. Thank you. 

 

[00:41:49] SY: Thank you for listening to DevNews. This show is produced and mixed by Levi Sharpe. Editorial oversight by Peter Frank, Ben Halpern, and Jess Lee. Our theme music is by Dan Powell. If you have any questions or comments, dial into our Google Voice at +1 (929) 500-1513. Or email us at [email protected] Please rate and subscribe to this show on Apple Podcasts.