Podcasts about graphql apis

  • 77PODCASTS
  • 187EPISODES
  • 47mAVG DURATION
  • 5WEEKLY NEW EPISODES
  • Nov 4, 2022LATEST

POPULARITY

20152016201720182019202020212022


Best podcasts about graphql apis

Latest podcast episodes about graphql apis

The Nonlinear Library
EA - Metaforecast late 2022 update: GraphQL API, Charts, better infrastructure behind the scenes. by NunoSempere

The Nonlinear Library

Play Episode Listen Later Nov 4, 2022 3:46


Welcome to The Nonlinear Library, where we use Text-to-Speech software to convert the best writing from the Rationalist and EA communities into audio. This is: Metaforecast late 2022 update: GraphQL API, Charts, better infrastructure behind the scenes., published by NunoSempere on November 4, 2022 on The Effective Altruism Forum. tl;dr: Metaforecast is a search engine and an associated repository for forecasting questions. Since our last update, we have added a GraphQL API, charts, and dashboards. We have also reworked our infrastructure to make it more stable. New API Our most significant new addition is our GraphQL API. It allows other people to build on top of our efforts. It can be accessed on metaforecast.org/api/graphql, and looks similar to the EA Forum's own graphql api. To get the first 1000 questions, you could use a query like: title url description options { name probability } qualityIndicators { numForecasts stars } timestamp } } pageInfo { endCursor startCursor You can find more examples, like code to download all questions, in our /scripts folder, to which we welcome contributions. Charts and question pages. Charts display a question's history. They look as follows: Charts can be accessed by clicking the expand button on the front page although they are fairly slow to load at the moment. Clicking on the expand button brings the user to a question page, which contains a chart, the full question description, and a range of quality indicators: We are also providing an endpoint at metaforecast.org/questions/embed/[id] to allow other pages to embed our charts. For instance, to embed a question whose id is betfair-1.178163916, the endpoint would be here. One would use it in the following code: You can find the necessary question id by clicking a toggle under "advanced options" on the frontpage, or simply by noticing the id in our URL when expanding the question. With time, we aim to improve these pages, make them more interactive, etc. We also think it would be a good idea to embed Metaforecast questions and dashboards into the EA Forum, and we are trying to collaborate with the Manifold team, who have done this before, to make that happen. Dashboards Dashboards are collections of questions. For instance, here is a dashboard on global markets and inflation, as embedded in Global Guessing. Like questions, you can either view dashboards directly, or embed them. You can also create them, at. Better infrastructure We have also revamped our infrastructure. We moved to from JavaScript to Typescript, from MongoDB to Postgres, and simplified our backend. We are open to collaborations We are very much open to collaborations. If you want to integrate Metaforecast into your project and need help do not hesitate to reach out, e.g., on our Github. Metaforecast is also open source, and we welcome contributions. You can see some to-dos here. Developing is going more slowly now because it's mostly driven by Nuño working in his spare time, so contributions would be counterfactual. Acknowledgements Metaforecast is hosted by the Quantified Uncertainty Research Institute, and has received funding from Astral Codex Ten. It has received significant contributions from Vyacheslav Matyuhin, who was responsible for the upgrade to Typescript and GraphQL. Thanks to Clay Graubard of Global Guessing for their comments and dashboards, to Insight Prediction for help smoothing out their API, to Nathan Young for general comments, to others for their comments and suggestions. Thanks for listening. To help us out with The Nonlinear Library or to learn more, please visit nonlinear.org.

CodePen Radio
389: Migrating a Ruby on Rails GraphQL API to a Go GraphQL API

CodePen Radio

Play Episode Listen Later Nov 2, 2022


One thing that's been keeping us very busy at CodePen is moving our main API. We decided on GraphQL long ago and it's served us pretty well. We originally built it in Ruby on Rails alongside a lot of the rest of our app. But while Rails served us well, we've been moving off of it. We like our React architecture and we're better served leaning into that, with frameworks like Next, than staying on Rails. We proved out this combination of technologies for ourselves, building a whole set of admin tools with it. Now we're ready to keep that train going as we build out more of CodePen with the same stack. But removing Rails means moving off of our Rails-based GraphQL implementation. This means re-writing that API in Go, another bit of tech we've had a lot of luck with. Turns out that re-writing an API is more time-consuming than writing it to begin with, especially as we need to run them side-by-side and behave identically. No refactoring allowed! Unless of course we want to refactor it on both sides and take even more time. Dee joined me this week in talking about all this. It's a huge job! But we've been doing well at it, building our own tooling, doing lots of testing, and ultimately proving that it works by releasing it in small areas on the production site. It's all working out how we hoped it would: fast, cheap, and easier to reason about. Time Jumps Sponsor: Equinix Metal's Startup Partner Program Equinix Metal's Startup Partner Program helps early stage companies level up. Their experts work with startups like Koord and INVISV to build their competitive edge with infrastructure. Equinix Metal provides real time guidance and support to help startups grow faster. With up to $100,000 in infrastructure credit, access to Equinix's global ecosystem of over 10,000 customers and 1,800 networks, they might just be what you need to take your startup global. Visit metal.equinix.com/startups to take your startup to the next level.

The Bike Shed
359: Serializers

The Bike Shed

Play Episode Listen Later Oct 25, 2022 44:10


Chris Toomey is back! (For an episode.) He talks about what he's been up to since handing off the reins to Joël. He's been playing around with something at Sagewell that he enjoys. At the core of it? Serializers. Primalize gem (https://github.com/jgaskins/primalize) Derek's talk on code review (https://www.youtube.com/watch?v=PJjmw9TRB7s) Inertia.js (https://inertiajs.com/) Phantom types (https://thoughtbot.com/blog/modeling-currency-in-elm-using-phantom-types) io-ts (https://gcanti.github.io/io-ts/) dry-rb (https://dry-rb.org/) parse don't validate (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) value objects (http://wiki.c2.com/?ValueObject) broader perspective on parsing (https://thoughtbot.com/blog/a-broader-take-on-parsing) Enumerable#tally (https://medium.com/@baweaver/ruby-2-7-enumerable-tally-a706a5fb11ea) RubyConf mini (https://www.rubyconfmini.com/) where.missing (https://boringrails.com/tips/activerecord-where-missing-associations) Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. And today, I'm joined by a very special guest, former host Chris Toomey. CHRIS: Hi, Joël. Thanks for having me. JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Chris, what's new in your world? CHRIS: Being on this podcast is new in my world, or everything old is new again, or something along those lines. But, yeah, thank you so much for having me back. It's a pleasure. Although it's very odd, it feels somehow so different and yet very familiar. But yeah, more generally, what's new in my world? I think this was probably in development as I was winding down my time as a host here on The Bike Shed, but I don't know that I ever got a chance to talk about it. There has been a fun sort of deep-in-the-weeds technical thing that we've been playing around with at Sagewell that I've really enjoyed. So at the core of it, we have serializers. So we take some data structures in our Ruby on Rails code base, and we need to serialize them to JSON to send them to the front end. In our case, we're using Inertia, so it's not quite a JSON API, but it's fine to think about it in that way for the context of this discussion. And what we were finding is our front end has TypeScript. So we're writing Svelte, which is using TypeScript. And so we're stating or asserting that the types like, hey, we're going to get this data in from the back end, and it's going to have this shape to it. And we found that it was really hard to keep those in sync to keep, like, what does the user mean on the front end? What's the data that we're going to get? It's going to have a full name, which is a string, except sometimes that might be null. So how do we make sure that those are keeping up to date? And then we had a growing number of serializers on the back end and determining which serializer we were actually using, and it was just...it was a mess, to put it lightly. And so we had explored a couple of different options around it, and eventually, we found a library called Primalize. So Primalize is a Ruby library. It is for writing JSON serializers. But what's really interesting about it is it has a typing layer. It's like a type system sort of thing at play. So when you define a serializer in Primalize, instead of just saying, here are the fields; there is an ID, a name, et cetera, you say, there is an ID, and it is a string. There is a name, and it is a string, or an optional string, which is the even more interesting bit. You can say array. You can say object. You can say an enum of a couple of different values. And so we looked at that, and we said, ooh, this is very interesting. Astute listeners will know that this is probably useless in a Ruby system, which doesn't have types or a compilation step or anything like that. But what's really cool about this is when you use a Primalize serializer, as you're serializing an object, if there is ever a type mismatch, so the observed type at runtime and the authored type if those ever mismatch, then you can have some sort of notification happen. So in our case, we configured it to send a warning to Sentry to say, "Hey, you said the types were this, but we're actually seeing this other thing." Most often, it will be like an Optional, a null sneaking through, a nil sneaking through on the Ruby side. But what was really interesting is as we were squinting at this, we're like, huh, so now we're going to write all this type information. What if we could somehow get that type information down to the front end? So I had a long weekend, one weekend, and I went away, and I wrote a bunch of code that took all of those serializers, ran through them, and generated the associated TypeScript interfaces. And so now we have a build step that will essentially run that and assert that we're getting the same thing in CI as we have committed to the codebase. But now we have the generated serializer types on the front end that match to the used serializer on the back end, as well as the observed run-time types. So it's a combination of a true compilation step type system on the front end and a run-time type system on the back end, which has been very, very interesting. JOËL: I have a lot of thoughts here. CHRIS: I figured you would. [laughs] JOËL: But the first thing that came to mind is, as a consultant, there's a scenario with especially smaller startups that generally concerns me, and that is the CTO goes away for a weekend and writes a lot of code... CHRIS: [laughs] JOËL: And brings in a new system on Monday, which is exactly what you're describing here. How do you feel about the fact that you've done that? CHRIS: I wasn't ready to go this deep this early on in this episode. JOËL: [laughs] CHRIS: But honestly, that is a fantastic question. It's a thing that I have been truly not struggling with but really thinking about. We're going to go on a slight aside here, but I am finding it really difficult to engage with the actual day-to-day coding work that we're doing and to still stay close to the codebase and not be in the way. There's a pattern that I've seen happen a number of times now where I pick up a piece of work that is, you know, one of the tickets at the top of the backlog. I start to work on it. I get pulled into a meeting, then another meeting, then three more meetings. And suddenly, it's three days later. I haven't completed this piece of work that was defined to be the next most important piece of work. And suddenly, I'm blocking the team. JOËL: Hmmm. CHRIS: So I actually made a rule that I'm not allowed to own critical path work, which feels weird because it's like, I want to be engaged with that work. So the counterpoint to that is I'm now trying to schedule pairing sessions with each of the developers on the team once a week. And in that time, I can work on that sort of stuff with them, and they'll then own it and run with it. So it makes sure that I'm not blocking on those sorts of things, but I'm still connected to the core work that we're doing. But the other thing that you're describing of the CTO goes away for the weekend and then comes back with a new harebrained scheme; I'm very sensitive to that, having worked on; frankly, I think the same project. I can think of a project that you and I worked on where we experienced this. JOËL: I think we're thinking of the same project. CHRIS: So yes. Like, I'm scarred by that and, frankly, a handful of experiences of that nature. So we actually, I think, have a really healthy system in place at Sagewell for capturing, documenting, prioritizing this sort of other work, this developer-centric work. So this is the feature and bug work that gets prioritized and one list over here that is owned by our product manager. Separately, the dev team gets to say, here are the pain points. Here's the stuff that keeps breaking. Here are the things that I wish was better. Here is the observability hard-to-understand bits. And so we have a couple of different systems at play and recurring meetings and sort of unique ceremonies around that, and so this work was very much a fallout of that. It was actually a recurring topic that we kept trying a couple of different stabs at, and we never quite landed it. And then I showed up this one Monday morning, and I was like, "I found a thing; what do we think?" And then, critically, from there, I made sure I paired with other folks on the team as we pushed on the implementation. And then, actually, I mentioned Primalize, the library that we're using. We have now since deprecated Primalize within the app because we kept just adding to it so much that eventually, we're like, at this point, should we own this stuff? So we ended up rewriting the core bits of Primalize to better fit our use cases. And now we've actually removed Primalize, wonderful library. I highly recommend it to anyone who has that particular use case but then the additional type generation for the front end. Plus, we have some custom types within our app, Money being the most interesting one. We decided to model Money as our first-class consideration rather than just letting JavaScript have the sole idea of a number. But yes, in a very long-winded way, yes, I'm very sensitive to the thing you described. And I hope, in this case, I did not fall prey to the CTO goes away for the weekend and made a thing. JOËL: I think what I'm hearing is the key difference here is that you got buy-in from the team around this idea before you went out and implemented it. So you're not off doing your own things disconnected from the team and then imposing it from on high. The team already agreed this is the thing we want to do, and then you just did it for them. CHRIS: Largely, yes. Although I will say there are times that each developer on the team, myself included, have sort of gone away, come back with something, and said, "Hey, here's a WIP PR exploring an area." And there was actually...I'm forgetting what the context was, but there was one that happened recently that I introduced. I was like; I had to do this. And the team talked me out of it, and I ended up closing that PR. Someone else actually made a different PR that was an alternative implementation. I was like, no, that's better; we should absolutely do that. And I think that's really healthy. That's a hard thing to maintain but making sure that everyone feels like they've got a strong voice and that we're considering all of the different ways in which we might consider the work. Most critically, you know, how does this impact users at the end of the day? That's always the primary consideration. How do we make sure we build a robust, maintainable, observable system, all those sorts of things? And primarily, this work should go in that other direction, but I also don't want to stifle that creative spark of I got this thing in my head, and I had to explore it. Like, we shouldn't then need to never mind, throw away the work, put it into a ticket. Like, for as long as we can, that more organic, intuitive process if we can retain that, I like that. Critically, with the ability for everyone to tell me, "No, this is a bad idea. Stop it. What are you doing?" And that has happened recently. I mean, they were kinder about it, but they did talk me out of a bad idea. So here we are. JOËL: So you showed up on Monday morning, not with telling everyone, "Hey, I merged this thing over the weekend." You're showing up with a work-in-progress PR. CHRIS: Yes, definitely. I mean, everything goes through a PR, and everything has discussion and conversation around it. That's a strong, strong like Derek Prior's wonderful talk Building a Culture of Code Review. I forget the exact name of it. But it's one of my favorite talks in talking about the utility of code review as a way to share ideas and all of those wonderful things. So everything goes through code review, and particularly anything that is of that more exploratory architectural space. Often we'll say any one review from anyone on the team is sufficient to merge most things but something like that, I would want to say, "Hey, can everybody take a look at this? And if anyone has any reservations, then let's talk about it more." But if I or anyone else on the team for this sort of work gets everybody approving it, then cool, we're good to go. But yeah, code review critical, critical part of the process. JOËL: I'm curious about Primalize, the gem that you mentioned. It sounds like it's some kind of validation layer between some Ruby data structure and your serializers. CHRIS: It is the serializer, but in the process of serializing, it does run-time type validation, essentially. So as it's accessing, you know, you say first name. You have a user object. You pass it in, and you say, "Serializer, there's a first name, and it's a string." It will call the first name method on that user object. And then, it will check that it has the expected type, and if it doesn't, then, in our case, it sends to Sentry. We have configured it...it's actually interesting. In development and test mode, it will raise for a type mismatch, and in production mode, it will alert Sentry so you can configure that differently. But that ends up being really nice because these type mismatches end up being very loud early on. And it's surprisingly easy to maintain and ends up telling us a lot of truths about our system because, really, what we're doing is connecting data from many different systems and flowing it in and out. And all of the inputs and outputs from our system feel very meaningful to lock down in this way. But yeah, it's been an adventure. JOËL: It seems to me there could almost be two sets of types here, the inputs coming into Primalize from your Ruby data structures and then the outputs that are the actual serialized values. And so you might expect, let's say, an integer on the Ruby side, but maybe at the serialization level, you're serializing it to a string. Do you have that sort of conversion step as part of your serializers sometimes, or is the idea that everything's already the right type on the Ruby side, and then we just, like, to JSON it at the end? CHRIS: Yep. Primalize, I think, probably works a little closer to what you're describing. They have the idea of coercions. So within Primalize, there is the concept of a timestamp; that is one of the types that is available. But a timestamp is sort of the union of a date, a time, or I think they might let through a string; I'm not sure if there is as well. But frankly, for us, that was more ambiguity than we wanted or more blurring across the lines. And in the implementation that we've now built, date and time are distinct. And critically, a string is not a valid date or time; it is a string, that's another thing. And so there's a bunch of plumbing within the way you define the serializers. There are override methods so that you can locally within the serializer say, like, oh, we need to coerce from the shape of data into this other shape of data, even little like in-line proc, so we can do it quickly. But the idea is that the data, once it has been passed to the serializer, should be up the right shape. And so when we get to the type assertion part of the library, we expect that things are in the asserted type and will warn if not. We get surprisingly few warnings, which is interesting now. This whole process has made us pay a little more intention, and it's been less arduous simultaneously than I would have expected because like this is kind of a lot of work that I'm describing. And yet it ends up being very natural when you're the developer in context, like, oh, I've been reading these docs for days. I know the shape of this JSON that I'm working with inside and out, and now I'll just write it down in the serializer. It's very easy to do in that moment, and then it captures it and enforces it in such a useful way. As an aside, as I've been looking at this, I'm like, this is just GraphQL, but inside out, I'm pretty sure. But that is a choice that we have made. We didn't want to adopt the whole GraphQL thing. But just for anyone out there who is listening and is thinking, isn't this just GraphQL but inside out? Kind of. Yes. JOËL: I think my favorite part of GraphQL is the schema, which is not really the selling point for GraphQL, you know, like the idea that you can traverse the graph and get any subset of data that you want and all that. I think I would be more than happy with a REST API that has some kind of schema built around it. And someone told me that maybe what I really just want is SOAP, and I don't know how to feel about that comment. CHRIS: You just got to have some XML, and some WSDLs, and other fun things. I've heard people say good things about SOAP. SOAP seems like a fine idea. If anything, I think a critical part of this is we don't have a JSON API. We have a very tightly coupled front end and back end, and a singular front end, frankly. And so that I think naturally...that makes the thing that I'm describing here a much more comfortable fit. If we had multiple different downstream clients that we're trying to consume from the same back end, then I think a GraphQL API or some other structured JSON schema, whatever it is type of API, and associated documentation and typing layer would be probably a better fit. But as I've said many a time on this here, Bike Shed, Inertia is one of my favorite libraries or frameworks (They're probably more of a framework.) one of my favorite technological approaches that I have ever found. And particularly in buildings Sagewell, it has allowed us to move so rapidly the idea that changes are, you know, one fell swoop changes everything within the codebase. We don't have to think about syncing deploys for the back end and the front end and how to coordinate across them. Our app is so much easier to understand by virtue of that architecture that Inertia implies. JOËL: So, if I understand correctly, you don't serialize to JSON as part of the serializers. You're serializing directly to JavaScript. CHRIS: We do serialize to JSON. At the end of the day, Inertia takes care of this on both the Rails side and the client side. There is a JSON API. Like, if you look at the network inspector, you will see XHR requests happening. But critically, we're not doing that. We're not the ones in charge of it. We're not hitting a specific endpoint. It feels as an application coder much closer to a traditional Rails app. It just happens to be that we're writing our view layer. Instead of an ERB, we're writing them in Svelte files. But otherwise, it feels almost identical to a normal traditional Rails app with controllers and the normal routing and all that kind of stuff. JOËL: One thing that's really interesting about JSON as an interchange format is that it is very restrictive. The primitives it has are even narrower than, say, the primitives that Ruby has. So you'd mentioned sending a date through. There is no JSON date. You have to serialize it to some other type, potentially an integer, potentially a string that has a format that the other side knows how it's going to interpret. And I feel like it's those sorts of richer types when we need to pass them through JSON that serialization and deserialization or parsing on the other end become really interesting. CHRIS: Yeah, I definitely agree with that. It was a struggling point for a while until we found this new approach that we're doing with the serializers in the type system. But so far, the only thing that we've done this with is Money. But on the front end, a while ago, we introduced a specific TypeScript type. So it's a phantom type, and I believe I'm getting this correct. It's a phantom type called Cents, C-E-N-T-S. So it represents...I'm going to say an integer. I know that JavaScript doesn't have integers, but logically, it represents an integer amount of cents. And critically, it is not a number, like, the lowercase number in the type system. We cannot add them together. We can't -- JOËL: I thought you were going to say, NaN. CHRIS: [laughs] It is not a number. I saw a n/a for not applicable somewhere in the application the other day. I was like, oh my God, we have a NaN? It happened? But it wasn't, it was just n/a, and I was fine. But yeah, so we have this idea of Cents within the application. We have a money input, which is a special input designed exactly for this. So to a user, it is formatted to look like you're entering dollars and cents. But under the hood, we are bidirectionally converting that to the integer amount of cents that we need. And we strictly, within the type system, those are cents. And you can't do math on Cents unless you use a special set of helper functions. You cannot generate Cents on the fly unless you use a special set of helper functions, the constructor functions. So we've been really restrictive about that, which was kind of annoying because a lot of the data coming from the server is just, you know, numbers. But now, with this type system that we've introduced on the Ruby side, we can assert and enforce that these are money.new on the Ruby side, so using the Money gem. And they come down to the front end as capital C Cents in the type system on the TypeScript side. So we're able to actually bind that together and then enforce proper usage sort of on both sides. The next step that we plan to do after that is dates and times. And those are actually almost weirder because they end up...we just have to sort of say what they are, and they will be ISO 8601 date and time strings, respectively. But we'll have functions that know this is a date string; that's a thing. It is, again, a phantom type implemented within our TypeScript type system. But we will have custom functions that deal with that and really constrain...lock ourselves down to only working with them correctly. And critically, saying that is the only date and time format that we work with; there is no other. We don't have arbitrary dates. Is this a JSON date or something else? I don't know; there are too many date syntaxes. JOËL: I like the idea of what you're doing in that it sounds like you're very much narrowing that sort of window of where in the stack the data exists in the sort of unstructured, free-floating primitives that could be misinterpreted. And so, at this point, it's almost narrowed to the point where it can't be touched by any user or developer-written code because you've pushed the boundaries on the Rails side down and then on the JavaScript side up to the point where the translation here you define translations on one side or, I guess, a parser on one side and a serializer on the other. And they guarantee that everything is good up until that point. CHRIS: Yep, with the added fun of the runtime reflection on the Ruby side. So it's an interesting thing. Like, TypeScript actually has similar things. You can say what the type is all day long, and your code will consistently conform to that asserted type. But at the end of the day, if your JSON API gets in some different data...unless you're using a library like io-ts, is one that I've looked at, which actually does parsing and returns a result object of did we parse to the thing that you wanted or did we get an error in that data structure? So we could get to that level on the client side as well. We haven't done that yet largely because we've essentially pushed that concern up to the Ruby layer. So where we're authoring the data, because we own that, we're going to do it at that level. There are a bunch of benefits of defining it there and then sort of reflecting it down. But yeah, TypeScript, you can absolutely lie to yourself, whereas Elm, a language that I know you love dearly, you cannot lie to yourself in Elm. You've got to tell the truth. It's the only option. You've got to prove it. Whereas in TypeScript, you can just kind of suggest, and TypeScript will be like, all right, cool, I'll make sure you stay honest on that, but I'm not going to make you prove it, which is an interesting sort of set of related trade-offs there. But I think we found a very comfortable resting spot for right now. Although now, we're starting to look at the edges of the Ruby system where data is coming in. So we have lots of webhooks and other external partners that we're integrating with, and they're sending us data. And that data is of varying shapes. Some will send us a payload with the word amount, and it refers to an integer amount of cents because, of course, it does. Some will send us the word amount in their payload, and it will be a floating amount of dollars. And I get a little sad on those days. But critically, our job is to make sure all of those are the same and that we never pass dollars as cents or cents as dollars because that's where things go sad. That is job number one at Sagewell in the engineering team is never get the decimal place wrong in money. JOËL: That would be a pretty terrible mistake to make. CHRIS: It would. I mean, it happens. In fintech, that problem comes up a lot. And again, the fact that...I'm honestly surprised to see situations out there where we're getting in floating point dollars. That is a surprise to me because I thought we had all agreed sort of as a community that it was integer cents but especially in a language that has integers. JavaScript, it's kind of making it up the whole time. But Ruby has integers. JSON, I guess, doesn't have integers, so I'm sort of mixing concerns here, but you get the idea. JOËL: Despite Ruby not having a static type system, I've found that generally, when I'm integrating with a third-party API, I get to the point where I want something that approximates like Elm's JSON decoders or io-ts or something like that. Because JSON is just a big blob of data that could be of any shape, and I don't really trust it because it's third-party data, and you should not trust third parties. And I find that I end up maybe cobbling something together commonly with like a bunch of usage of hash.fetch, things like that. But I feel like Ruby doesn't have a great approach to parsing and composing these validators for external data. CHRIS: Ruby as a language certainly doesn't, and the ecosystem, I would say, is rather limited in terms of the options here. We have looked a bit at the dry-rb stack of gems, so dry-validation and dry-schema, in particular, both offer potentially useful aspects. We've actually done a little bit of spiking internally around that sort of thing of, like, let's parse this incoming data instead of just coercing to hash and saying that it's got probably the shape that we want. And then similarly, I will fetch all day instead of digging because I want to be quite loud when we get it wrong. But we're already using dry-monads. So we have the idea of result types within the system. We can either succeed or fail at certain operations. And I think it's just a little further down the stack. But probably something that we will implement soon is at those external boundaries where data is coming in doing some form of parsing and validation to make sure that it conforms to unknown data structure. And then, within the app, we can do things more cleanly. That also would allow us to, like, let's push the idea that this is floating point dollars all the way out to the edge. And the minute it hits our system, we convert it into a money.new, which means that cents are properly handled. It's the same type of money or dollar, same type of currency handling as everywhere else in the app. And so pushing that to the very edges of our application is a very interesting idea. And so that could happen in the library or sort of a parsing client, I guess, is probably the best way to think about it. So I'm excited to do that at some point. JOËL: Have you read the article, Parse, Don't Validate? CHRIS: I actually posted that in some code review the other day to one of the developers on the team, and they replied, "You're just going to quietly drop one of my favorite articles of all time in code review?" [laughs] So yes, I've read it; I love it. It's a wonderful idea, definitely something that I'm intrigued by. And sort of bringing dry-monads into Ruby, on the one hand, feels like a forced fit and yet has also been one of the other, I think strongest sort of architectural decisions that we've made within the application. There's so much imperative work that we ended up having to do. Send this off to this external API, then tell this other one, then tell this other one. Put the whole thing in a transaction so that our local data properly handles it. And having dry-monads do notation, in particular, to allow us to make that manageable but fail in all the ways it needs to fail, very expressive in its failure modes, that's been great. And then parse, don't validate we don't quite do it yet. But that's one of the dreams of, like, our codebase really should do that thing. We believe in that. So let's get there soon. JOËL: And the core idea behind parse, don't validate is that instead of just having some data that you don't trust, running a check on it and passing that blob of now checked but still untrusted data down to the next person who might also want to check it. Generally, you want to pass it through some sort of filter that will, one, validate that it's correct but then actually typically convert it into some other trusted shape. In Ruby, that might be something like taking an amorphous blob of JSON and turning it into some kind of value object or something like that. And then anybody downstream that receives, let's say, money object can trust that they're dealing with a well-formed money value as opposed to an arbitrary blob of JSON, which hopefully somebody else has validated, but who knows? So I'm going to validate it again. CHRIS: You can tell that I've been out of the podcasting game for a while because I just started responding to yes; I love that blog post without describing the core premise of it. So kudos to you, Joël; you are a fantastic podcast host over there. I will say one of the things you just described is an interesting...it's been a bit of a struggle for us. We keep sort of talking through what's the architecture. How do we want to build this application? What do we care about? What are the things that really matter within this codebase, and then what is all the other stuff? And we've been good at determining the things that really matter, thinking collectively as a group, and I think coming up with some novel, useful, elegant...I'm saying too many positive adjectives for what we're doing. But I've been very happy with sort of the thing that we decide. And then there's the long-tail work of actually propagating that change throughout the rest of the application. We're, like, okay, here's how it works. Every incoming webhook, we now parse and yield a value object. That sentence that you just said a minute ago is exactly what I want. That's like a bunch of work. It's particularly a bunch of work to convert an existing codebase. It's easy to say, okay, from here forward, any new webhooks, payloads that are coming in, we're going to do in this way. But we have a lot of things in our app now that exist in this half-converted way. There was a brief period where we had three different serializer technologies at play. Just this week, I did the work of killing off the middle ground one, the Primalized-based thing, and we now have only our new hotness and then the very old. We were using Blueprinter as the serializer as the initial sort of stub. And so that still exists within the codebase in some places. But trying to figure out how to prioritize that work, the finishing out those maintenance-type conversions is a tricky one. It's never the priority. But it is really nice to have consistency in a codebase. So it's...yeah, do you have any thoughts on that? JOËL: I think going back to the article and what the meaning of parsing is, I used to always think of parsing as taking strings and turning them into something else, and I think this really broadened my perspective on the idea of parsing. And now, I think of it more as converting from a broader type to a narrower type with failures. So, for example, you could go from a string to an integer, and not all strings are valid integers. So you're narrowing the type. And if you have the string hello world, it will fail, and it will give you an error of some type. But you can have multiple layers of that. So maybe you have a string that you parse into an integer, but then, later on, you might want to parse that integer into something else that requires an integer in a range. Let's say it's a percentage. So you have a value object that is a percentage, but it's encoded in the JSON as a string. So that first pass, you parse it from a string into an integer, and then you parse that integer into a percentage object. But if it's outside the range of valid percentage numbers, then maybe you get an error there as well. So it's a thing that can happen at multiple layers. And I've now really connected it with the primitive obsession smell in code. So oftentimes, when you decide, wait, I don't want a primitive here; I want a richer type, commonly, there's going to be a parsing step that should exist to go from that primitive into the richer type. CHRIS: I like that. That was a classic Joël wildly concise summary of a deeply complex technical topic right there. JOËL: It's like I'm going to connect some ideas from functional programming and a classic object-oriented code smell and, yeah, just kind of mash it all together with a popular article. CHRIS: If only you had a diagram. Podcast is not the best medium for diagrams, but I think you could do it. You could speak one out loud, and everyone would be able to see it in their mind's eye. JOËL: So I will tell you what my diagram is for this because I've actually created it already. I imagine this as a sort of like pyramid with different layers that keep getting smaller and smaller. So the size of type is sort of the width of a layer. And so your strings are a very wide layer. Then on top of that, you have a narrower layer that might be, you know, it could be an integer, or you could even if you're parsing JSON, you first start with a string, then you parse that into a Ruby hash, not all strings are valid hashes. So that's going to be narrower. Then you might extract some values out of that hash. But if the keys aren't right, that might also fail. You're trying to pull the user out of it. And so each layer it gets a richer type, but that richer type, by virtue of being richer, is narrower. And as you're trying to move up that pyramid at every step, there is a possibility for a failure. CHRIS: Have you written a blog post about this with said diagram in it? And is that why you have that so readily at hand? [laughs] JOËL: Yes, that is the case. CHRIS: Okay. Yeah, that made sense to me. [laughs] JOËL: We'll make sure to link to it in the show notes. CHRIS: Now you have to link to Joël blog posts, whereas I used to have to link to them [chuckles] in almost every episode of The Bike Shed that I recorded. JOËL: Another thing I've been thinking about in terms of this parsing is that parsing and serializing are, in a sense, almost opposites of each other. Typically, when you're parsing, you're going from a broad type to a narrow one. And when you're serializing, you're going from a narrow type to a broader one. So you might go from a user into a hash into a string. So you're sort of going down that pyramid rather than going up. CHRIS: It is an interesting observation and one that immediately my brain is like, okay, cool. So can we reuse our serializers but just run them in reverse or? And then I try and talk myself out of that because that's a classic don't repeat yourself sort of failure mode of, like, actually, it's fine. You can repeat a little bit. So long as you can repeat and constrain, that's a fine version. But yeah, feels true, though, at the core. JOËL: I think, in some ways, if you want a single source of truth, what you want is a schema, and then you can derive serializers and parsers from that schema. CHRIS: It's interesting because you used the word derive. That has been an interesting evolution at Sagewell. The engineering team seems to be very collected around the idea of explicitness, almost the Zen of Python; explicit is better than implicit. And we are willing to write a lot of words down a lot of times and be happy with that. I think we actually made the explicit choice at one point that we will not implement an automatic camel case conversion in our serializer, even though we could; this is a knowable piece of code. But what we want is the grepability from the front end to the back end to say, like, where's this data coming from? And being able to say, like, it is this data, which is from this serializer, which comes from this object method, and being able to trace that very literally and very explicitly in the code, even though that is definitely the sort of thing that we could derive or automatically infer or have Ruby do that translation for us. And our codebase is more verbose and a little noisier. But I think overall, I've been very happy with it, and I think the team has been very happy. But it is an interesting one because I've seen plenty of teams where it is the exact opposite. Any repeated characters must be destroyed. We must write code to write the code for us. And so it's fun to be working with a team where we seem to be aligned around an approach on that front. JOËL: That example that you gave is really interesting because I feel like a common thing that happens in a serialization layer is also a form of normalization. And so, for example, you might downcase all strings as part of the serialization, definitely, like dates always get written in ISO 8601 format whenever that happens. And so, regardless of how you might have it stored on the Ruby side, by the time it gets to the JSON, it's always in a standard format. And it sounds like you're not necessarily doing that with capitalization. CHRIS: I think the distinction would be the keys and the values, so we are definitely doing normalization on the values side. So ISO 8601 date and time strings, respectively that, is the direction that we plan to go for the value. But then for the key that's associated with that, what is the name for this data, those we're choosing to be explicit and somewhat repetitive, or not even necessarily repetitive, but the idea of, like, it's first_name on the Ruby side, and it's first capital N name camel case, or it's...I forget the name. It's not quite camel case; it's a different one but lower camel, maybe. But whatever JavaScript uses, we try to bias towards that when we're going to the front end. It does get a little tricky coming back into the Ruby side. So our controllers have a bunch of places where they need to know about what I think is called lower camel case, and so we're not perfect there. But that critical distinction between sort of the names for things, and the values for things, transformations, and normalizations on the values, I'm good with that. But we've chosen to go with a much more explicit version for the names of things or the keys in JSON objects specifically. JOËL: One thing that can be interesting if you have a normalization phase in your serializer is that that can mean that your serializer and parsers are not necessarily symmetric. So you might accept malformed data into your parser and parse it correctly. But then you can't guarantee that the data that gets serialized out is going to identically match the data that got parsed in. CHRIS: Yeah, that is interesting. I'm not quite sure of the ramifications, although I feel like there are some. It almost feels like formatting Prettier and things like that where they need to hold on to whitespace in some cases and throw out in others. I'm thinking about how ASTs work. And, I don't know, there's interesting stuff, but, again, not sure of the ramifications. But actually, to flip the tables just a little bit, and that's an aggressive terminology, but we're going to roll with it. To flip the script, let's go with that, Joël; what's been up in your world? You've been hosting this wonderful show. I've listened in to a number of episodes. You're doing a fantastic job. I want to hear a little bit more of what's new in your world, Joël. JOËL: So I've been working on a project that has a lot of flaky tests, and we're trying to figure out the source of that flakiness. It's easy to just dive into, oh, I saw a flaky Test. Let me try to fix it. But we have so much flakiness that I want to go about it a little bit more systematically. And so my first step has actually been gathering data. So I've actually been able to make API requests to our CI server. And the way we figure out flakiness is looking at the commit hash that a particular test suite run has executed on. And if there's more than one CI build for a given commit hash, we know that's probably some kind of flakiness. It could be a legitimate failure that somebody assumed was flakiness, and so they just re-run CI. But the symptom that we are trying to address is the fact that we have a very high level of people re-verifying their code. And so to do that or to figure out some stats, I made a request to the API grouped by commit hash and then was able to get the stats of how many re-verifications there are and even the distribution. The classic way that you would do that is in Ruby; you would use the GroupBy function from enumerable. And then, you would transform values instead of having, like, say; each commit hash then points to all the builds, an array of builds that match that commit hash. You would then thumb those. So now you have commit hashes that point to counts of how many builds there were for that commit hash. Newer versions of Ruby introduced the tally method, which I love, which allows you to basically do all of that in one step. One thing that I found really interesting, though, is that that will then give me a hash of commit hashes that point to the number of builds that are there. If I want to get the distribution for the whole project over the course of, say, the last week, and I want to say, "How many times do people run only one CI run versus running twice in the same commit versus running three times, or four times, or five or six times?" I want to see that distribution of how many times people are rerunning their build. You're effectively doing that tally process twice. So once you have a list of all the builds, you group by hash. You count, and so you end up with that. You have the Ruby hash of commit SHAs pointing to number of times the build was run on that. And then, you again group by the number of builds for each commit SHA. And so now what you have is you'll have something like one, and then that points to an array of SHA one, SHA two, SHA three, SHA four like all the builds. And then you tally that again, or you transform values, or however, you end up doing it. And what you end up with is saying for running only once, I now have 200 builds that ran only once. For running twice in the same commit SHA, there are 15. For running three times, there are two. For running four times, there is one. And now I've got my distribution broken down by how many times it was run. It took me a while to work through all of that. But now the shortcut in my head is going to be you double tally to get distribution. CHRIS: As an aside, the whole everything you're talking about is interesting and getting to that distribution. I feel like I've tried to solve that problem on data recently and struggled with it. But particularly tally, I just want to spend a minute because tally is such a fantastic addition to the Ruby standard library. I used to have in sort of like loose muscle memory transform value is grouped by ampersand itself, transform values count, sort, reverse to H. That whole string of nonsense gets replaced by tally, and, oof, what a beautiful example of Ruby, and enumerable, and all of the wonder that you can encapsulate there. JOËL: Enumerable is one of the best parts of Ruby. I love it so much. It was one of the first things that just blew my mind about Ruby when I started. I came from a PHP, C++ background and was used to writing for loops for everything and not the nice for each loops that a lot of languages have these days. You're writing like a legit for or while loop, and you're managing the indexes yourself. And there's so much room for things to go wrong. And being introduced to each blew my mind. And I was like, this is so beautiful. I'm not dealing with indexes. I'm not dealing with the raw implementation of the array. I can just say do a thing for each element. This is amazing. And that is when I truly fell in love with Ruby. CHRIS: I want to say I came from Python, most recently before Ruby. And Python has pretty nice list comprehensions and, in fact, in some ways, features that enumerable doesn't have. But, still, coming to Ruby, I was like, oh, this enumerable; this is cool. This is something. And it's only gotten better. It still keeps growing, and the idea of custom enumerables. And yeah, there's some real neat stuff in there. JOËL: I'm going to be speaking at RubyConf Mini this fall in November, and my talk is all about Enumerators and ranges in enumerable and ways you can use those to make the APIs of the objects that you create delightful for other people to use. CHRIS: That sounds like a classic Joël talk right there that I will be happy to listen to when it comes out. A very quick related, a semi-related aside, so, tally, beautiful addition to the Ruby language. On the Rails side, there was one that I used recently, which is where.missing. Have you seen where.missing? JOËL: I have not heard of this. CHRIS: So where.missing is fantastic. Let's assume you've got two related objects, so you've got like a has many blah, so like a user has many posts. I think you can...if I'm remembering it correctly, it's User.where.missing(:posts). So it's where dot missing and then parentheses the symbol posts. And under the hood, Rails will do the whole LEFT OUTER JOIN where the count is null, et cetera. It turns into this wildly complex SQL query or understandably complex, but there's a lot going on there. And yet it compresses down so elegantly into this nice, little ActiveRecord bit. So where.missing is my new favorite addition into the Rails landscape to complement tally on the Ruby side, which I think tally is Ruby 2.7, I want to say. So it's been around for a while. And where.missing might be a Ruby 7 feature. It might be a six-something, but still, wonderful features, ever-evolving these tool sets that we use. JOËL: One of the really nice things about enumerable and family is the fact that they build on a very small amount of primitives, and so as long as you basically understand blocks, you can use enumerable and anything in there. It's not special syntax that you have to memorize. It's just regular functions and blocks. Well, Chris, thank you so much for coming back for a visit. It's been a pleasure. And it's always good to have you share the cool things that you're doing at Sagewell. CHRIS: Well, thank you so much, Joël. It's been an absolute pleasure getting to come back to this whole Bike Shed. And, again, just to add a note here, you're doing a really fantastic job with the show. It's been interesting transitioning back into listener mode for the show. Weirdly, I wasn't listening when I was a host. But now I've regained the ability to listen to The Bike Shed and really enjoy the episodes that you've been doing and the wonderful spectrum of guests that you've had on and variety of topics. So, yeah, thank you for hosting this whole Bike Shed. It's been great. JOËL: And with that, let's wrap up. The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore. If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeeeeee!!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Salesforce Developer Podcast
146: GraphQL with Ben Sklar

Salesforce Developer Podcast

Play Episode Listen Later Oct 17, 2022 22:44


Ben Sklar is a Senior Product Manager here at Salesforce. Though he started college as a pre-med major, he quickly shifted his interests after taking a Coding 101 course. He went on to pursue Computer Science and even to do research at Vanderbilt University and Hamilton College. Today, Ben and I are talking about GraphQL. GraphQL is a new standard which provides significant performance and organizational benefits to API calls as opposed to REST.  Specifically, we're discussing how Salesforce is implementing it and how you can use it. Join us! Show Highlights: How Ben got into web technology and front-end engineering. How he got introduced to Salesforce and what he does in his current job here. An overview of GraphQL. The key limitation of REST that GraphQL is trying to solve. The two main ways to use GraphQL APIs. How lightning web components fit into all of this. More things on the roadmap for GraphQL. Links: Ben on LinkedIn: https://www.linkedin.com/in/benjamin-sklar/  

Syntax - Tasty Web Development Treats
Supper Club × Neovim, Lua, RPC and Twitch with TJ DeVries

Syntax - Tasty Web Development Treats

Play Episode Listen Later Oct 14, 2022 56:18 Very Popular


In this supper club episode of Syntax, Wes and Scott talk with TJ DeVries about his work on Neovim, programming in Lua, the benefits of RPC, live streaming your work day, and PDE. FireHydrant - Sponsor Incidents are hard. Managing them shouldn't be. FireHydrant makes it easy for anyone in your organization to respond to incidents efficiently and consistently. Intuitive, guided workflows provide turn-by-turn navigation for incident response, while thoughtful prompts and powerful integrations capture all of your incident data to drive useful retros and actionable analytics. Hasura - Sponsor With Hasura, you can get a fully managed, production-ready GraphQL API as a service to help you build modern apps faster. You can get started for free in 30 seconds, or if you want to try out the Standard tier for zero cost, use the code “TryHasura” at this link: hasura.info. We've also got an amazing selection of GraphQL tutorials at hasura.io/learn. Gatsby - Sponsor Today's episode was sponsored by Gatsby, the fastest frontend for the headless web. Gatsby is the framework of choice for content-rich sites backed by a headless CMS as its GraphQL data layer makes it straightforward to source website content from anywhere. Gatsby's opinionated, React-based framework makes the hardest parts of building a performant website simpler. Visit Gatsby.dev/Syntax to get your first Gatsby site up in minutes and experience the speed. ⚡️ Show Notes 00:36 Welcome 01:13 Guest introduction Teej_dv on Twitter TJ Devries Teej_DV on Twitch TJ on YouTube Telescope on GitHub Neovim on GitHub Syntax 508 with The Primeagan 03:15 The difference between Vim and Neovim 06:14 Why did you choose to write in Lua? Lua Luajit 13:26 What is adapative UI in Neovim? 17:38 Lunarvim and alternatives Fvim LunarVim 20:24 Personalized development environment PDE PDE Firenvim 22:40 Sponsor: FireHydrant 23:21 Benefits of RPC 30:34 Is working on Neovim your job? Sponsor Neovim Sourcegraph 31:30 What is your approach to streaming? 34:11 Did you go to school for computer science? 39:12 Sponsor: Gatsby 39:46 Supper Club questions System76 Pop Dactyl Manuform Keyboard Kit Jetbrains Mono 49:52 Sponsor: Hasura 50:47 SIIIIICK ××× PIIIICKS ××× Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

COMPRESSEDfm
093 | Full Time Content Creation

COMPRESSEDfm

Play Episode Listen Later Oct 11, 2022 39:58


Amy discusses with James his recent job change and how he plans to move forward in full time content creation.SponsorsZEALZEAL is a computer software agency that delivers “the world's most zealous” and custom solutions. The company plans and develops web and mobile applications that consistently help clients draw in customers, foster engagement, scale technologies, and ensure delivery.ZEAL believes that a business is “only as strong as” its team and cares about culture, values, a transparent process, leveling up, giving back, and providing excellent equipment. The company has staffers distributed throughout the United States, and as it continues to grow, ZEAL looks for collaborative, object-oriented, and organized individuals to apply for open roles.For more information visit codingzeal.comVercelVercel combines the best developer experience with an obsessive focus on end-user performance. Their platform enables frontend teams to do their best work. It is the best place to deploy any frontend app. Start by deploying with zero configuration to their global edge network. Scale dynamically to millions of pages without breaking a sweat.For more information, visit Vercel.comDatoCMSDatoCMS is a complete and performant headless CMS built to offer the best developer experience and user-friendliness in the market. It features a rich, CDN-powered GraphQL API (with realtime updates!), a super-flexible way to handle dynamic layouts and structured content, and best-in-class image/video support, with progressive/LQIP image loading out-of-the-box."For more information, visit datocms.comShow Notes00:00 Introduction00:54 James's Big Change04:54 Diversifying Content07:05 Full Time Content vs Full Time Dev09:19 Being Your Own Boss11:04 Running Workshops13:03 Sponsor: DatoCMS13:57 Feeding the Beast19:05 Process Changes20:33 Where to Start?23:23 Bad First Pancake25:24 Watching the Numbers26:33 Imposter Syndrome28:42 Sponsor: ZEAL29:36 Sponsored Rap30:12 Monthly Retainers and Freelance Dev Rel31:10 End Goal32:59 Is this freelance Dev Rel?33:37 Sponsor: Vercel34:44 Picks and Plugs

Syntax - Tasty Web Development Treats
Supper Club × ORMs with Nikolas Burke from Prisma

Syntax - Tasty Web Development Treats

Play Episode Listen Later Oct 7, 2022 62:33 Very Popular


In this supper club episode of Syntax, Wes and Scott talk with Nikolas Burke from Prisma about the role an ORM plays in a tech stack, how Prisma has changed over the years, ways to query data in Prisma, and how migrations work with Prisma. Hasura - Sponsor With Hasura, you can get a fully managed, production-ready GraphQL API as a service to help you build modern apps faster. You can get started for free in 30 seconds, or if you want to try out the Standard tier for zero cost, use the code “TryHasura” at this link: hasura.info. We've also got an amazing selection of GraphQL tutorials at hasura.io/learn. Storyblok - Sponsor Storyblok is a headless component-based CMS with a real-time visual editor. It offers the flexibility for developers to craft their perfect tech stack, but it also empowers content creators to make changes independently. The result is that every team has the freedom to quickly and easily create the ideal website with limitless extensibility. Other key features include robust Storyblok SDKs and APIs, powerful internationalization options, and an eCommerce-ready platform. FireHydrant - Sponsor Incidents are hard. Managing them shouldn't be. FireHydrant makes it easy for anyone in your organization to respond to incidents efficiently and consistently. Intuitive, guided workflows provide turn-by-turn navigation for incident response, while thoughtful prompts and powerful integrations capture all of your incident data to drive useful retros and actionable analytics. Did we mention that FireHydrant is free? Get started at Firehydrant.com/syntax. Show Notes 00:35 Welcome 01:30 Guest intro @NikolasBurk on Twitter 04:56 How has Prisma evolved? Prisma Keystone GraphQL 10:44 What was Prisma V1? 17:04 Is there any GraphQL specific functions in Prismic? 21:26 Sponsor: Hasura 22:26 What role does an ORM play in a tech stack? 29:54 What is Planetscale? Planetscale The T3 Stack 32:22 Where does TRPC fit? tRPC 33:46 Sponsor: Storyblok 35:28 What is an ORM? Prisma VS Code plugin 42:00 How do migrations work with Prisma? 45:58 Query your data with Prisma client 49:43 Have you looked into alternative JavaScript environments? 55:16 Sponsor: FireHydrant 57:05 Supper Club questions 58:50 SIIIIICK ××× PIIIICKS ××× ××× SIIIIICK ××× PIIIICKS ××× Lichess Shameless Plugs Prisma blog Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

Open Source Startup Podcast
E56: Add GraphQL APIs to Your Data with Hasura

Open Source Startup Podcast

Play Episode Listen Later Oct 6, 2022 42:15


Rajoshi Ghosh & Tanmai Gopal are the Co-founders of Hasura, the platform to create GraphQL APIs with your data. Hasura's open source graph-QL engine has over 28K stars. Hasura has raised $140M from investors including Lightspeed, Vertex, and Greenoaks Capital. In this episode, we discuss how open source builds trust, the difference between project-market fit and product-market fit, hiring for values, and much more!

Syntax - Tasty Web Development Treats
Supper Club × Open Sauced With bdougie

Syntax - Tasty Web Development Treats

Play Episode Listen Later Sep 30, 2022 53:02 Very Popular


In this supper club episode of Syntax, Wes and Scott talk with bdougie about his work on Open Sauced, thoughts on getting into open source development, and his live streaming set up. Hasura - Sponsor With Hasura, you can get a fully managed, production-ready GraphQL API as a service to help you build modern apps faster. You can get started for free in 30 seconds, or if you want to try out the Standard tier for zero cost, use the code “TryHasura” at this link: hasura.info. We've also got an amazing selection of GraphQL tutorials at hasura.io/learn. FireHydrant - Sponsor Incidents are hard. Managing them shouldn't be. FireHydrant makes it easy for anyone in your organization to respond to incidents efficiently and consistently. Intuitive, guided workflows provide turn-by-turn navigation for incident response, while thoughtful prompts and powerful integrations capture all of your incident data to drive useful retros and actionable analytics. Get started at Firehydrant.com/syntax Storyblok - Sponsor Storyblok is a headless component-based CMS with a real-time visual editor. It offers the flexibility for developers to craft their perfect tech stack, but it also empowers content creators to make changes independently. The result is that every team has the freedom to quickly and easily create the ideal website with limitless extensibility. Other key features include robust Storyblok SDKs and APIs, powerful internationalization options, and an eCommerce-ready platform. Show Notes 00:36 Welcome 01:52 Guest introduction OpenSauced.pizza @Bdougieyo on TikTok bdougie on Twitch Open Sauced on YouTube bdougie on YouTube Jamstack Netlify 03:36 What was the inspiration for Open Sauced? 08:23 GitHub GraphQL API 13:22 What are your thoughts on GraphQL? GraphQL 14:36 What is the T3 stack? 16:30 Sponsor: Hasura 17:53 What is the goal for Open Sauced? Open Sauced Beta for Hacktoberfest 20:08 What is your focus with live streaming? T3 Stack Vite The Primeagan on Syntax Episode 508 Octoverse Hot Open Sauced Pizza 21:39 What hardware and software do you live stream with? Rode Procaster Wave XLR GoXLR OBS 25:26 Should adults be on TikTok? 30:31 How do you build an algorithm? 32:44 Sponsor: Storyblok 34:01 Supper club questions Keychron K2 Warp Ghostwriter from Replit A first look at GitHub Copilot Stable Diffusion Fig 43:17 Sponsor: FireHydrant 44:36 Interviews with open source maintainers 45:55 How should maintainers get paid? Patreon GitHub Sponsors Neovim Vim Adventures Lunar Vim 47:47 SIIIIICK ××× PIIIICKS ××× 51:34 Shameless Plugs ××× SIIIIICK ××× PIIIICKS ××× bdougie: Warp Shameless Plugs bdougie on Twitter saucedopen on Twitter Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

COMPRESSEDfm
086 | Chrome Developer Tools Walkthrough

COMPRESSEDfm

Play Episode Listen Later Sep 23, 2022 54:58


In this episode, James and Amy talk about the Chrome Developer Tools including familiar tabs like Elements, Console, Network, and a few you've probably never heard of! They also share some of their favorite tips and tricks along the way.SponsorsZEALZEAL is a computer software agency that delivers “the world's most zealous” and custom solutions. The company plans and develops web and mobile applications that consistently help clients draw in customers, foster engagement, scale technologies, and ensure delivery.ZEAL believes that a business is “only as strong as” its team and cares about culture, values, a transparent process, leveling up, giving back, and providing excellent equipment. The company has staffers distributed throughout the United States, and as it continues to grow, ZEAL looks for collaborative, object-oriented, and organized individuals to apply for open roles.For more information visit codingzeal.comVercelVercel combines the best developer experience with an obsessive focus on end-user performance. Their platform enables frontend teams to do their best work. It is the best place to deploy any frontend app. Start by deploying with zero configuration to their global edge network. Scale dynamically to millions of pages without breaking a sweat.For more information, visit Vercel.comDatoCMSDatoCMS is a complete and performant headless CMS built to offer the best developer experience and user-friendliness in the market. It features a rich, CDN-powered GraphQL API (with realtime updates!), a super-flexible way to handle dynamic layouts and structured content, and best-in-class image/video support, with progressive/LQIP image loading out-of-the-box."For more information, visit datocms.comShow Notes00:00:00 - Intro00:04:43 - Amy's Trip to Berlin for Prisma Days00:07:47 - What Are Chrome Developer Tools?00:12:18 - The Elements Tab00:16:00 - Sponsor: DatoCMS00:16:54 - Tweaking Styles in the Elements Tab00:19:06 - The Layout Tab, Event Listeners, Breakpoints, and Accessibility Tabs00:23:34 - The Console00:27:18 - Sponsor: Zeal00:28:12 - Performance Insights and Performance00:29:07 - Debugging and the Sources Tab00:31:22 - The Network Tab00:37:07 - Sponsor:  Vercel00:38:14 - The Application Tab - Local Storage, Cookies, and More00:41:30 - The Lighthouse Tab and Framework Specific Tabs00:44:52 - Grab Bag Questions00:50:02 - Picks and Plugs

COMPRESSEDfm
085 | Casual Conversations on Github Copilot, Frameworks, Desk Setups, Serverless, and More

COMPRESSEDfm

Play Episode Listen Later Sep 21, 2022 46:02


In this episode, James and Amy answer questions from the audience about Github Copilot, modern frameworks, Serverless vs Express.js, PlanetScale vs Supabase vs Firebase, and more!SponsorsZEALZEAL is a computer software agency that delivers “the world's most zealous” and custom solutions. The company plans and develops web and mobile applications that consistently help clients draw in customers, foster engagement, scale technologies, and ensure delivery.ZEAL believes that a business is “only as strong as” its team and cares about culture, values, a transparent process, leveling up, giving back, and providing excellent equipment. The company has staffers distributed throughout the United States, and as it continues to grow, ZEAL looks for collaborative, object-oriented, and organized individuals to apply for open roles.For more information visit codingzeal.comVercelVercel combines the best developer experience with an obsessive focus on end-user performance. Their platform enables frontend teams to do their best work. It is the best place to deploy any frontend app. Start by deploying with zero configuration to their global edge network. Scale dynamically to millions of pages without breaking a sweat.For more information, visit Vercel.comDatoCMSDatoCMS is a complete and performant headless CMS built to offer the best developer experience and user-friendliness in the market. It features a rich, CDN-powered GraphQL API (with realtime updates!), a super-flexible way to handle dynamic layouts and structured content, and best-in-class image/video support, with progressive/LQIP image loading out-of-the-box."For more information, visit datocms.comShow Notes00:00:00 - Intro00:02:16 - Github Copilot Controversy00:15:08 - Sponsor: DatoCMS00:16:02 - Thoughts on Next JS,Redwood, Remix, and More00:23:27 - Sponsor: ZEAL00:24:22 - Desk Cable Management 00:30:25 - Serverless vs Express.js00:34:50 - Prisma and PlanetScale00:37:17 - Sponsor:  Vercel00:38:24 - Script for YouTube Images00:39:42 - PlanetScale vs Firebase vs Supabase

COMPRESSEDfm
84 | Building a SvelteKit Wordle Clone

COMPRESSEDfm

Play Episode Listen Later Sep 19, 2022 55:14


In this episode, James talks about his experience using SvelteKit to re-create the famous guessing game, Wordle.SponsorsZEALZEAL is a computer software agency that delivers “the world's most zealous” and custom solutions. The company plans and develops web and mobile applications that consistently help clients draw in customers, foster engagement, scale technologies, and ensure delivery.ZEAL believes that a business is “only as strong as” its team and cares about culture, values, a transparent process, leveling up, giving back, and providing excellent equipment. The company has staffers distributed throughout the United States, and as it continues to grow, ZEAL looks for collaborative, object-oriented, and organized individuals to apply for open roles.For more information visit codingzeal.comVercelVercel combines the best developer experience with an obsessive focus on end-user performance. Their platform enables frontend teams to do their best work. It is the best place to deploy any frontend app. Start by deploying with zero configuration to their global edge network. Scale dynamically to millions of pages without breaking a sweat.For more information, visit Vercel.comDatoCMSDatoCMS is a complete and performant headless CMS built to offer the best developer experience and user-friendliness in the market. It features a rich, CDN-powered GraphQL API (with realtime updates!), a super-flexible way to handle dynamic layouts and structured content, and best-in-class image/video support, with progressive/LQIP image loading out-of-the-box."For more information, visit datocms.comShow Notes00:00:00 - Intro00:03:57 - Svelte vs SvelteKit and Wordle00:10:29 - Sponsor: Vercel00:11:36 - How Wordle Works00:15:51 - SvelteKit Stores for Game State00:19:01 - Sponsor: Zeal00:19:53 - More on Game State00:21:33 - Working with LocalStorage00:27:43 - Creating the Keyboard00:29:53- Game Logic for Guessing Letter00:31:12 - Sponsor: DatoCMS00:32:05 - Color-coded Feedback On Guesses00:36:46 - Adding Transitions on Guessed Letters00:38:19 - Custom Overlay and Alert Components00:47:17 - Grab Bag Questions00:50:20 - Picks and PlugsLinksSource Code - https://github.com/jamesqquick/sveltekit-wordle-cloneWordle Game - https://www.nytimes.com/games/wordle/index.html(Amy Plug) Advent of CSS - https://adventofcss.com/(Amy Plug #2) Advent of JS - https://adventofcss.com/(James Pick) - https://www.amazon.com/Wireless-Charging-Case-Compatible-Microphones/dp/B09C1G9Z1D(James Plug) - https://www.youtube.com/c/jamesqquick

COMPRESSEDfm
83 | An Introduction to Github Actions

COMPRESSEDfm

Play Episode Listen Later Sep 17, 2022 47:18


In this episode, Amy and James explain Github Actions: what they are, how they work, use cases, and more. Amy also shares some of her personal experience in setting up Github Actions in a recent project.SponsorsZEALZEAL is a computer software agency that delivers “the world's most zealous” and custom solutions. The company plans and develops web and mobile applications that consistently help clients draw in customers, foster engagement, scale technologies, and ensure delivery.ZEAL believes that a business is “only as strong as” its team and cares about culture, values, a transparent process, leveling up, giving back, and providing excellent equipment. The company has staffers distributed throughout the United States, and as it continues to grow, ZEAL looks for collaborative, object-oriented, and organized individuals to apply for open roles.For more information visit codingzeal.comVercelVercel combines the best developer experience with an obsessive focus on end-user performance. Their platform enables frontend teams to do their best work. It is the best place to deploy any frontend app. Start by deploying with zero configuration to their global edge network. Scale dynamically to millions of pages without breaking a sweat.For more information, visit Vercel.comDatoCMSDatoCMS is a complete and performant headless CMS built to offer the best developer experience and user-friendliness in the market. It features a rich, CDN-powered GraphQL API (with realtime updates!), a super-flexible way to handle dynamic layouts and structured content, and best-in-class image/video support, with progressive/LQIP image loading out-of-the-box."For more information, visit datocms.comShow Notes00:00:00 - Intro00:05:27 - What are GitHub actions?00:12:59 - Sponsor: DatoCMS00:13:53 - Linting or Formatting00:24:34 - Sponsor:  Vercel00:30:03 - Sponsor: Zeal00:30:56 - Other Use Cases00:37:12 - Grab Bag Questions00:44:00 - Picks and PlugsLinksLearn Github Actions - https://docs.github.com/en/actions/learn-github-actionsQuickstart for Github Actions - https://docs.github.com/en/actions/quickstartLevel Up Tutorials Course on Github Actions from Brian Douglass - https://leveluptutorials.com/tutorials/code-automation-with-github/introduction(James Pick) Rode Wireless Go - https://www.amazon.com/Rode-Microphones-Wireless-Channel-Microphone/dp/B08XFQ6KP9(James Plug) YouTube Channel - https://www.youtube.com/c/jamesqquick(Amy Pick) ELOH IPhone Game - https://apps.apple.com/us/app/eloh/id1406382064(Amy Plug) Learn Build Teach Discord - https://learnbuildteach.com/

Future Founder Promise
Stephan Schneider | Clip #04 | Main Stellate Learnings | Striving For Excellence | Frequent Retrospectives | Liked-Learned-Long For | Overstepping | Developer Buy In | Alignment Phase | Feeling Heard

Future Founder Promise

Play Episode Listen Later Sep 13, 2022 8:45


A FFP interview with Stellate Software Engineer Stephan Schneider. Stephan is a Berlin based software engineer with a deep love for backend logic and a living example that attending meetups can help your career progression. He started working for Contentful after being on one of the meetups they hosted and stuck with them for many years, building and maintaining various APIs, including their GraphQL API from scratch. He later toured a few meetups to give back to the community by talking about the lessons learned - design decisions, developer experience and performance on scale - and ended up chatting with the Stellate team on one of those. Now he's an engineer for Stellate, doubling-down on what he loves to do: helping users with their backend APIs. Hear Stephan's perspective on: Main Stellate learnings Striving for excellence Frequent retrospectives Retro culture Liked-Learned-Long for Overstepping Developer buy in Alignment phase Feeling heard Uncomfortable learnings Blame-free environment Feedback culture and much more… We are currently hiring for a lot of new positions at Stellate. If you got interested in potentially working with us, please take a look at our hiring page.

COMPRESSEDfm
81 | 10 Common Accessibility Mistakes to Avoid

COMPRESSEDfm

Play Episode Listen Later Sep 12, 2022 48:45


James and Amy discuss common accessibility mistakes that you should avoid in your web applications.SponsorsZEALZEAL is a computer software agency that delivers “the world's most zealous” and custom solutions. The company plans and develops web and mobile applications that consistently help clients draw in customers, foster engagement, scale technologies, and ensure delivery.ZEAL believes that a business is “only as strong as” its team and cares about culture, values, a transparent process, leveling up, giving back, and providing excellent equipment. The company has staffers distributed throughout the United States, and as it continues to grow, ZEAL looks for collaborative, object-oriented, and organized individuals to apply for open roles.For more information visit codingzeal.comVercelVercel combines the best developer experience with an obsessive focus on end-user performance. Their platform enables frontend teams to do their best work. It is the best place to deploy any frontend app. Start by deploying with zero configuration to their global edge network. Scale dynamically to millions of pages without breaking a sweat.For more information, visit Vercel.comDatoCMSDatoCMS is a complete and performant headless CMS built to offer the best developer experience and user-friendliness in the market. It features a rich, CDN-powered GraphQL API (with realtime updates!), a super-flexible way to handle dynamic layouts and structured content, and best-in-class image/video support, with progressive/LQIP image loading out-of-the-box."For more information, visit datocms.comShow Notes00:00:00 - Intro00:02:54 - What is Accessibility00:10:59 - Sponsor Shoutout: Dato CMS00:11:52- 1. Not Using Alt Tags on Images00:15:30 - 2. Not Using Semantic HTML Tags00:22:16 - 3. Not Checking for Accessible Colors and Contrast Ratio  00:24:18 - 4. Relying on Color To Communicate00:26:10 - 5. Not Adding Validation to Your Forms00:29:39 - 6. Setting Outline to None00:30:45 - 7. Ignoring Reduced Motion Preferences00:33:08 - Sponsor Shoutout: Zeal00:34:00 - 8. Using Non-descriptive Link Text00:35:16 - 9. Not Using Aria Role Tag00:37:29 - 10. Not Labeling Your Input Fields00:39:16 - Additional Resources00:40:50 - Grab Bag Questions00:41:16 - Picks and PlugsLinksGive a Damn About Accessibiility - https://www.accessibility.uxdesign.cc/A11ycasts - https://www.youtube.com/playlist?list=PLNYkxOF6rcICWx0C9LVWWVqvHlYJyqw7gStorybook - https://storybook.js.org/Deque - https://www.deque.com/Ekster Wallet - https://ekster.com/Peak Design Bag - https://www.peakdesign.com/products/travel-duffel

Syntax - Tasty Web Development Treats
Supper Club × The Primeagan - Vim, Streaming, Rust, all Around Interesting Guy

Syntax - Tasty Web Development Treats

Play Episode Listen Later Sep 9, 2022 64:21 Very Popular


In this supper club episode of Syntax, Wes and Scott talk with The Primeagan about his streaming set up, how he decides what to stream, why he makes the kind of content he does, and why he loves Vim. Hasura - Sponsor With Hasura, you can get a fully managed, production-ready GraphQL API as a service to help you build modern apps faster. You can get started for free in 30 seconds, or if you want to try out the Standard tier for zero cost, use the code “TryHasura” at this link: hasura.info. We've also got an amazing selection of GraphQL tutorials at hasura.io/learn. Storyblok - Sponsor Storyblok is a headless component-based CMS with a real-time visual editor. It offers the flexibility for developers to craft their perfect tech stack, but it also empowers content creators to make changes independently. The result is that every team has the freedom to quickly and easily create the ideal website with limitless extensibility. Other key features include robust Storyblok SDKs and APIs, powerful internationalization options, and an eCommerce-ready platform. Show Notes 00:35 Welcome 01:48 Guest introduction ThePrimeagen on YouTube ThePrimeagen on Twitch @ThePrimeagen on Twitter Why I Make Content 03:53 Dropping in on skateboarding Tony Hawk's Pro Skater 05:43 What do you do? 07:17 How do you plan your live streams? 10:05 Sponsor: Hasura 11:27 Do you do interactive content via OBS on stream? OBS 16:22 What languages do you use on stream? Bun Zig 22:03 What do you try to build on stream? 24:53 Sponsor: StoryBlok 25:45 Why do you use Vim? 38:42 Do you ever have to do pair programming with Vim? 40:43 What kind of hardware are you playing with? Arduino 42:52 Supper club questions Lemur Pop Kinesis Advantage 2 56:20 SIIIIICK ××× PIIIICKS ××× Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

Future Founder Promise
Stephan Schneider | Clip #03 | New Job | GraphQL Love | Quitting Beloved Job | Joining Small Startup | Productive Pair Programming | Flow State | Feeling Productive | Starting vs Proceeding

Future Founder Promise

Play Episode Listen Later Sep 6, 2022 14:43


A FFP interview with Stellate Software Engineer Stephan Schneider. Stephan is a Berlin based software engineer with a deep love for backend logic and a living example that attending meetups can help your career progression. He started working for Contentful after being on one of the meetups they hosted and stuck with them for many years, building and maintaining various APIs, including their GraphQL API from scratch. He later toured a few meetups to give back to the community by talking about the lessons learned - design decisions, developer experience and performance on scale - and ended up chatting with the Stellate team on one of those. Now he's an engineer for Stellate, doubling-down on what he loves to do: helping users with their backend APIs. Hear Stephan's perspective on: New job GraphQL love Fading product attachment Quitting beloved job Joining small startup Productive pair programming Flow state Feeling productive Pairing engineering culture Sharing domain knowledge “The War Of Art” Starting vs proceeding Larger companies Office vs remote experience Meetup recruitment Quitting secure job Family support and much more… We are currently hiring for a lot of new positions at Stellate. If you got interested in potentially working with us, please take a look at our hiring page.

COMPRESSEDfm
All Things Serverless

COMPRESSEDfm

Play Episode Listen Later Sep 2, 2022 64:46


Episode NotesJames and Amy talk about everything Serverless and how it fits into modern Web Development. They discuss Serverless Functions, hosting platforms (Netlify, Vercel, and Cloudflare), frameworks and tools, benefits, Edge Functions, and more.SponsorsZEALZEAL is a computer software agency that delivers “the world's most zealous” and custom solutions. The company plans and develops web and mobile applications that consistently help clients draw in customers, foster engagement, scale technologies, and ensure delivery.ZEAL believes that a business is “only as strong as” its team and cares about culture, values, a transparent process, leveling up, giving back, and providing excellent equipment. The company has staffers distributed throughout the United States, and as it continues to grow, ZEAL looks for collaborative, object-oriented, and organized individuals to apply for open roles.For more information visit codingzeal.comVercelVercel combines the best developer experience with an obsessive focus on end-user performance. Their platform enables frontend teams to do their best work. It is the best place to deploy any frontend app. Start by deploying with zero configuration to their global edge network. Scale dynamically to millions of pages without breaking a sweat.For more information, visit Vercel.comDatoCMSDatoCMS is a complete and performant headless CMS built to offer the best developer experience and user-friendliness in the market. It features a rich, CDN-powered GraphQL API (with realtime updates!), a super-flexible way to handle dynamic layouts and structured content, and best-in-class image/video support, with progressive/LQIP image loading out-of-the-box."For more information, visit datocms.comShow Notes00:00:00 - Intro00:00:45 - What Have We Been Up To00:05:35 - Rant: Should You Leave Comments in Your Code?!00:10:23 - Overview of Serverless00:15:00 - Sponsor: Vercel00:21:00 - Sponsor: Zeal00:21:53 - Overview of the Jamstack and Serverless Functions00:35:27 - Sponsor DatoCMS00:37:32 - Benefits of Serverless00:45:41 - Edge Computing  00:51:02 - Grab Bag Questions01:01:49 - Picks and Plugs

Future Founder Promise
Stephan Schneider | Clip #02 | Dream Job | Back-End Attraction | Community Adoption Benefits | Facebook's Recruiting Masterstroke | Longing To Learn | Triangulating Feedback | “Listening To Listen”

Future Founder Promise

Play Episode Listen Later Sep 1, 2022 11:40


A FFP interview with Stellate Software Engineer Stephan Schneider. Stephan is a Berlin based software engineer with a deep love for backend logic and a living example that attending meetups can help your career progression. He started working for Contentful after being on one of the meetups they hosted and stuck with them for many years, building and maintaining various APIs, including their GraphQL API from scratch. He later toured a few meetups to give back to the community by talking about the lessons learned - design decisions, developer experience and performance on scale - and ended up chatting with the Stellate team on one of those. Now he's an engineer for Stellate, doubling-down on what he loves to do: helping users with their backend APIs. Hear Stephan's perspective on: Dream job requirements Back-End attraction CSS avoidance Internal framework downside Community adoption benefits Facebook's recruiting masterstroke Longing to learn Pull request driven learning Triangulating feedback Delayed feedback reflection “Listening to listen” Gratitude and much more… We are currently hiring for a lot of new positions at Stellate. If you got interested in potentially working with us, please take a look at our hiring page.

Future Founder Promise
Stephan Schneider | Clip #01 | Getting Into Coding | Love For Hardware | Overclocking CPUs | Science Experiments w/ Kids | Outdated University Classes | Leaving University | First Job

Future Founder Promise

Play Episode Listen Later Aug 30, 2022 10:04


A FFP interview with Stellate Software Engineer Stephan Schneider. Stephan is a Berlin based software engineer with a deep love for backend logic and a living example that attending meetups can help your career progression. He started working for Contentful after being on one of the meetups they hosted and stuck with them for many years, building and maintaining various APIs, including their GraphQL API from scratch. He later toured a few meetups to give back to the community by talking about the lessons learned - design decisions, developer experience and performance on scale - and ended up chatting with the Stellate team on one of those. Now he's an engineer for Stellate, doubling-down on what he loves to do: helping users with their backend APIs. Hear Stephan's perspective on: Getting into coding Love for hardware Overclocking CPUs Science experiments w/ kids Outdated university classes Leaving university First job and much more… We are currently hiring for a lot of new positions at Stellate. If you got interested in potentially working with us, please take a look at our hiring page.

Azure Friday (HD) - Channel 9
Modernize your API stack with GraphQL and Azure API Management

Azure Friday (HD) - Channel 9

Play Episode Listen Later Aug 29, 2022


Elizabeth Barnitt joins Scott Hanselman to discuss and demo GraphQL support in Azure API Management, which allows you to import, validate, secure, and augment GraphQL APIs in Azure. Azure API Management enables you to both govern your existing GraphQL servers and build one from scratch with Synthetic GraphQL, which allows you to combine your existing REST and SOAP endpoints into a single, easy to query endpoint. Chapters 00:00 - Introduction 01:23 - What is GraphQL? 11:34 - Demo - Import a GraphQL API 18:12 - Demo - Synthetic GraphQL 21:24 - Wrap-up Recommended resources Azure API Management resources Import a GraphQL API Import a GraphQL schema and set up field resolvers Protect, Augment, and Build GraphQL APIs with Azure API Management Create a Pay-as-You-Go account (Azure) Create a free account (Azure) Connect Scott Hanselman | Twitter: @SHanselman Elizabeth Barnitt | Twitter: @BarnittE Azure Friday | Twitter: @AzureFriday

Azure Friday (Audio) - Channel 9
Modernize your API stack with GraphQL and Azure API Management

Azure Friday (Audio) - Channel 9

Play Episode Listen Later Aug 29, 2022


Elizabeth Barnitt joins Scott Hanselman to discuss and demo GraphQL support in Azure API Management, which allows you to import, validate, secure, and augment GraphQL APIs in Azure. Azure API Management enables you to both govern your existing GraphQL servers and build one from scratch with Synthetic GraphQL, which allows you to combine your existing REST and SOAP endpoints into a single, easy to query endpoint. Chapters 00:00 - Introduction 01:23 - What is GraphQL? 11:34 - Demo - Import a GraphQL API 18:12 - Demo - Synthetic GraphQL 21:24 - Wrap-up Recommended resources Azure API Management resources Import a GraphQL API Import a GraphQL schema and set up field resolvers Protect, Augment, and Build GraphQL APIs with Azure API Management Create a Pay-as-You-Go account (Azure) Create a free account (Azure) Connect Scott Hanselman | Twitter: @SHanselman Elizabeth Barnitt | Twitter: @BarnittE Azure Friday | Twitter: @AzureFriday

The Swyx Mixtape
[Weekend Drop] AWS, Cloudflare, and Techbro Therapy on AWS.fm

The Swyx Mixtape

Play Episode Listen Later Aug 27, 2022 51:25


Listen to AWS.fm: https://aws.fm/episodes/episode-25-shawn-swyx-wangShawn joins Adam to discuss Amplify and its place in the developer ecosystem, whether we should care about Cloudflare, yet, and how to cope with the anxiety that can come with being extremely online. Also, it sounds like Adam is a tech bro and he's NOT happy about it.TranscriptAdam Elmore: Hey, everyone. Welcome to AWS FM, a podcast with guests from around the AWS community. I'm your host, Adam Elmore. And today, I'm joined by Shawn Swyx Wang. Hi, Shawn.Shawn Wang: Hey, Adam. How's it going?Adam Elmore: It's going well. I've been extremely excited. I've said this on a ton of podcasts, that I'm excited to get on with a guest, but this has been a long time because before I took my break, I was going to get on with you. Took a big, long break, and I've finally got you on. You're somebody, and I'm going to say a lot of things, I'm very dramatic, but you're somebody that I really admire in the online space. You have this ability to think about things, and distill them, and put them out there in a way that I admire greatly. I'm so excited to have you on here. It's going to be hard for me to stay on any one topic because I have just a list of questions I want to ask you, basically.Shawn Wang: [inaudible 00:00:52].Adam Elmore: First, could you tell everyone on this show who you are, just the short version of Shawn?Shawn Wang: Yeah. So I'm Shawn, born and raised in Singapore, went to The States for college and then spent my first career in finance where I did investment banking and hedge funds. Loved the coding part because every junior finance person starts to learn to code, and didn't like the stress of the finance part, so I pivoted to tech where I was a software engineer at Two Sigma and then I was in developer relations at Netlify, AWS, Temporal, and I've just joined Airbyte as head of developer experience.Adam Elmore: Oh, I did not know you weren't still at Temporal. So Airbyte, what is Airbyte?Shawn Wang: Airbyte is a data integration company, it basically has the largest community of open-source connectors for connecting to any SaaS API source into your data warehouse. So for anyone doing data engineering, the first task that you have to do is to get data from all the different silos of data in your business. Let's say you have a Salesforce being the source of truth for customers, Stripe being the source of truth for transactions, get all of them into a single data warehouse for you to do operations on. So the goal is to have the largest community of open-source developers for connecting all the data and liberating your data from all the silos that you have in your business.Adam Elmore: And how long ago did you start? How did I miss this?Shawn Wang: A couple weeks ago. I actually have not announced it on Twitter, which is why.Adam Elmore: Oh, there you go.Shawn Wang: I like to slow play it. So when I joined Temporal, I actually waited for six months to really understand Temporal and to practice my pitch before announcing it on Twitter. And that's how I like to do things because, well, partially I want to be fully up to speed before I represent something publicly.Adam Elmore: Yeah. So I want to talk about that. You get very up to speed in a way that I don't see a lot of people on Twitter. I don't see them understand things in the way that you do. So you obviously write, your blog is a huge source of information for me, and I've enjoyed it quite a lot, but it's not just that you write, it's the way you think about things. Does that come from your finance, your analytical background in finance, or were you like that before, your ability to see the whole forest, take in the way things are trending and the way things are moving, put it all together and distill it into these wonderful articles? Where does that come from?Shawn Wang: Oh, so first of all, thanks for the very kind words. I don't hear back from my readers that often, so it's really nice when I get to talk to someone like this. So yeah, I would say a lot of this stuff is actually from my finance days. This is the kind of analysis that you would have to do when you do an investment report or investment research on any stock or any industry. You want to get a perspective of what's going on, what the trends are, who the major players are, and form an opinion on where things are going. And I think taking that finance mindset into the bets I have, in terms of technologies, whether or not it's for using them personally in my personal stack or for joining them as a startup employee, I think is extremely underrated. And it's something I'm trying to model and hopefully teach people someday.Shawn Wang: Although I'm not sure about the teaching part, because if I say like, "Get rich by doing investment analysis stock on early stage startups," I would feel like a hustler. So maybe not that, but I just do like engaging in that. And probably it's an exercise for me to think things through clearly by writing it down. And I also get a lot of feedback from that, so I actually improve and learn a lot by learning in public. And that's the other thing that I am pretty well known for, so this is the application of the general purpose learning in public principle.Adam Elmore: Yeah. No, and I love your learning in public article. I hope more people see how you break down systems and the world around us and distill it. I hope more people do that because I'd love to have more sources of that kind of information. It's really fascinating and that's a lot of what I want to talk about today is your opinions on the future and where certain things are headed. First, I want to talk, you did work at AWS. How long were you at AWS?Shawn Wang: A year. AWS Amplify.Adam Elmore: Yeah. So I'd love to know, I guess what it was like working at AWS, what you took from that, but also more broadly, I want to get into Amplify and where it fits. You sort of live in that intersection. I feel like web, and cloud, and infrastructure, where things are trending, and I want to talk Amplify's place in that, but first, what was your role there like at AWS, at Amplify?Shawn Wang: Yeah, I was a senior dev advocate at Amplify, basically doing demos and talks for Amplify. And the fun thing about working at Amplify is that you are essentially also a developer advocate for all the underlying services. So amplify is essentially a roll up of DynamoDB, API Gateway, AWS AppSync, even file storage like S3. You could do some demos with that. And I did, I made like a DIY Dropbox clone. But it's focus on front-end engineers. And I think that was the first time that AWS had ever made a dedicated arm or products for front-end engineers. And it turned out to be a really good bet because AWS Amplify was one of the fastest growing AWS services, at least during the time that I was there. So I thought it was just really compelling to try it out and obviously everyone has very high regard for AWS. There's a bunch of services that I only experienced on the inside and I only learned about once I got on the inside, and I thought that was really interesting as well.Shawn Wang: A few things I'll point out. I really loved the AWS interview process, actually. I felt like it was very rigorous and I definitely haven't had as rigorous a process anywhere else. And they really got a good look at every single part of me before they made the decision. And fortunately for me, it was a unanimous, good decision, but I felt challenged. I felt like there was a lot of growth that I took away from that process as well. So I highly recommend going through it, even if you don't necessarily take the job.Shawn Wang: And once you're in, I think the other practice I really like was the weekly business reviews. Not everyone gets to be a part of, but I was, and essentially you have a P&L from the central AWS finance team that week to week tells you how well you're doing or not. And the PMs in particular, they'll put up highlights, they bring up topics of discussion, and the general manager would be grilling people on. And I thought that was just a fun way to run a business. It was a little bit stressful, sometimes a little bit dramatic, but hey, it forced you to take on the issues head on instead of ignoring them for three months to a year, which I've also seen happen.Shawn Wang: So I just really appreciated that directness, and everything that you've heard about on the outside about AWS culture applies, like they'll send out the memo and the first 10 minutes of the meeting will be spend in complete silence where you just read the memo.Adam Elmore: Just read the memo. Yeah, that's real. Well, what about the leadership principle? You talked about interviewing there. Did you feel like you started to embody those? Did those really become something you valued or was it sort of like, you're just doing it because that's what Amazon cares about?Shawn Wang: There are a few things here. So I think one, people are drawn to Amazon because of leadership principles, like literally is what the interview is for. So you can't really join without already having them ingrained in you. And then second, yes, it gets brought up a lot when decisions are being made or just behaviors being modeled or discussed, especially in the performance review stuff. So I think that is useful, that is helpful, but at the same time I have problems with some of the LPs myself. "Be right a lot." What the hell is that?Adam Elmore: So what is right?Shawn Wang: Yes, exactly. What is right, what is a lot? So I think that, for example, what is underdiscussed or just not on the table, just because it comes from so much up high and has so much baggage and history with it, is that sometimes you have to try to be wrong, to take more risks. And being right a lot means that you might be more conservative than you otherwise should be. It leads to very incrementalist thinking, which is like, "All right, what is the most obvious next step? What is the low-hanging fruit? What is the short thing?" You just pick that over something that is more risky, but potentially has higher impact.Adam Elmore: Yeah. No, that makes sense. I want to, I want to shift gears a little bit and talk about Amplify. Now that you're outside of AWS, you mentioned it was sort of the first example of AWS trying to go to the front-end developer and bundle up more of a developer experience. How do you feel? And you may have information from being there about traction and things like that. How do you feel about Amplify's return on investment and is Amazon doing a good job, I guess, with Amplify in terms of trying to package up their own experience? Do you see that resonating with developers?Shawn Wang: So I think Amazon is doing a good enough job at addressing the needs of AWS customers. And that's something that is Prime first and foremost, like excels at that. Amplify could be doing a lot better at competing with the other standalone front-end developer focused startups that are out there that don't have the AWS infrastructure, which should help, but actually sometimes hurts it a little bit. So my favorite example of this is, so there's another company Begin, begin.com with Brian LeRoux. It's a four-persons company, and they also do very similar things. They deploy on top of Amazon, they are entirely serverless, they have a smaller set of offerings that they have, but their deploy speeds are in order of magnitude, faster than Amplify. They can deploy faster to AWS than Amplify can.Shawn Wang: And that's because Amplify doesn't do some of the trickery that they do, like having a cold pool ready or anything like that. When people are not married to the AWS stack, just because that's the solution, that's the technology provider or cloud that their company has picked. When you have free choice, then you come with no baggage and just being from AWS doesn't give you any home ground advantage anymore. Therefore, you have to really, really, really compete on developer experience. And that's something that Amplify still needed to work on at the time that I left.Adam Elmore: Yeah. I'm glad you brought up Begin too. I'm curious how it fits into the landscape. I've seen you mention Begin within some of your articles, like the cloud distros article I think about, I want to talk about that, but how is Begin doing? I interact with Brian on Twitter, I generally like him a lot, I like what they're building, but it is sort of a thing you have to buy into. It's like a whole different way of building applications. Do you have any sense for how they fit as a player in all of this?Shawn Wang: They're tiny. I mean, they're not a rocket ship by any means, but they absolutely solve the problem for the serverless full stack minimalist aesthetic that they're going for.Adam Elmore: Those are all things I like, so.Shawn Wang: Right down to the API calls, having an inbuilt authentication solution that when you write the serverless function, you just have the user ID and it's all done for you with cookies in the background. That's just beautiful, that's [inaudible 00:12:58] mess with cognito or anything like that. Because it's very straightforward, that is the way that I would want to build serverless applications. If I didn't have some kind of big enterprise thing requirement, which maybe it's a premature optimization to try to glom that on in the first place, which is what you're required to do with AWS Amplify.Shawn Wang: So I don't think I have enough experience to really judge, are they the right technical choice in all aspects? But I think there's just a certain aesthetic that you try to optimize for. And if you have full stack needs, if you like serverless, if you like one of everything, essentially one story solution, one queuing solution, one database solution, then Begin is the right curation for you. And then Amplify is sort of the more fully loaded solution if you want an easy way to access, let's say API Gateway, even like the... Actually just before I left, they actually launched support for serverless containers with a AWS Fargate, which is also super interesting.Adam Elmore: Oh, I didn't even know Amplify supported that.Shawn Wang: Yeah, exactly. They're just different trade offs in the spectrum, like Begin is way more opinionated than Amplify. Amplify is way more opinionated than the full set of AWS services that are possibly out there. I think they serve front-end developers well in all different respects. Yeah. I think Amplify is definitely hitting its goals and probably exceeding its goals for adoption internally. Begin could do a better job at marketing and something that I should probably try to help them on just because I'm a friend of the company and so, I mean, I just really like the philosophy, but at the same time, there are other competitors out there, like CloudFlare Workers is essentially trying to become a Jamstack or a backend-as-a-service platform, because they have Workers KV and Durable Objects. And that's a very compelling solution for a particular type of audience.Shawn Wang: And it's weird because you have to be much more specific now. Like that's the thing, you have to figure out which part of the population you are in, in order to figure out which provider is best for you. There's no such thing as one provider fits all. It's really about like, "Okay, do you like the minimalist approach? Go with Begin. Do you like the edge-first approach? Maybe go with CloudFlare. Do you like the little bit more full stack, scalable, cloudy service? Maybe go with Amplify." There's a lot there. Like, "Do you like to self-host containers? Maybe go with Fly.io or Render.com. There's just a lot of options out there, but all of them happened to be built on top of AWS, which is why we had the cloud distros thesis.Adam Elmore: Yeah. And I've consumed a lot of your content on that front, like hosted back ends. I do wonder where it's all headed. Maybe the answer is that there's just going to be a lot of options, and because there's a lot of different use cases, I guess maybe narrowing it down. Like if I really don't care about enterprise stuff or big teams, if I just care about building stuff with small teams, startups, that's where I live. Do you have any predictions, I guess, for where ideal product building is headed? Is it hosted back ends to go with your hosted front ends on Vercel or whatever else? Is it learning AWS primitives and just good and good at building stuff? How do you see that forecasting into the future?Shawn Wang: What's the alternative to hosted back ends?Adam Elmore: I guess what I do right now is build... Like I kind of use all the Amplify services, I just don't use Amplify. So I build a lot of bespoke APIs with AppSync, and Dynamo, and whatever.Shawn Wang: So because you have that knowledge, that's the best thing for you, because you already have that knowledge. Like it's not a big deal for you to spin up another service, but for others it would be, because they would be new to that and sometimes a more friendly layer that abstracts it away for them would be helpful. So it's really hard to say which is going to win just because they're all going to win in some way, but some will be more winning than others. That's kind of how I view it.Adam Elmore: Yeah. Yeah.Shawn Wang: Because at the end of the day, like cloud is such a big deal, it's such a multi decade thing. It's going to take the rest of our lives to play out. That means that the vast majority of users of cloud haven't adopted it yet, still. This late into the game, they still haven't adopted it yet.Adam Elmore: It's so hard for me to wrap my brain around. It seems like it's been so long. And when you say the rest of our lives, I don't put it in that kind of perspective. I need to calm down trying to figure out what's going to happen in the next three years. Like it doesn't matter.Shawn Wang: Yeah. Yeah. Lambda is like seven years old. This is so early. The way that this looks 40, 50 years from now is going to be so different. AWS has like a million-something customers, imagine it having 10 million. When you have order of magnitude, when we start to think in terms of orders of magnitude, you start to really sweat the small details a lot less because you're like, "Whatever. Everyone's going to win."Adam Elmore: We all win. Yeah, I guess it's true. I don't know if you've talked about this, I'm sure you've thought about it, and maybe you have written about this, but it's the idea of scarcity versus abundance mentality, I guess. It's weird because all at the same time, I agree with the sentiment that if you're on Twitter or you're very online or whatever, you should have this mentality that we can all lift each other up and we can all succeed. But then on the other hand, you've got the climate and how much can the earth sustain in terms of everything can only grow so much. I just had that thought, that sort of raw stream of consciousness. So I don't know if you've got any refined response to that. Is that sort of totally different concepts that I shouldn't conflate?Shawn Wang: What, the limits to growth thesis?Adam Elmore: Oh, yeah. I guess that's what it's called. See, I knew you'd have a name for it or something. Like the idea that we can all succeed, but at the same time, we all need to do a lot less because the planet can't succeed if we all...Shawn Wang: I mean, this is about the offline-online shift. So we can still do a lot less and cloud can still grow because the mix of what we do in-cloud versus off-cloud is still very much imbalanced. So when you do things like pay attention to an Andy Jassy Keynote, and he'll talk about like, "Oh, cloud penetration is whatever, 20%, 30%." That is how low it is and it still takes a long time for people to adopt for whatever reason, institutional or just generational, or maybe our technology's not there yet. There's still a lot that needs to be developed to serve all kinds of markets that it hasn't penetrated. My favorite stat was that online shopping went from 10% to 20% in COVID.Adam Elmore: I can't believe it's only 20%. That's actually...Shawn Wang: Exactly, right?Adam Elmore: That's bonkers.Shawn Wang: So there's some version of the future where that is 70%, which means that you still have a long, long, long, long, long way to grow for every part of e-commerce and the planet can still win by maybe more efficient sorting or less retail outlets. I don't know. I don't know about that. I think I'm much more shakier ground there, but yeah, often the online transition, I think it is a very positive thing for the planet, especially because a lot of the major clouds are committing to net zero carbon footprints. I'm not sure if AWS has actually done that yet, but definitely Microsoft and Google have done it, which means AWS will eventually do it.Adam Elmore: And I know AWS, they've launched sustainability insights and stuff recently, where you can start to see the emissions impact of the services you're spinning up. I know Google's done that for some time, but AWS is now doing that, I think.Shawn Wang: Right. But we're actually measuring it now versus not measuring it before, so whatever. This is peanuts compared to like, "All right, are we moving to electric vehicles or something?" That is way more of an interesting concern than this stuff. Like invent a better battery and that will drastically accelerate the move to solar, and that will be much more meaningful than choosing paper straws. Sweating over the carbon footprint of your EC2 instance is the developer equivalent of choosing a paper straw. Really, look, I appreciate the effort, the spirit's, the heart's in the right place, but really if you want to make an impact, go work in the big things.Adam Elmore: I'm glad you said that because this is not on my notes, this is not something I planned to talk about, but this is the thing that I feel like to make an impact, I've really struggled, I'm 15 years into my career, I've been like a software engineer mostly early in my career, then I did a startup, and then I've mostly just been doing consulting. I feel like there are more possible things I could do with my time than ever. And it's so hard for me to decide what is worth spending time on.Adam Elmore: And I guess, do you have any thoughts on senior engineers, when you get to a point in your career where you have more flexibility and more opportunities, what is the most impactful thing? I've thought about making courses, I've thought about building products and just continuing with consulting. Is there a way to split your time that you're ever going to feel good about?Shawn Wang: Probably not.Adam Elmore: Okay. It's good to know. I can stop trying to find it.Shawn Wang: Yeah. The menu options is so high. I think just figure out what gives you energy and then try to spend more of your time and day on that than stuff that takes away energy from you, so it was just a very hippie thing for me to say.Adam Elmore: Yeah. No, that seems much simpler than I'm making it.Shawn Wang: There's a concept here that I do like to share about leverage. There's an inherent tension between productivity and leverage. I think we are trained from basically our days in school, that high productivity is the goal, which is you want to have a packed calendar, you want to be doing eight different things at once. You should feel bad if your efficiency went down 10% compared to last week or whatever, and you're not meeting your OKRs or whatever. And the exact opposite to that is leverage where you want to have one thing, you want to do one thing and just have a lot of impacts come out of that.Shawn Wang: And I think there's a movement, at least in VC circles, but also in sort of tech bro circles of waking up to the idea of slack in your life, and having peace and not having so much going on, and just doing high leverage activities that help you extend your reach without you necessarily putting more hours in or being super productive. Like being unproductive is fantastic. It's actually people who cannot figure out leverage who have to try to be productive. If you can figure out leverage, then productivity doesn't matter at all.Adam Elmore: Yeah. No, that's good stuff. I think I intuitively knew that. I just have a really hard time. I feel like I'm much more seeing the tree versus the forest, so I really appreciate talking with people like you that see the broader picture. I think I have a lot of thoughts and then I read an article of yours and it helps me put words to those thoughts that I couldn't really formalize in my head.Shawn Wang: I should really write about this more, but I feel like I haven't got it yet. You see me out there, you see me doing all sorts of random crap. So I haven't internalized it fully. I haven't let go of the sort of productivity mantra. Part of that is me being very risk-averse, part of that is me being doubting myself. Definitely, the stuff that you see from me has extremely high leverage. I think, okay... The other thing is I also have second thoughts or doubts about this whole leverage thing, that's why I have a very divisive tone about VCs and tech bros, because everyone wants to be high leverage, everyone wants to do the 80-20. Nobody wants to ship stuff, they just want to tweet thoughts, and then they think they're done. Right?Adam Elmore: Yeah.Shawn Wang: That's what they think high leverage is. But really the people who get shit done, swipe to find details and take things to the finish line. And guess what? Doing that last 10% is super low leverage. Like, "Oh man, I got to fix this stupid SEO description or the OG image isn't right, let me go fix that." That kind of small little details matter for the quality of the products and for shipping things, but all the high-leverage people feel like they're above that because it's not a good use of time.Adam Elmore: So are they the high-leverage people or you're saying the people that want to be high leverage, is that the VCs and the tech bros?Shawn Wang: Yeah, exactly.Adam Elmore: What is tech bro? I feel like I probably am a tech bro, and I don't want to be a tech bro, but I feel like I'm a white male that has a podcast, so I can't escape it.Shawn Wang: Yeah. Yeah. I'm a tech bro guy. I'm sort of reluctantly in that demographic. Yeah, the tech bro is a bro that's in tech.Adam Elmore: Okay. Yeah. Well.Shawn Wang: That is fully aware. Okay. I do like to have this mis-metric. If you're fully up to speed on the latest news, the gossip, you know all the new launches and new products, you're definitely a tech bro.Adam Elmore: Okay. Okay.Shawn Wang: If nothing surprises you, you're a tech bro. If you know what AUM is, if you know what ARR is, if you know all these acronyms without even blinking, you're a tech bro. Well, the real people who get shit done out there are wonderfully blissfully ignorant. They'll be like, "What is this whole Twitter kerfuffle, what's going on? I don't know. I just completely stayed out of the loop." But you being a tech bro, you would know the blow by blow of like Elon did this, twitter did that, Elon did other thing, twitter did other thing. It doesn't matter, the stuff doesn't matter to some extent and tech bros are so involved in their own filter bubble that they don't see their own forest for the trees, so.Adam Elmore: You said Twitter. I think I've been on Twitter actively for a year or so and I don't know that I'm better for it. I don't know that like... I know that I'm very influenced by that sphere and sort of feeling like, I think that's why it's so surprising to me when I hear about cloud adoption or I hear about online shopping. It just seems like everyone lives in this little community and it's very easy to just not really remember the people that are actually around me in my local community and what life is actually like. Is there a way to balance it? Is there a way to balance being very online, being a member of this Twitter community and still keep a good grasp on the real world?Shawn Wang: I don't think I personally have figured that out a lot, but I think it's basically the developer equivalent of go touch grass, which is go outside.Adam Elmore: Yeah, yeah, yeah.Shawn Wang: Have hobbies, have kids.Adam Elmore: That I was going to say, I've got two boys and they make me be outside a whole lot, so that probably helps, I guess, somewhat.Shawn Wang: Yeah, yeah, yeah.Adam Elmore: I think the biggest thing for me just career and in terms of the always online, the tech broness, I think giving my wife the opportunity to set some boundaries around the time that I am working, I think this stage of my career, I've been able to say I'm going to work less and just seeing her role and what her life looks like and realizing how it shouldn't be this different. Like we shouldn't have such a, I don't know, huge chasm in terms of our daily life. Like I get to go enjoy what I do all day. Yeah, that's helped. We've carved out a lot of time that's like, "This is time for family." I think yeah, but my online, my work life feels very homogenous, I guess. And it could be better.Shawn Wang: For me, it's like, "All right, figure out what is probably going to make your money and focus all your attention on that. Ignore everything else. Try to stick to, okay, what can you reasonably explain to your non-technical relatives? If you can't really justify it to them, then maybe have a second thought about like, 'All right, what am I really doing here?' Am I really making the world a better place by inventing a better form of infrastructure as code? Probably not." Unless you become a billionaire by creating HashiCorp, right?Adam Elmore: Yeah, I guess it happens in that very rare instance. Yeah.Shawn Wang: Right. But it can happen. You just have to be super clear on what you're trying to do here. And just like, yeah, be super intellectually honest about like, "Look, you're you're in this for the money, whatever you work on is probably going to be irrelevant in 10 years anyway. It doesn't matter, but you're at least going to have fun, you're going to build some relationships, you're going to make some people happy, create some jobs, whatever, and then spend the rest of your time with family and friends."Adam Elmore: That was a very succinct way of wrapping up a lot of the things I needed answered. So I don't know if anyone that listens to this podcast cares about any of this. I really appreciate the conversation we just had.Shawn Wang: No, no. I think yeah, this is very real and I really appreciate you bringing it up, because I don't get a lot of chance to talk about this.Adam Elmore: Yeah. No, I live in the Ozarks, so tech literacy here is super low. I think that's where getting into the Twitter community, it was like, "I have friends now that I can talk to about technology and things I care about." But yeah, finding that balance. I think it's really very practical of you, very wise of you to point out that ultimately this stuff doesn't necessarily matter in a decade, that whatever I think I'm working on that's so important is probably more about the people, more about what I'm kind of enjoying the process along the way and that it's making a living and that we're moving a little bit forward whatever parts we touch and what other people we can be involved with. That was very nice for me to hear.Shawn Wang: I will point out one thing. So humanity is kind of moving onto this metaverse. If there's anything that's actually real about the metaverse is that you have your community online that is dissociated from your physical community. You're so into AWS, or cloud, or anything like that, and no one else around you physically is, and it's fine. And this is something that actually the crypto bros, they probably got right. So I think Balaji Srinivasan, who is one of the crypto investors at Andreessen Horowitz, he released this book recently about building a digital nation, which is really compelling, which is like, essentially there's the world of physical nations, like the ones that country that've boundaries, but then there's the digital nations, which are formed online, and you're a member of the digital nation of probably tech Twitter, whatever.Adam Elmore: Yeah, yeah.Shawn Wang: Or AWS Twitter. And I kind of liken it to the difference between friends being the family that you choose versus the family that you have is the one that you're born with.Adam Elmore: Yeah, yeah, yeah, yeah.Shawn Wang: So where you're physically located is just the nation that you're born with or the nation that you have to live in for your family reasons, but the one that you do online, that's the nation that you choose, so you're member of a different nation online. And that nation is global, it's ephemeral, it's virtual, whatever that is. But it's something that you prefer to spend your time in as compared to your physical nation.Adam Elmore: Yeah. So I feel like since getting really active in Twitter and being involved with the AWS community, even outside of Twitter, it is so global. It's helped me see the perspective of America, where I live, so differently. Just getting all those other points of view and just knowing that when I interact with someone, it's not this base assumption that they understand the world through the lens of America like I do. I very much appreciate that. I feel like I'm, if anything, becoming more and more dissociated with the country I physically live in, because I just don't interact much with people outside of these walls. I don't know if it was COVID and being in all the time. I always have been kind of an at-home person.Shawn Wang: So that is dangerous. Right? That is dangerous.Adam Elmore: Yeah. It feels dangerous. Yeah, tell me why.Shawn Wang: Well, because if you don't care about the physical environment that you're in, then it's going to degrade, it's going to diverge away from your preference.Adam Elmore: Yeah.Shawn Wang: I don't know if that's inherently bad to me. Like there's definitely a physical element to humanity that we should keep around. We are not just brains plugged into the matrix. Essentially this leads to the matrix, that we might also just be plugged into something virtual online and spend zero time on a physical environment. Most people would not like to live that way, and that means we should care about what's going on around us. And we should try to have some physical presence that we're actually proud of and enjoy. And I think that there's a tension there that I think is sort of the modern humanistic existentialism, which is like, "How much of my life should I spend online versus how much should I spend in person?" And the fact that you have to choose is just nuts.Adam Elmore: Yeah. And I think my problem, like if I'm just being honest with myself and just thinking through this, I spend about as much time, I think, in the real world, but it's just with my family, at home, it's with my neighbor, I got a neighbor that I go for walks every week with. It's like my very, very hyper local community. But what's going on in the City of Nixa? It's like 10,000 people where I live. What's the local government doing? I don't know. I have no idea. What's the State of Missouri doing? Probably stuff I don't like.Shawn Wang: Exactly. And look, this has a very real impact on us because these people are making the laws that we have to follow. And we don't have a voice because we choose not to have a voice because we choose to not care. But hey, is it really our fault when the Supreme Court or the Congress makes a law that we don't like? Well, yeah. I mean, what did you expect? You didn't spend any time investing in that part of the world. It's like, "When are we going to have a software engineer in Congress?" That's really the big question.Adam Elmore: Yeah. There's not a lot of tech representation, is there? In government in the United States.Shawn Wang: No, because everyone hates politics, they love to dunk on it, they don't want to do a thing about it, but that's kind of the problem. I don't care which side of the bench you're on, like just the politicalness because you feel like you're not a member of the physical nation, you're a member of the digital nation. That is a problem for the physical nation, because at the end of the day, that's basically a reality.Adam Elmore: Yeah. Oh, I think of that, there was that Netflix documentary. I don't even know if it was just on Netflix, but there was that social. Well, I don't even remember what it was called, it was about social media and had all these people from Facebook and other places, or ex-Facebook, talking about just this impact that the very online nature of our generation, what it's doing to our brains and all that. This all sort of ties in my mind. Like I definitely need to do some more things that are yeah, going to impact my life, my kids' lives, sort of being more involved, I guess, outside of... Like I divide my time into I'm at work and I'm on a computer all day or I'm with my family and we're out in the yard playing. It's those two things. And I make no time for anything else, but that's probably not good. Not a good, long-term solution.Adam Elmore: Okay. Now I'm getting way off the rails. AWS FM, people literally listen to this for some good AWS bits. They've turned out long ago. I do have a couple more questions here, getting back to like I'm a developer, I like building full-stack web applications and I happen to like leveraging AWS. I'm going to ask you a few things. When should I care about CloudFlare? They announce all this cool stuff and it really is genuinely cool sounding, but there's so much of a barrier to adoption, like for me to change my day to day and start using a new thing. When should I care about CloudFlare?Shawn Wang: I have the article on this, about how CloudFlare is playing Go while AWS plays chess, so I highly recommend reading that up. Essentially, CloudFlare is a really good CDN. AWS has its own. I would think you can do up comparisons of CloudFront and CloudFlare all day long, but I would say that CloudFlare probably has much more of a security focus than CloudFront has, and that by default wins you the majority of the business and it happens to be very easily adoptable because you just need to configure some DNS, just is carrying a lot of weight there and it comes to DNS.Adam Elmore: If you're asking someone in the Ozarks around me, then what's DNS, first of all?Shawn Wang: So I think it basically starts from the outside in. You want to think about CloudFlare, you think about where your user's traffic is coming in. Maybe you want to protect those with CloudFlare and then you want to come in a little bit. CloudFlare has this S3 wrapper called R2, that basically reduces a lot of your outgoing bandwidth costs. And that seems like basically a Pareto optimal win. Pareto being you're no worse off in any dimension and you're better off in one dimension, which is cost. And that's just a function of CloudFlare.Shawn Wang: Like how many points of presence does AWS have? I think in the hundreds, maybe 100, 150, something like that. CloudFlare has tens of thousands, right?Adam Elmore: Oh, okay.Shawn Wang: It's just a much better edge network than AWS has. And so they just have a fundamentally different business model. And I think once you understand that from a fundamental physics and points of presence perspective, then you're understanding, "Okay, this is what I'm getting that AWS doesn't do." It's not a straight up one-to-one competitor, it's trying to tackle the cloud problem from a different way.Shawn Wang: So you do the cloud traffic protection, then you do the sort of egress charges, which are sort of the main sticking point of AWS. Then you get into the extra stuff that CloudFlare offers for application builders. And I focus on this because I'm an application builder. CloudFlare's other offerings for security that I have no idea, security and networking that I have no idea about, particularly if you need to wire a building or an office, they have a box that's pretty sweet for everything I heard. CloudFlare One is the name of it if you want to Google it.Adam Elmore: Okay. Yeah, I do.Shawn Wang: But for application developers, CloudFlare Workers, that team is the sort of primary team that's working on that. And that is, there's edge function service that would be a big leap to adopt because they don't run Node.js, they run V8 isolates, which are taken out of the Chrome V8 engine.Adam Elmore: Is it similar to like Lambda@Edge? Like the same kind of...?Shawn Wang: No, it is not.Adam Elmore: Oh, is Lambda@Edge node?Shawn Wang: Yes.Adam Elmore: Oh, it is.Shawn Wang: Yes.Adam Elmore: It is. Now, what is it similar to? It's similar to, I guess like Middleware and Next.js, that's that same kind of a limited runtime environment?Shawn Wang: I think so. Yeah, exactly, exactly. I would say it's more limited in Lambda@Edge and it's got different costs and criteria. Basically, there's just more of the open source ecosystem that it will be incompatible with CloudFlare Workers than it would be with Lambda@Edge. And that's the thing that you need to know because you're going to use...Adam Elmore: CloudFront Functions.Shawn Wang: Ah, okay. Yeah, that's the one I keep forgetting.Adam Elmore: I don't know who's using it, but that's what I was thinking of.Shawn Wang: Right. So I used to use this only for smart redirects, like looking at the headers of a request and saying, "If you're coming in with a header indicating you're from a certain region, certain IPS, certain language, then I'm going to route you to a different location than I would normally." Only for route, but now Edge Functions are becoming so capable that you might be able to do rendering on demands instead of just routing. And that actually is unlocking a few new things because on top of that, CloudFlare also has persistence solutions with Workers KV, which is their eventually consistent store, and Workers, and Durable Objects, which is their strongly consistent store. So either one of those combined with the ability to render, means that you can actually just host a site full stack with Front on the Edge. There's no origin server, there's no region, you just have everything everywhere all at once, which is a favorite phrase that I try to sneak in.Adam Elmore: Yeah. That's super compelling.Shawn Wang: So yeah, your latencies go down from like 300 milliseconds to nine, just because you're just pinging near a cell tower or something.Adam Elmore: Yeah, that's incredible. And they've just announced, I don't remember D1 or whatever. I don't know, I can't keep track of their product names, but they have like a distributed SQL offering as well that's coming or...Shawn Wang: SQLite. Yeah.Adam Elmore: Yeah. SQLite at the edge.Shawn Wang: I mean, everything's just built on top, it's just clearly built on top of the original persistence primitive that they have. And so once they got strongly consistent and eventually consistent, those are the two dimensions that you really care about. You can build any sort of solution on that, so the SQLite offering is just built on top of that.Adam Elmore: Yeah. Okay. So I don't know if I'm going to like jump on this stuff yet, but it does sound like there is a world where I could build side projects just on CloudFlare, like stuff runs all at the edge and I don't have to build up, I guess, is the interop, like if I want to still stand up a GraphQL API in AWS, like AppSync or something, is there interoping between the two services? You said their durable storage sits on top of S3, so it's actually, you're using an S3 bucket, you're just wrapping it with a CloudFlare thing?Shawn Wang: It's a proxy.Adam Elmore: Okay. Are people building hybrid CloudFlare, oh, I know they are, hybrid CloudFlare and AWS back ends today? I think I know of a couple at least. Is that a thing you recommend?Shawn Wang: I would say yeah, there are. I'd say this is definitely on the cutting edge. You do it because you feel like [inaudible 00:42:35].Adam Elmore: It's like Twitter, where you do it and you talk about it on Twitter and then everyone thinks...Shawn Wang: It's theoretically possible, it's just like probably not in any size.Adam Elmore: Doesn't make sense yet. Okay. So I'm going to say, I don't need to care about CloudFlare yet, that's what I'm going to say based on this conversation. I mean, I'm going to keep reading the articles, but.Shawn Wang: The only thing I'll point out is don't stop there because this is what they've achieved in the past three, four years, they clearly have a roadmap, they clearly are going to keep going, and just eating the cloud from outside in, which is the name of the article. What else of the functionality can be replicated in an-edge-first way? CloudFlare is probably going to do that. And so there's a whole roadmap that just consists of looking at the AWS console and just going, "That first, that first, that first comes [inaudible 00:43:17]."Adam Elmore: Yep. Yep. Yep.Shawn Wang: And then there's a question of just what kind of application are you building and do you really need the full set of AWS services, or can you just start from the edge first? That's how disruption happens. Disruption happens by taking a section on the market that nobody cared about and making that your entire thing, and then making it so capable over time that people see no use to use the old thing, but it takes a course of what, 10, 20 years to do that because AWS has just spent the past 20 years doing that in the first place.Adam Elmore: I just don't keep those time frames in mind. Like Twitter has warped my sense of when things are coming. And when you say 10, 20 years, it's like, I don't think about anything that's coming 10, 20 years from now. I think I'm thinking what's coming in the next 18 months.Shawn Wang: Right. But that's a problem for us, because that short-term mentality stops us from betting on big trends early. And I think to build anything of significance, you have to do it for 10 years.Adam Elmore: Yeah. I got to get off Twitter, that's what I'm coming to here.Shawn Wang: I think so. I think I'm going to do it in healthy amounts. So I actually, one of my longstanding wishlist projects is to actually build a Twitter client that has a time limit.Adam Elmore: Oh, nice. Yes.Shawn Wang: [inaudible 00:44:25] Client with a time limit. If you're going to have more time, you're going to have to pay to donate to your favorite charity or something.Adam Elmore: Oh, I love it.Shawn Wang: And that's in my wishlist.Adam Elmore: Yeah. I will use it. You've got your first user if you build it.Shawn Wang: I'll just say the only reason I don't do it is because nobody trusts the Twitter API.Adam Elmore: So one more, should I care about it yet or not? Because I see Brian LeRoux talk about this quite a bit. Deno. Should I care about Deno yet?Shawn Wang: I think so. I think it's there. I think it's there. So what is Deno? Dino is sort of the new runtime that the original creator of Node.js is saying, "All right, I'm going to do this over. Node.js has been around for 10 years. I see all the flaws of it, now I'm going to start over from scratch." I was very skeptical of Deno when it first came out, but it's been two years and it's really shown a lot of progress. And I think the governance is right, the funding model was right, and the adoption is growing. What is really compelling to me about Deno, just not from a technical perspective, from a business perspective, which feeds into a technical, the business side. There are companies so Superbase and Netlify, both launched edge functions powered by Deno, which means that their biggest products shipping capability announcement of the year of 2022 was someone else's product. It was a startup that's way younger than them, but they just have the right abstraction and the right cloud service that is already functional that they're launching. So it's weird.Shawn Wang: Deno's go-to-market strategy is just waiting for other people to wake up and go, "I need this. Deno's the only supplier in the market for this. And yeah, let's just bring it on and ship it as our thing." Where it really is Deno's thing, but they're just letting other people white label them. It's that's fantastic. So I mean, from that perspective alone in the past six months, I've really changed to, from like, "Okay, Node and Deno will coexist for the foreseeable future because there's such a huge install base of Node into every incremental app will probably be built in Deno."Adam Elmore: Well, that's... Yeah. No, that's what I needed to hear. I think I there's a lot of excitement. I see it all, but it's all Twitter, so I needed to hear it face to face that it's worth digging into.Adam Elmore: One last question. We do have a couple more minutes here. Do you have thoughts on the whole macro venture capital situation and how that might impact the next 5, 10 years? And I don't know if we're entering into some tightening cycle that we've never seen anything like the last 10 years, 13, whatever years, of government injecting so much capital into the system. And if that starts going away, do you have opinions or thoughts on all these startups that are making our lives better? Like I think of DevX startups where I don't know how financially sound they are yet, they've been living off the VC. Do you have thoughts on all that?Shawn Wang: Not fully formed ones, but I can give you a quick hit.Adam Elmore: Yeah. Yeah.Shawn Wang: So how bad did it get? It got to the point, so the average price of sales ratio of a publicly traded company would be in the range of 10 to 50. That's a very wide range, meaning your market capitalization, the total value of a company is 50 times your sales. In private markets, the price of sales ratios of funding rounds, series A and B, and all that, got up to 1,000 times.Adam Elmore: Oh my God.Shawn Wang: We had 1,500 at one of the startups that I was at and I heard of one startup that was 2,500.Adam Elmore: Wow.Shawn Wang: So that was the peak in November of last year. Those days are gone, people are now asking for 100X, which is very like 10X fall, like very, very big. That's why almost nobody's raising money. So that VC market is right up, I'll say it has different impact on different stages. And this is all to do with like, "Okay, would you invest in Stripe at 95 billion when Shopify used to be 100 billion and now it's worth 20 billion?" You probably want to buy the more quality asset that's already publicly listed than the very stable asset that is at a high valuation.Shawn Wang: So this is the deal making has just gone off. Like I think at the seed stage, people are completely unaffected. I think people are cognizant of the fact that economic cycles repeat or like, this is not going to... This is a recession. We are probably already in a recession right now, we are in a tightening cycle right now, but this is probably not one of those that's just going to drag out super long. And startup take 10 years to build anyway, so why should your early stage investing be affected at all by what the current level of the S&P is? It shouldn't.Adam Elmore: Yeah. No, it's true. I mean, so much of this conversation just echoes your bias towards long term versus short term, and I should have known that coming in. I'm asking all these questions that are very much like, there's a clear answer if you just think outside of the next year.Shawn Wang: Oh, I love training people to do that.Adam Elmore: Yeah. No, it's really nice.Shawn Wang: Take a long-term perspective in the history and then project it out to the future as well, and try to make decisions on that, so.Adam Elmore: Yeah, it's sort of refreshing, especially in this sort of anxiety-ridden digital space. I feel like when you zoom out things feel a lot less pressing or anxiety-laden, I guess. I don't know. Yeah, I appreciate that.Shawn Wang: It's weird because I think that's true, but at the same time, you're only here on this earth for so long. When you zoom out, that actually reduces the available number of decisions that you can possibly make, which means that each decision goes from being a two-way door into a one-way door because you want to make more substantial decisions. Therefore, for example, when I changed jobs, it took me like two months of agonizing to finally land on something, because I could have done any number of things and I think you have to really examine your beliefs as to what the long-term trends are going to be and trade that off versus being happy in the short run.Adam Elmore: Yeah. I'm going to be trying to do that. I think I'm in the middle of the agonizing stage right now, trying to figure out what's next, but I'm going to try and think a little more long term.Shawn Wang: The thing I'll point you to, you're talking about courses and stuff like that in leverage, I'll say definitely check out Eric Jorgenson, who is the book writer for Naval Ravikant. He wrote the Almanac of Naval Ravikant, and he's trying to build up a thesis or a body of knowledge around what leverage is and what leverage means. And then the other thing I'll point you to is Nathan Barry, who's the founder of ConvertKit who talked about the letters of wealth creation and how some things are more high leverage than others, so.Adam Elmore: Thank you so much for that. Again, this podcast may just be for me, but that's okay because I got a lot out of it. Thank you so much for taking the time, Shawn.Shawn Wang: [inaudible 00:50:58].Adam Elmore: I didn't know how much I'd get in on my... I think we covered half the things I thought about talking to you about. You're just a wealth of knowledge, you're sort of a wise sage in this community and it's been so great to pick your brain. Thanks for coming on.Shawn Wang: I think we're the same age.Adam Elmore: Oh, yeah. Well yeah, you've been using your time better, I guess. You've been doing more high-leverage things or something.Shawn Wang: Yeah. Thanks for having me around, but we can talk anytime. I really enjoyed this conversation.Adam Elmore: That sounds good. Thanks, Shawn.

Syntax - Tasty Web Development Treats
Supper Club × Self Hosted Backend-as-a-service with Brandon Roberts

Syntax - Tasty Web Development Treats

Play Episode Listen Later Aug 26, 2022 47:28 Very Popular


In this supper club episode of Syntax, Wes and Scott talk with Brandon Roberts about Appwrite, how Appwrite works, who it's for, as well as his thoughts on Angular, Remix, and more. Hasura - Sponsor With Hasura, you can get a fully managed, production-ready GraphQL API as a service to help you build modern apps faster. You can get started for free in 30 seconds, or if you want to try out the Standard tier for zero cost, use the code “TryHasura” at this link: hasura.info. We've also got an amazing selection of GraphQL tutorials at hasura.io/learn. Lightstep Incident Response - Sponsor Streamline on-call, collaboration, incident management, and automation with a free 30-day trial of Lightstep Incident Response, built on ServiceNow. Usage-based pricing on active services promotes collaboration across your entire team to build a culture of service ownership. Listeners of Syntax will also receive a free Lightstep Incident Response T-shirt after firing an alert or incident. Pay for the services you use, not the number of people on your team with Lightstep Incident Response, built on ServiceNow. Streamline on-call, collaboration, incident management, and automation with a free 30-day trial. Fire an alert or incident today and receive a free Lightstep Incident Response t-shirt. Show Notes 00:36 Welcome 01:10 Who is Brandon Roberts? @BrandonTRoberts 02:00 What is Appwrite? Appwrite Getting started with Appwrite 03:17 What database layer does Appwrite use? 08:17 Is this working client side or server side? 09:54 Great docs and examples 12:55 How is deployment handled? Appwrite on Digital Ocean 15:30 Sponsor: Lightstep Incident Response 16:36 Appwrite's focus on developer experience Appwrite to do with Svelte 19:56 Realtime database options with Appwrite 22:40 Cloud functions in Appwrite 26:01 How does Appwrite scale? Docker Swarm 27:28 Who is Appwrite for? Flutter 30:03 What is Ionic? Ionic 32:12 What do you enjoy about working in Angular? Angular 35:08 Sponsor: Hasura 36:30 Supper club questions Night owl Shameless Plugs Guest: React Router Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

COMPRESSEDfm
75 | DevOps and Setting up a CICD Pipeline

COMPRESSEDfm

Play Episode Listen Later Aug 26, 2022 58:32


In this episode, Amy talks through the details of Dev Operations and setting up a CI/CD (Continuous Integration and Continuous Deployment) pipeline on a recent project, using RedwoodJS, Husky, Postgres, Render, and GitHub Integrations.SponsorsZEALZEAL is a computer software agency that delivers “the world's most zealous” and custom solutions. The company plans and develops web and mobile applications that consistently help clients draw in customers, foster engagement, scale technologies, and ensure delivery.ZEAL believes that a business is “only as strong as” its team and cares about culture, values, a transparent process, leveling up, giving back, and providing excellent equipment. The company has staffers distributed throughout the United States, and as it continues to grow, ZEAL looks for collaborative, object-oriented, and organized individuals to apply for open roles.For more information visit codingzeal.comVercelVercel combines the best developer experience with an obsessive focus on end-user performance. Their platform enables frontend teams to do their best work. It is the best place to deploy any frontend app. Start by deploying with zero configuration to their global edge network. Scale dynamically to millions of pages without breaking a sweat.For more information, visit Vercel.comDatoCMSDatoCMS is a complete and performant headless CMS built to offer the best developer experience and user-friendliness in the market. It features a rich, CDN-powered GraphQL API (with realtime updates!), a super-flexible way to handle dynamic layouts and structured content, and best-in-class image/video support, with progressive/LQIP image loading out-of-the-box."For more information, visit datocms.comShow Notes00:00 Introduction03:40 Amy's Rant On Work Life Balance06:56 What is DevOps?08:11 James Alternative Definition of DevOps10:37 DevOps Workflows of the Past13:00 CI/CD Pipelines + Vercel14:17 Sponsor: Vercel15:24 Amy's Experience with Redwood.js16:35 Readme.so17:12 Project Environments and Setup With Docker21:32 Project Setup - Github Projects, Github Actions, Kent C. Dodds Testing Trophy, etc.30:47 Hosting With Render35:01 Database Best Practices with Shipping Code36:43 Sponsor: DatoCMS37:37 Deploy Previews with Render Based on Github PRs44:01 Deploy Redwood.js on Render (Documentation)45:11 Sponsor: ZEAL45:57 Heroku Github Integration Issues49:39 Grab Bag Questions Section50:08 Picks and Plugs52:52 James's Plug - Top 5 Struggles of a Developer Advocate53:44 Create a SvelteKit Blog With Markdown FilesMDsvex57:03 Amy's Plug - Hashnode57:44 Amy's Pick - Matthew McConaughey's book, Greenlights

COMPRESSEDfm
74 | So you want to be a Developer Advocate?

COMPRESSEDfm

Play Episode Listen Later Aug 23, 2022 63:49


In this episode, James shares all the juicy details about Developer Relations / Developer Advocacy / Technical Evangelism and all the things that happen behind the scenes.SponsorsZEALZEAL is a computer software agency that delivers “the world's most zealous” and custom solutions. The company plans and develops web and mobile applications that consistently help clients draw in customers, foster engagement, scale technologies, and ensure delivery.ZEAL believes that a business is “only as strong as” its team and cares about culture, values, a transparent process, leveling up, giving back, and providing excellent equipment. The company has staffers distributed throughout the United States, and as it continues to grow, ZEAL looks for collaborative, object-oriented, and organized individuals to apply for open roles.For more information visit codingzeal.comVercelVercel combines the best developer experience with an obsessive focus on end-user performance. Their platform enables frontend teams to do their best work. It is the best place to deploy any frontend app. Start by deploying with zero configuration to their global edge network. Scale dynamically to millions of pages without breaking a sweat.For more information, visit Vercel.comDatoCMSDatoCMS is a complete and performant headless CMS built to offer the best developer experience and user-friendliness in the market. It features a rich, CDN-powered GraphQL API (with realtime updates!), a super-flexible way to handle dynamic layouts and structured content, and best-in-class image/video support, with progressive/LQIP image loading out-of-the-box."For more information, visit datocms.comShow Notes0:00 Introduction2:50 "Not" Parenting Rant3:56 Spending Time with Remix5:14 Remix vs Next.js7:09 Remix vs Next.js Article9:01 How James Got His First Developer Advocacy Role12:10 Sponsor: Vercel13:18 Working at Microsoft as a Technical Evangelist18:17 Why Content Creation is Important19:54 Difference Between Technical Evangelism and Developer Advocacy22:05 Tech Is More Than Just Software Development23:00 Sponsor: DatoCMS23:54 Moving to New York City24:50 The Impact of Student Hackathons27:22 James Meets Tom Holland31:04 Learn Build Teach31:28 Speaking in Public34:20 Sponsor: ZEAL35:05 Technical Experience at FedEx40:10 Transitioning Back to Developer Advocacy42:23 Downside of Developer Advocacy47:34 Grab Bag Questions47:46 What are two challenges faced by developer advocates?42:10 What has been the hardest challenge when building a community and how did you address it? What do you like the most and the least about Developer Advocacy?55:44 What advice would you give to become a Developer Advocate?56:36 How much time do you spend building stuff versus marketing versus documentation?58:14 Picks and Plugs52:24 James's Pick: Ryobi Battery Powered Weed-Eater1:00:10 James's Pick: James Q Quick on YouTube 01:00:21 Amy's Pick - Book: Story Worthy01:01:15 Amy's Plug: SelfTeach.me on Twitch

Syntax - Tasty Web Development Treats
Supper Club × Headless Ecommerce with Shopify's Josh Larson

Syntax - Tasty Web Development Treats

Play Episode Listen Later Aug 12, 2022 51:44 Very Popular


In this supper club episode of Syntax, Wes and Scott talk with Josh Larson from Shopify about headless ecommerce, including Hydrogen from Shopify, how integrations work with Shopify, and what the tech stack is behind Hydrogen. Hasura - Sponsor With Hasura, you can get a fully managed, production-ready GraphQL API as a service to help you build modern apps faster. You can get started for free in 30 seconds, or if you want to try out the Standard tier for zero cost, use the code “TryHasura” at this link: hasura.info. We've also got an amazing selection of GraphQL tutorials at hasura.io/learn. Lightstep Incident Response - Sponsor Streamline on-call, collaboration, incident management, and automation with a free 30-day trial of Lightstep Incident Response, built on ServiceNow. Usage-based pricing on active services promotes collaboration across your entire team to build a culture of service ownership. Listeners of Syntax will also receive a free Lightstep Incident Response T-shirt after firing an alert or incident. Pay for the services you use, not the number of people on your team with Lightstep Incident Response, built on ServiceNow. Streamline on-call, collaboration, incident management, and automation with a free 30-day trial. Fire an alert or incident today and receive a free Lightstep Incident Response t-shirt. Show Notes 00:38 Welcome 01:12 Guest introduction 03:16 What is Hydrogen from Shopify? Hydrogen Shopify Oxygen 11:23 Why would you want to go headless? 15:26 Sponsor: Hasura 16:56 Where does custom logic fit? 18:45 What is the stack behind Hydrogen? 24:16 Sponsor: Lightstep Incident Response 25:33 How much code is JavaScript vs React? 33:43 How do integrations work? 38:28 Supper Club Questions In Bed By 7pm VS Code Theme Zsh Hyper Laravel Vite Cloudflare Workers Rust Rust for JS 48:10 SIIIIICK ××× PIIIICKS ××× ××× SIIIIICK ××× PIIIICKS ××× The Story Of by Vice Shameless Plugs @JPLHomer Shopify Editions Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

Syntax - Tasty Web Development Treats
Supper Club × Syed Balkhi and WordPress

Syntax - Tasty Web Development Treats

Play Episode Listen Later Jul 29, 2022 56:39 Very Popular


In this supper club episode of Syntax, Wes and Scott talk with Syed Balkhi about his experiences blogging and developing plugins in the WordPress ecosytem. Hasura - Sponsor With Hasura, you can get a fully managed, production-ready GraphQL API as a service to help you build modern apps faster. You can get started for free in 30 seconds, or if you want to try out the Standard tier for zero cost, use the code “TryHasura” at this link: hasura.info. We've also got an amazing selection of GraphQL tutorials at hasura.io/learn. Sponsorname - Sponsor Show Notes 00:32 Welcome 01:52 Guest introduction WPBeginner WP Beginner YouTube CSS Tricks Smashing Magazine 04:33 What tips do you have for blogging and audience building? AnswerthePublic 09:09 How do you manage so many people? 13:07 What was your background before this all got big? 13:43 Sponsor: Hasura 15:01 How do you design your products? 18:40 YouTube, TikTok, and video 25:12 Why the WordPress hate? 29:03 What types of websites are being created in WordPress? Easy Digital Downloads WooCommerce MemberPress 34:13 Sponsor: Lightstep Incident Response 35:26 What schools are you building? Balkhi Foundation Pencils of Promise 40:51 Supper Club questions Copyhackers Swiped Uncanny Automator 53:07 SIIIIICK ××× PIIIICKS ××× ××× SIIIIICK ××× PIIIICKS ××× Streaks App Ready Player Two WP Forms AwesomeMotive Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

COMPRESSEDfm
72 | Working with Storybook

COMPRESSEDfm

Play Episode Listen Later Jul 26, 2022 45:00


In this episode, Amy shares her experience with working with Storybook, the pros and cons, and how it's changed her developer workflow.SponsorsZEALZEAL is a computer software agency that delivers “the world's most zealous” and custom solutions. The company plans and develops web and mobile applications that consistently help clients draw in customers, foster engagement, scale technologies, and ensure delivery.ZEAL believes that a business is “only as strong as” its team and cares about culture, values, a transparent process, leveling up, giving back, and providing excellent equipment. The company has staffers distributed throughout the United States, and as it continues to grow, ZEAL looks for collaborative, object-oriented, and organized individuals to apply for open roles.For more information visit codingzeal.comVercelVercel combines the best developer experience with an obsessive focus on end-user performance. Their platform enables frontend teams to do their best work. It is the best place to deploy any frontend app. Start by deploying with zero configuration to their global edge network. Scale dynamically to millions of pages without breaking a sweat.For more information, visit Vercel.comDatoCMSDatoCMS is a complete and performant headless CMS built to offer the best developer experience and user-friendliness in the market. It features a rich, CDN-powered GraphQL API (with realtime updates!), a super-flexible way to handle dynamic layouts and structured content, and best-in-class image/video support, with progressive/LQIP image loading out-of-the-box."For more information, visit datocms.comShow Notes0:00 IntroductionEpisode 32 - Getting Started with TypeScript7:17 Quick Rant: Wired Headphones8:49 Design SystemsEpisode 46 - Everything You Ever Wanted to know about Design SystemsBootstrapZurb Foundation10:36 Supports Multiple Libraries and Frameworks12:28 Sponsor: ZEAL13:13 How do you enter all the information into Storybook?Frontend Masters: Design Systems with React & Storybook - Emma Bostian18:24 Storybook in the Wild: Building out Frontend Components for Backend DevelopersEpisode 54 - Why RedwoodJS is the App Framework for Startups with David Price Redwood.js with David Price22:17 Comparing Storybook to Testing25:31 Sponsor: Vercel26:39 Breaking Down a Component29:29 Add-Ons with Storybook31:28 Storybook and Figma Integration31:46 Sponsor: DatoCMS32:40 Do you use Storybook at work?33:39 Do you think Redwood is an option that you'll use more of going forward? Or, do you think Storybook is something that you implement outside of Redwood in some of your existing setups?35:05 Is Redwood something teams should be looking at for new projects?36:32 Grab Bag Questions39:16 Picks and Plugs39:26 James's Pick: Spike Ball41:07 James's Plug: TikTok42:25 Amy's Pick: PARA Method43:42 Amy's Plug: Everything Svelte

Talking Drupal
Talking Drupal #357 - GraphQL

Talking Drupal

Play Episode Listen Later Jul 25, 2022 60:21


Today we are talking about GraphQL with Alexander Varwijk. www.talkingDrupal.com/357 Topics What is GraphQL Common use cases Why GraphQL over JSON:Api How is it being used? How to use it with Drupal Is there a standard? How do you customize it? What resources do you recommend? Resources Book module listener Amit Building a GraphQL API - Beyond the basics GraphQL API examples Shopify GitHub The GraphQL specification repository on GitHub The Drupal GraphQL module The GraphQL PHP library GraphQL in the Open Social Drupal distribution Serving GraphQL Subscriptions Using PHP and Drupal The GraphQL documentation website Production Ready GraphQL - Marc-Andre Giroux GraphQL specification for servers and clients http://spec.graphql.org/ https://github.com/graphql/graphql-spec/ GraphQL OAuth The GraphQL Compose module UrQL Relay ReScript Caching & GraphQL: Setting the Story Straight Guests Alexander Varwijk - www.alexandervarwijk.com/ @kingdutch Hosts Nic Laflin - www.nLighteneddevelopment.com @nicxvan John Picozzi - www.epam.com @johnpicozzi Ryan Price - ryanpricemedia.com - @liberatr

Elixir Mix
Combining GraphQL and LiveView with Abul Asar Sayyad - EMX 182

Elixir Mix

Play Episode Listen Later Jul 20, 2022 44:27


Today we talk with Abul Asar Sayyad, a software engineer from Mumbai, India.  Working for ID Plans, a commercial property management solution.  We discuss his blog article about combining GraphQL with LiveView for rendering on the front end.  We also dive into GraphQL libraries, working with LiveView, and testing.  Sponsors Top End Devs Coaching | Top End Devs Links Abul Asar's Blog LinkedIn: AbulAsar Sayyad Fetching data from external Graphql API service in Phoenix LiveView Hashnode - Blogging community for developers, and people in tech GitHub - uesteibar/neuron: A GraphQL client for Elixir GitHub - annkissam/common_graphql_client: Elixir GraphQL Client with HTTP and WebSocket Support GitHub - sasa1977/con_cache: ets based key/value cache with row level isolated writes and ttl support Creating Note taking app using LiveView and GenServer - Part 1 Picks Abul - Project management tool in LiveView Abul - Blog about canvas realtime drawing coming soon Abul - Thor Love and Thunder Adi- GitHub - annkissam/common_graphql_client: Elixir GraphQL Client with HTTP and WebSocket Support Adi - donkeycr.app Allen - How to Cache in LiveView Sascha - The Sprawl

Syntax - Tasty Web Development Treats
Supper Club × 70,000 Serverless Functions with Kristi Perreault of Liberty Mutual

Syntax - Tasty Web Development Treats

Play Episode Listen Later Jul 15, 2022 56:17 Very Popular


In this supper club episode of Syntax, Wes and Scott talk with Kristi Perreault of Liberty Mutual about why they're using serverless functions, what languages they write in, managing security and montoring, and Kristi's journey into tech as a career. Hasura - Sponsor With Hasura, you can get a fully managed, production-ready GraphQL API as a service to help you build modern apps faster. You can get started for free in 30 seconds, or if you want to try out the Standard tier for zero cost, use the code “TryHasura” at this link: hasura.info. We've also got an amazing selection of GraphQL tutorials at hasura.io/learn. Stack Overflow Podcast - Sponsor For over a dozen years, the Stack Overflow Podcast has been exploring what it means to be a developer, and how the art and practice of software programming is changing our world. Hosted by Ben Popper, Cassidy Williams, and Ceora Ford, the Stack Overflow Podcast is your home for all things code. Listen to new episodes twice a week, wherever you get your podcasts. Lightstep Incident Response - Sponsor Streamline on-call, collaboration, incident management, and automation with a free 30-day trial of Lightstep Incident Response, built on ServiceNow. Usage-based pricing on active services promotes collaboration across your entire team to build a culture of service ownership. Listeners of Syntax will also receive a free Lightstep Incident Response T-shirt after firing an alert or incident. Pay for the services you use, not the number of people on your team with Lightstep Incident Response, built on ServiceNow. Streamline on-call, collaboration, incident management, and automation with a free 30-day trial. Fire an alert or incident today and receive a free Lightstep Incident Response t-shirt. Show Notes 00:33 Welcome 03:24 Guest introduction @kperreault95 Kristi Perreault on Dev.to Kristi Perreault AWS Hero Liberty Mutual 04:55 Developers at Mutual Liberty 07:05 What did you do before serverless functions? 08:36 Why are you using serverless functions? 12:39 What languages are you writing for serverless functions? 15:53 Sponsor: Hasura 17:22 Where does all the code live? 20:58 AWS CDK AWS CDK CDK Workshop 25:55 Sponsor: Lightstep Incident Response 27:07 How did you get into tech? 31:44 How do you organize all the functions? 33:51 How important is security? 35:23 What are IM roles? 36:16 How do you deal with spiking and monitoring? Datadog Splunk 41:20 Sponsor: Stackoverflow Podcast 42:02 Have you used Edge functions? 42:50 Supper Club Questions Off by None newsletter Ready Set Cloud ××× SIIIIICK ××× PIIIICKS ××× Loki on Disney+ Shameless Plugs Real World Serverless Podcast Serverless Denver Group AWS Summits @ServerlessCO Kristi Perreault on Medium Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

Ruby Rogues
Speed Up Your Rails App by Lazy Loading Your N+1 Queries - RUBY 554

Ruby Rogues

Play Episode Listen Later Jul 13, 2022 39:13


Wouldn't it be great if ActiveRecord didn't make you think about eager loading and it just did the "right" thing by default?  Lazy loading is extremely helpful when the list of associations to load is determined dynamically.  Today on the show, Charles and Luke interview Evgeniy Demin, Principal Engineer at Toptal.  They discuss how you can speed up your processes by lazy loading your N+1 queries, plus various tools to optimize your workflows. In this episode… N+1 queries and cases ActiveRecord methodology Developing new features quickly Various tools and ideas The fulfill method Alternative stacks Ruby Tik-Tok Sponsors Avo Top End Devs Coaching | Top End Devs Links LinkedIn: Evgeniy Demin GitHub - djezzzl/n1_loader: Loader to solve N+1 issues for good. Highly recommended for GraphQL API. GitHub - DmitryTsepelev/ar_lazy_preload: Lazy loading associations for the ActiveRecord models GitHub - salsify/goldiloader: Just the right amount of Rails eager loading N+1 problem will never be an issue with N1Loader gem Enhanced ActiveRecord preloading Picks Charles- PODFEST EXPO | Where Your Voice Matters Charles- Legendary: A Marvel Deck Building Game - Guardians of the Galaxy Charles- Vistaprint US Online Printing: Business Cards, Signage & More Charles- Products Charles - Winco Foods Evgeniy - Toptal Evgeniy - Telltale Games Luke- Watch The Lincoln Lawyer | Netflix Official Site

All Ruby Podcasts by Devchat.tv
Speed Up Your Rails App by Lazy Loading Your N+1 Queries - RUBY 554

All Ruby Podcasts by Devchat.tv

Play Episode Listen Later Jul 13, 2022 39:13


Wouldn't it be great if ActiveRecord didn't make you think about eager loading and it just did the "right" thing by default?  Lazy loading is extremely helpful when the list of associations to load is determined dynamically.  Today on the show, Charles and Luke interview Evgeniy Demin, Principal Engineer at Toptal.  They discuss how you can speed up your processes by lazy loading your N+1 queries, plus various tools to optimize your workflows. In this episode… N+1 queries and cases ActiveRecord methodology Developing new features quickly Various tools and ideas The fulfill method Alternative stacks Ruby Tik-Tok Sponsors Avo Top End Devs Coaching | Top End Devs Links LinkedIn: Evgeniy Demin GitHub - djezzzl/n1_loader: Loader to solve N+1 issues for good. Highly recommended for GraphQL API. GitHub - DmitryTsepelev/ar_lazy_preload: Lazy loading associations for the ActiveRecord models GitHub - salsify/goldiloader: Just the right amount of Rails eager loading N+1 problem will never be an issue with N1Loader gem Enhanced ActiveRecord preloading Picks Charles- PODFEST EXPO | Where Your Voice Matters Charles- Legendary: A Marvel Deck Building Game - Guardians of the Galaxy Charles- Vistaprint US Online Printing: Business Cards, Signage & More Charles- Products Charles - Winco Foods Evgeniy - Toptal Evgeniy - Telltale Games Luke- Watch The Lincoln Lawyer | Netflix Official Site

Syntax - Tasty Web Development Treats
Supper Club × Developer Experience with Shawn Wang

Syntax - Tasty Web Development Treats

Play Episode Listen Later Jul 1, 2022 53:31 Very Popular


In this supper club episode of Syntax, Wes and Scott talk with Shawn Wang about his thoughts on developer experience, why DX is important, and the importance of learning in public. Hasura - Sponsor With Hasura, you can get a fully managed, production-ready GraphQL API as a service to help you build modern apps faster. You can get started for free in 30 seconds, or if you want to try out the Standard tier for zero cost, use the code “TryHasura” at this link: hasura.info. We've also got an amazing selection of GraphQL tutorials at hasura.io/learn. LogRocket - Sponsor LogRocket lets you replay what users do on your site, helping you reproduce bugs and fix issues faster. It's an exception tracker, a session re-player and a performance monitor. Get 14 days free at logrocket.com/syntax. Show Notes 00:32 Welcome 01:56 Guest introduction swyx.io Why Temporal? 06:09 What is Developer Experience? Sarah Drasner 08:35 Is VS Code considered DX? 09:28 Why is internal DX important? Vercel NextJS 11:44 Is DX helpful to small organizations as well? 15:27 Parsimony Parsimony 16:43 Is productivity the main focus? 21:09 Sponsor: Hasura 22:48 What are your thoughts on React? 27:31 Designing for API success 30:44 Sponsor: LogRocket 32:07 What is external developer experience? 36:05 Learning in public 40:46 Supper Club questions dx.tips Retreon VS Code Theme Agnoster ZSH Theme freeCodeCamp Frontend Masters QConf Learn in Public ××× SIIIIICK ××× PIIIICKS ××× Scott: The Stormlight Archive Shameless Plugs Scott: LevelUp Tutorials Wes: Wes Bos Tutorials Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

COMPRESSEDfm
Secrets Things, Env Vars, How to Handle API Keys Correctly

COMPRESSEDfm

Play Episode Listen Later Jun 28, 2022 47:11


In this episode, James shares common mistakes people make with their API Keys and explains the appropriate way to handle them.SponsorsVercelVercel combines the best developer experience with an obsessive focus on end-user performance. Their platform enables frontend teams to do their best work. It is the best place to deploy any frontend app. Start by deploying with zero configuration to their global edge network. Scale dynamically to millions of pages without breaking a sweat.For more information, visit Vercel.comZEAL is hiring!ZEAL is a computer software agency that delivers “the world's most zealous” and custom solutions. The company plans and develops web and mobile applications that consistently help clients draw in customers, foster engagement, scale technologies, and ensure delivery.ZEAL believes that a business is “only as strong as” its team and cares about culture, values, a transparent process, leveling up, giving back, and providing excellent equipment. The company has staffers distributed throughout the United States, and as it continues to grow, ZEAL looks for collaborative, object-oriented, and organized individuals to apply for open roles.For more information visit softwareresidency.com/careersDatoCMSDatoCMS is a complete and performant headless CMS built to offer the best developer experience and user-friendliness in the market. It features a rich, CDN-powered GraphQL API (with realtime updates!), a super-flexible way to handle dynamic layouts and structured content, and best-in-class image/video support, with progressive/LQIP image loading out-of-the-box."For more information, visit datocms.comShow Notes0:00 IntroductionYouTube Video RE: Mistakes People Make with API Keys6:42 API Keys7:37 Where do API Keys come from?8:57 Mistakes People Make with API Keys9:10 Mistake #1: Hard Coding the API Key Value11:45 Sponsor: Vercel12:53 Mistake #2: Adding an API Key to the .env file, but still exposing the key16:20 Mistake #3: Committing Your Key to Source Control17:59 What should you do about a leaked API key?19:38 Using .gitignore21:20 The Best Way to Handle Secrets22:57 Serverless FunctionsEpisode 57 - Authentication and Authorization and other Buzz Words29:55 Sponsor: ZEAL30:41 Where would you put a Bearer Token?31:40 Server Side Rendering33:49 Public API Keys37:20 Sponsor: DatoCMS38:13 Grab Bag Questions38:24 What's the best way to share environmental variables across different machines?38:35 What are the pros and cons of system environmental variables vs a KMS (Key Management System)?40:34 Picks and Plugs40:44 James's Pick: Sketcher's Tennis Shoes from Costco44:54 James's Plug: YouTube Video - 10 Things JavaScript Developers Have Stopped Doing45:26 Amy's Picks: James Clear 3-2-1 NewsletterAtomic Habits, by James Clear46:14 Amy's Pick: Keystone.js on Level Up Tutorials

Screaming in the Cloud
Google Cloud Run, Satisfaction, and Scalability with Steren Giannini

Screaming in the Cloud

Play Episode Listen Later Jun 23, 2022 37:01


Full Description / Show Notes Steren and Corey talk about how Google Cloud Run got its name (00:49) Corey talks about his experiences using Google Cloud (2:42) Corey and Steven discuss Google Cloud's cloud run custom domains (10:01) Steren talks about Cloud Run's high developer satisfaction and scalability (15:54) Corey and Steven talk about Cloud Run releases at Google I/O (23:21) Steren discusses the majority of developer and customer interest in Google's cloud product (25:33) Steren talks about his 20% projects around sustainability (29:00) About SterenSteren is a Senior Product Manager at Google Cloud. He is part of the serverless team, leading Cloud Run. He is also working on sustainability, leading the Google Cloud Carbon Footprint product.Steren is an engineer from École Centrale (France). Prior to joining Google, he was CTO of a startup building connected objects and multi device solutions.Links Referenced: Google Cloud Run: https://cloud.run sheets-url-shortener: https://github.com/ahmetb/sheets-url-shortener snark.cloud/run: https://snark.cloud/run Twitter: https://twitter.com/steren TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined today by Steren Giannini, who is a senior product manager at Google Cloud, specifically on something called Google Cloud Run. Steren, thank you for joining me today.Steren: Thanks for inviting me, Corey.Corey: So, I want to start at the very beginning of, “Oh, a cloud service. What are we going to call it?” “Well, let's put the word cloud in it.” “Okay, great. Now, it is cloud, so we have to give it a vague and unassuming name. What does it do?” “It runs things.” “Genius. Let's break and go for work.” Now, it's easy to imagine that you spent all of 30 seconds on a name, but it never works that way. How easy was it to get to Cloud Run as a name for the service?Steren: [laugh]. Such a good question because originally it was not named Cloud Run at all. The original name was Google Serverless Engine. But a few people know that because they've been helping us since the beginning, but originally it was Google Serverless Engine. Nobody liked the name internally, and I think at one point, we wondered, “Hey, can we drop the engine structure and let's just think about the name. And what does this thing do?” “It runs things.”We already have Cloud Build. Well, wouldn't it be great to have Cloud Run to pair with Cloud Build so that after you've built your containers, you can run them? And that's how we ended up with this very simple Cloud Run, which today seems so obvious, but it took us a long time to get to that name, and we actually had a lot of renaming to do because we were about to ship with Google Serverless Engine.Corey: That seems like a very interesting last-minute change because it's not just a find and replace at that point, it's—Steren: No.Corey: —“Well, okay, if we call it Cloud Run, which can also be a verb or a noun, depending, is that going to change the meaning of some sentences?” And just doing a find and replace without a proofread pass as well, well, that's how you wind up with funny things on Twitter.Steren: API endpoints needed to be changed, adding weeks of delays to the launch. That is why we—you know, [laugh] announced in 2018 and publicly launched in 2019.Corey: I've been doing a fair bit of work in cloud for a while, and I wound up going down a very interesting path. So, the first native Google Cloud service—not things like WP Engine that ride on top of GCP—but my first native Google Cloud Service was done in service of this podcast, and it is built on Google Cloud Run. I don't think I've told you part of this story yet, but it's one of the reasons I reached out to invite you onto the show. Let me set the stage here with a little bit of backstory that might explain what the hell I'm talking about.As listeners of this show are probably aware, we have sponsors whom we love and adore. In the early days of this show, they would say, “Great, we want to tell people about our product”—which is the point of a sponsorship—“And then send them to a URL.” “Great. What's the URL?” And they would give me something that was three layers deep, then with a bunch of UTM tracking parameters at the end.And it's, “You do realize that no one is going to be sitting there typing all of that into a web browser?” At best, you're going to get three words or so. So, I built myself a URL redirector, snark.cloud. I can wind up redirecting things in there anywhere it needs to go.And for a long time, I did this on top of S3 and then put CloudFront in front of it. And this was all well and good until, you know, things happened in the fullness of time. And now holy crap, I have an operations team involved in things, and maybe I shouldn't be the only person that knows how to work on all of these bits and bobs. So, it was time to come up with something that had a business user-friendly interface that had some level of security, so I don't wind up automatically building out a spam redirect service for anything that wants to, and it needs to be something that's easy to work with. So, I went on an exploration.So, at first it showed that there were—like, I have an article out that I've spoken about before that there are, “17 Ways to Run Containers on AWS,” and then I wrote the sequel, “17 More Ways to Run Containers on AWS.” And I'm keeping a list, I'm almost to the third installation of that series, which is awful. So, great. There's got to be some ways to build some URL redirect stuff with an interface that has an admin panel. And I spent three days on this trying a bunch of different things, and some were running on deprecated versions of Node that wouldn't build properly and others were just such complex nonsense things that had got really bad. I was starting to consider something like just paying for Bitly or whatnot and making it someone else's problem.And then I stumbled upon something on GitHub that really was probably one of the formative things that changed my opinion of Google Cloud for the better. And within half an hour of discovering this thing, it was up and running. I did the entire thing, start to finish, from my iPad in a web browser, and it just worked. It was written by—let me make sure I get his name correct; you know, messing up someone's name is a great way to say that we don't care about them—Ahmet Balkan used to work at Google Cloud; now he's over at Twitter. And he has something up on GitHub that is just absolutely phenomenal about this, called sheets-url-shortener.And this is going to sound wild, but stick with me. The interface is simply a Google Sheet, where you have one column that has the shorthand slug—for example, run; if you go to snark.cloud/run, it will redirect to Google Cloud Run's website. And the second column is where you want it to go. The end.And whenever that gets updated, there's of course some caching issues, which means it can take up to five seconds from finishing that before it will actually work across the entire internet. And as best I can tell, that is fundamentally magic. But what made it particularly useful and magic, from my perspective, was how easy it was to get up and running. There was none of this oh, but then you have to integrate it with Google Sheets and that's a whole ‘nother team so there's no way you're going to be able to figure that out from our Docs. Go talk to them and then come back in the day.They were the get started, click here to proceed. It just worked. And it really brought back some of the magic of cloud for me in a way that I hadn't seen in quite a while. So, all which is to say, amazing service, I continue to use it for all of these sponsored links, and I am still waiting for you folks to bill me, but it fits comfortably in the free tier because it turns out that I don't have hundreds of thousands of people typing it in every week.Steren: I'm glad it went well. And you know, we measure tasks success for Cloud Run. And we do know that most new users are able to deploy their apps very quickly. And that was the case for you. Just so you know, we've put a lot of effort to make sure it was true, and I'll be glad to tell you more about all that.But for that particular service, yes, I suppose Ahmet—who I really enjoyed working with on Cloud Run, he was really helpful designing Cloud Run with us—has open-sourced this side project. And basically, you might even have clicked on a deploy to Cloud Run button on GitHub, right, to deploy it?Corey: That is exactly what I did and it somehow just worked and—Steren: Exactly.Corey: And it knew, even logging into the Google Cloud Console because it understands who I am because I use Google Docs and things, I'm already logged in. None of this, “Oh, which one of these 85 credential sets is it going to be?” Like certain other clouds. It was, “Oh, wow. Wait, cloud can be easy and fun? When did that happen?”Steren: So, what has happened when you click that deploy to Google Cloud button, basically, the GitHub repository was built into a container with Cloud Build and then was deployed to Cloud Run. And once on Cloud Run, well, hopefully, you have forgotten about it because that's what we do, right? We—give us your code, in a container if you know containers if you don't just—we support, you know, many popular languages, and we know how to build them, so don't worry about that. And then we run it. And as you said, when there is low traffic or no traffic, it scales to zero.When there is low traffic, you're likely going to stay under the generous free tier. And if you have more traffic for, you know, Screaming in the Cloud suddenly becoming a high destination URL redirects, well, Cloud Run will scale the number of instances of this container to be able to handle the load. Cloud Run scales automatically and very well, but only—as always—charging you when you are processing some requests.Corey: I had to fork and make a couple of changes myself after I wound up doing some testing. The first was to make the entire thing case insensitive, which is—you know, makes obvious sense. And the other was to change the permanent redirect to a temporary redirect because believe it or not, in the fullness of time, sometimes sponsors want to change the landing page in different ways for different campaigns and that's fine by me. I just wanted to make sure people's browser cache didn't remember it into perpetuity. But it was easy enough to run—that was back in the early days of my exploring Go, which I've been doing this quarter—and in the couple of months this thing has been running it has been effectively flawless.It's set it; it's forget it. The only challenges I had with it are it was a little opaque getting a custom domain set up that—which is still in beta, to be clear—and I've heard some horror stories of people saying it got wedged. In my case, no, I deployed it and I started refreshing it and suddenly, it start throwing an SSL error. And it's like, “Oh, that's not good, but I'm going to break my own lifestyle here and be patient for ten minutes.” And sure enough, it cleared itself and everything started working. And that was the last time I had to think about any of this. And it just worked.Steren: So first, Cloud Run is HTTPS only. Why? Because it's 2020, right? It's 2022, but—Corey: [laugh].Steren: —it's launched in 2020. And so basically, we have made a decision that let's just not accept HTTP traffic; it's only HTTPS. As a consequence, we need to provision a cert for your custom domain. That is something that can take some time. And as you said, we keep it in beta or in preview because we are not yet satisfied with the experience or even the performance of Cloud Run custom domains, so we are actively working on fixing that with a different approach. So, expect some changes, hopefully, this year.Corey: I will say it does take a few seconds when people go to a snark.cloud URL for it to finish resolving, and it feels on some level like it's almost like a cold start problem. But subsequent visits, the same thing also feel a little on the slow and pokey side. And I don't know if that's just me being wildly impatient, if there's an optimization opportunity, or if that's just inherent to the platform that is not under current significant load.Steren: So, it depends. If the Cloud Run service has scaled down to zero, well of course, your service will need to be started. But what we do know, if it's a small Go binary, like something that you mentioned, it should really take less than, let's say, 500 milliseconds to go from zero to one of your container instance. Latency can also be due to the way the code is running. If it occurred is fetching things from Google Sheets at every startup, that is something that could add to the startup latency.So, I would need to take a look, but in general, we are not spinning up a virtual machine anytime we need to scale horizontally. Like, our infrastructure is a multi-tenant, rapidly scalable infrastructure that can materialize a container in literally 300 milliseconds. The rest of the latency comes from what does the container do at startup time?Corey: Yeah, I just ran a quick test of putting time in front of a curl command. It looks like it took 4.83 seconds. So, enough to be perceptive. But again, for just a quick redirect, it's generally not the end of the world and there's probably something I'm doing that is interesting and odd. Again, I did not invite you on the show to file a—Steren: [laugh].Corey: Bug report. Let's be very clear here.Steren: Seems on the very high end of startup latencies. I mean, I would definitely expect under the second. We should deep-dive into the code to take a look. And by the way, building stuff on top of spreadsheets. I've done that a ton in my previous lives as a CTO of a startup because well, that's the best administration interface, right? You just have a CRUD UI—Corey: [unintelligible 00:12:29] world and all business users understand it. If people in Microsoft decided they were going to change Microsoft Excel interface, even a bit, they would revert the change before noon of the same day after an army of business users grabbed pitchforks and torches and marched on their headquarters. It's one of those things that is how the world runs; it is the world's most common IDE. And it's great, but I still think of databases through the lens of thinking about it as a spreadsheet as my default approach to things. I also think of databases as DNS, but that's neither here nor there.Steren: You know, if you have maybe 100 redirects, that's totally fine. And by the way, the beauty of Cloud Run in a spreadsheet, as you mentioned is that Cloud Run services run with a certain identity. And this identity, you can grant it permissions. And in that case, what I would recommend if you haven't done so yet, is to give an identity to your Cloud Run service that has the permission to read that particular spreadsheet. And how you do that you invite the email of the service account as a reader of your spreadsheet, and that's probably what you did.Corey: The click button to the workflow on Google Cloud automatically did that—Steren: Oh, wow.Corey: —and taught me how to do it. “Here's the thing that look at. The end.” It was a flawless user-onboarding experience.Steren: Very nicely done. But indeed, you know, there is this built-in security which is the principle of minimal permission, like each of your Cloud Run service should basically only be able to read and write to the backing resources that they should. And by default, we give you a service account which has a lot of permissions, but our recommendation is to narrow those permissions to basically only look at the cloud storage buckets that the service is supposed to look at. And the same for a spreadsheet.Corey: Yes, on some level, I feel like I'm going to write an analysis of my own security approach. It would be titled, “My God, It's Full Of Stars” as I look at the IAM policies of everything that I've configured. The idea of least privilege is great. What I like about this approach is that it made it easy to do it so I don't have to worry about it. At one point, I want to go back and wind up instrumenting it a bit further, just so I can wind up getting aggregate numbers of all right, how many times if someone visited this particular link? It'll be good to know.And I don't know… if I have to change permissions to do that yet, but that's okay. It's the best kind of problem: future Corey. So, we'll deal with that when the time comes. But across the board, this has just been a phenomenal experience and it's clear that when you were building Google Cloud Run, you understood the assignment. Because I was looking for people saying negative things about it and by and large, all of its seem to come from a perspective of, “Well, this isn't going to be the most cost-effective or best way to run something that is hyperscale, globe-spanning.”It's yes, that's the thing that Kubernetes was originally built to run and for some godforsaken reason people run their blog on it instead now. Okay. For something that is small, scales to zero, and has long periods where no one is visiting it, great, this is a terrific answer and there's absolutely nothing wrong with that. It's clear that you understood who you were aiming at, and the migration strategy to something that is a bit more, I want to say robust, but let's be clear what I mean when I'm saying that if you want something that's a little bit more impressive on your SRE resume as you're trying a multi-year project to get hired by Google or pretend you got hired by Google, yeah, you can migrate to something else in a relatively straightforward way. But that this is up, running, and works without having to think about it, and that is no small thing.Steren: So, there are two things to say here. The first is yes, indeed, we know we have high developer satisfaction. You know, we measure this—in Google Cloud, you might have seen those small satisfaction surveys popping up sometimes on the user interface, and you know, we are above 90% satisfaction score. We hire third parties to help us understand how usable and what satisfaction score would users get out of Cloud Run, and we are constantly getting very, very good results, in absolute but also compared to the competition.Now, the other thing that you said is that, you know, Cloud Run is for small things, and here while it is definitely something that allows you to be productive, something that strives for simplicity, but it also scales a lot. And contrary to other systems, you do not have any pre-provisioning to make. So, we have done demos where we go from zero to 10,000 container instances in ten seconds because of the infrastructure on which Cloud Run runs, which is fully managed and multi-tenant, we can offer you this scale on demand. And many of our biggest customers have actually not switched to something like Kubernetes after starting with Cloud Run because they value the low maintenance, the no infrastructure management that Cloud Run brings them.So, we have like Ikea, ecobee… for example ecobee, you know, the smart thermostats are using Cloud Run to ingest events from the thermostat. I think Ikea is using Cloud Run more and more for more of their websites. You know, those companies scale, right? This is not, like, scale to zero hobby project. This is actually production e-commerce and connected smart objects production systems that have made the choice of being on a fully-managed platform in order to reduce their operational overhead.[midroll 00:17:54]Corey: Let me be clear. When I say scale—I think we might be talking past each other on a small point here. When I say scale, I'm talking less about oh tens or hundreds of thousands of containers running concurrently. I'm talking in a more complicated way of, okay, now we have a whole bunch of different microservices talking to one another and affinity as far as location to each other for data transfer reasons. And as you start beginning to service discovery style areas of things, where we build a really complicated applications because we hired engineers and failed to properly supervise them, and that type of convoluted complex architecture.That's where it feels like Cloud Run increasingly, as you move in that direction, starts to look a little bit less like the tool of choice. Which is fine, I want to be clear on that point. The sense that I've gotten of it is a great way to get started, it's a great way to continue running a thing you don't have to think about because you have a day job that isn't infrastructure management. And it is clear to—as your needs change—to either remain with the service or pivot to a very close service without a whole lot of retooling, which is key. There's not much of a lock-in story to this, which I love.Steren: That was one of the key principles when we started to design Cloud Run was, you know, we realized the industry had agreed that the container image was the standard for the deployment artifact of software. And so, we just made the early choice of focusing on deploying containers. Of course, we are helping users build those containers, you know, we have things called build packs, we can continuously deploy from GitHub, but at the end of the day, the thing that gets auto-scaled on Cloud Run is a container. And that enables portability.As you said. You can literally run the same container, nothing proprietary in it, I want to be clear. Like, you're just listening on a port for some incoming requests. Those requests can be HTTP requests, events, you know, we have products that can push events to Cloud Run like Eventarc or Pub/Sub. And this same container, you can run it on your local machine, you can run it on Kubernetes, you can run it on another cloud. You're not locked in, in terms of API of the compute.We even went even above and beyond by having the Cloud Run API looks like a Kubernetes API. I think that was an extra effort that we made. I'm not sure people care that much, but if you look at the Cloud Run API, it is actually exactly looking like Kubernetes, Even if there is no Kubernetes at all under the hood; we just made it for portability. Because we wanted to address this concern of serverless which was lock-in. Like, when you use a Function as a Service product, you are worried that the architecture that you are going to develop around this product is going to be only working in this particular cloud provider, and you're not in control of the language, the version that this provider has decided to offer you, you're not in control of more of the complexity that can come as you want to scan this code, as you want to move this code between staging and production or test this code.So, containers are really helping with that. So, I think we made the right choice of this new artifact that to build Cloud Run around the container artifact. And you know, at the time when we launched, it was a little bit controversial because back in the day, you know, 2018, 2019, serverless really meant Functions as a Service. So, when we launched, we little bit redefined serverless. And we basically said serverless containers. Which at the time were two worlds that in the same sentence were incompatible. Like, many people, including internally, had concerns around—Corey: Oh, the serverless versus container war was a big thing for a while. Everyone was on a different side of that divide. It's… containers are effectively increasingly—and I know, I'll get email for this, and I don't even slightly care, they're a packaging format—Steren: Exactly.Corey: —where it solves the problem of how do I build this thing to deploy on Debian instances? And Ubuntu instances, and other instances, God forbid, Windows somewhere, you throw a container over the wall. The end. Its DevOps is about breaking down the walls between Dev and Ops. That's why containers are here to make them silos that don't have to talk to each other.Steren: A container image is a glorified zip file. Literally. You have a set of layers with files in them, and basically, we decided to adopt that artifact standard, but not the perceived complexity that existed at the time around containers. And so, we basically merged containers with serverless to make something as easy to use as a Function as a Service product but with the power of bringing your own container. And today, we are seeing—you mentioned, what kind of architecture would you use Cloud Run for?So, I would say now there are three big buckets. The obvious one is anything that is a website or an API, serving public internet traffic, like your URL redirect service, right? This is, you have an API, takes a request and returns a response. It can be a REST API, GraphQL API. We recently added support for WebSockets, which is pretty unique for a service offering to support natively WebSockets.So, what I mean natively is, my client can open a socket connection—a bi-directional socket connection—with a given instance, for up to one hour. This is pretty unique for something that is as fully managed as Cloud Run.Corey: Right. As we're recording this, we are just coming off of Google I/O, and there were a number of announcements around Cloud Run that were touching it because of, you know, strange marketing issues. I only found out that Google I/O was a thing and featured cloud stuff via Twitter at the time it was happening. What did you folks release around Cloud Run?Steren: Good question, actually. Part of the Google I/O Developer keynote, I pitched a story around how Cloud Run helps developers, and the I/O team liked the story, so we decided to include that story as part of the live developer keynote. So, on stage, we announced Cloud Run jobs. So now, I talked to you about Cloud Run services, which can be used to expose an API, but also to do, like, private microservice-to-microservice communication—because cloud services don't have to be public—and in that case, we support GRPC and, you know, a very strong security mechanism where only Service A can invoke Service B, for example, but Cloud Run jobs are about non-request-driven containers. So, today—I mean, before Google I/O a few days ago, the only requirement that we imposed on your container image was that it started to listen for requests, or events, or GRPC—Corey: Web requests—Steren: Exactly—Corey: It speaks [unintelligible 00:24:35] you want as long as it's HTTP. Yes.Steren: That was the only requirement we asked you to have on your container image. And now we've changed that. Now, if you have a container that basically starts and executes to completion, you can deploy it on a Cloud Run job. So, you will use Cloud Run jobs for, like, daily batch jobs. And you have the same infrastructure, so on-demand, you can go from zero to, I think for now, the maximum is a hundred tasks in parallel, for—of course, you can run many tasks in sequence, but in parallel, you can go from zero to a hundred, right away to run your daily batch job, daily admin job, data processing.But this is more in the batch mode than in streaming mode. If you would like to use a more, like, streaming data processing, than a Cloud Run service would still be the best fit because you can literally push events to it, and it will auto-scale to handle any number of events that it receives.Corey: Do you find that the majority of customers are using Cloud Run for one-off jobs that barely will get more than a single container, like my thing, or do you find that they're doing massively parallel jobs? Where's the lion's share of developer and customer interest?Steren: It's both actually. We have both individual developers, small startups—which really value the scale to zero and pay per use model of Cloud Run. Your URL redirect service probably is staying below the free tier, and there are many, many, many users in your case. But at the same time, we have big, big, big customers who value the on-demand scalability of Cloud Run. And for these customers, of course, they will probably very likely not scale to zero, but they value the fact that—you know, we have a media company who uses Cloud Run for TV streaming, and when there is a soccer game somewhere in the world, they have a big spike of usage of requests coming in to their Cloud Run service, and here they can trust the rapid scaling of Cloud Run so they don't have to pre-provision things in advance to be able to serve that sudden traffic spike.But for those customers, Cloud Run is priced in a way so that if you know that you're going to consume a lot of Cloud Run CPU and memory, you can purchase Committed Use Discounts, which will lower your bill overall because you know you are going to spend one dollar per hour on Cloud Run, well purchase a Committed Use Discount because you will only spend 83 cents instead of one dollar. And also, Cloud Run and comes with two pricing model, one which is the default, which is the request-based pricing model, which is basically you only have CPU allocated to your container instances if you are processing at least one request. But as a consequence of that, you are not paying outside of the processing of those requests. Those containers might stay up for you, one, ready to receive new requests, but you're not paying for them. And so, that is—you know, your URL redirect service is probably in that mode where yes when you haven't used it for a while, it will scale down to zero, but if you send one request to it, it will serve that request and then it will stay up for a while until it decides to scale down. But you the user only pays when you are processing these specific requests, a little bit like a Function as a Service product.Corey: Scales to zero is one of the fundamental tenets of serverless that I think that companies calling something serverless, but it always charges you per hour anyway. Yeah, that doesn't work. Storage, let's be clear, is a separate matter entirely. I'm talking about compute. Even if your workflow doesn't scale down to zero ever as a workload, that's fine, but if the workload does, you don't get to keep charging me for it.Steren: Exactly. And so, in that other mode where you decide to always have CPU allocated to your Cloud Run container instances, then you pay for the entire lifecycle of this container instances. You still benefit from the auto-scaling of Cloud Run, but you will pay for the lifecycle and in that case, the price points are lower because you pay for a longer period of time. But that's more the price model that those bigger customers will take because at their scale, they basically always receive requests, so they already to pay always, basically.Corey: I really want to thank you for taking the time to chat with me. Before you go, one last question that we'll be using as a teaser for the next episode that we record together. It seems like this is a full-time job being the product manager on Cloud Run, but no Google, contrary to popular opinion, does in fact, still support 20% projects. What's yours?Steren: So, I've been looking to work on Cloud Run since it was a prototype, and you know, for a long time, we've been iterating privately on Cloud Run, launching it, seeing it grow, seeing it adopted, it's great. It's my full-time job. But on Fridays, I still find the time to have a 20% project, which also had quite a bit of impact. And I work on some sustainability efforts for Google Cloud. And notably, we've released two things last year.The first one is that we are sharing some carbon characteristics of Google Cloud regions. So, if you have seen those small leaves in the Cloud Console next to the regions that are emitting the less carbon, that's something that I helped bring to life. And the second one, which is something quite big, is we are helping customers report and reduce their gross carbon emissions of their Google Cloud usage by providing an out of the box reporting tool called Google Cloud Carbon Footprint. So, that's something that I was able to bootstrap with a team a little bit on the side of my Cloud Run project, but I was very glad to see it launched by our CEO at the last Cloud Next Conference. And now it is a fully-funded project, so we are very glad that we are able to help our customers better meet their sustainability goals themselves.Corey: And we will be talking about it significantly on the next episode. We're giving a teaser, not telling the whole story.Steren: [laugh].Corey: I really want to thank you for being as generous with your time as you are. If people want to learn more, where can they find you?Steren: Well, if they want to learn more about Cloud Run, we talked about how simple was that name. It was obviously not simple to find this simple name, but the domain is https://cloud.run.Corey: We will also accept snark.cloud/run, I will take credit for that service, too.Steren: [laugh]. Exactly.Corey: There we are.Steren: And then, people can find me on Twitter at @steren, S-T-E-R-E-N. I'll be happy—I'm always happy to help developers get started or answer questions about Cloud Run. And, yeah, thank you for having me. As I said, you successfully deployed something in just a few minutes to Cloud Run. I would encourage the audience to—Corey: In spite of myself. I know, I'm as surprised as anyone.Steren: [laugh].Corey: The only snag I really hit was the fact that I was riding shotgun when we picked up my daughter from school and went through a dead zone. It's like, why is this thing not loading in the Google Cloud Console? Yeah, fix the cell network in my area, please.Steren: I'm impressed that you did all of that from an iPad. But yeah, to the audience give Cloud Run the try. You can really get started connecting your GitHub repository or deploy your favorite container image. And we've worked very hard to ensure that usability was here, and we know we have pretty strong usability scores. Because that was a lot of work to simplicity, and product excellence and developer experience is a lot of work to get right, and we are very proud of what we've achieved with Cloud Run and proud to see that the developer community has been very supportive and likes this product.Corey: I'm a big fan of what you've built. And well, of course, it links to all of that in the show notes. I just want to thank you again for being so generous with your time. And thanks again for building something that I think in many ways showcases the best of what Google Cloud has to offer.Steren: Thanks for the invite.Corey: We'll talk again soon. Steren Giannini is a senior product manager at Google Cloud, on Cloud Run. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice. If it's on YouTube, put the thumbs up and the subscribe buttons as well, but in the event that you hated it also include an angry comment explaining why your 20% project is being a shithead on the internet.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Syntax - Tasty Web Development Treats
Supper Club × Edge Functions and Deno with Eduardo Bouças of Netlify

Syntax - Tasty Web Development Treats

Play Episode Listen Later Jun 17, 2022 54:44 Very Popular


In this supper club episode of Syntax, Wes and Scott talk edge functions and Deno with Eduardo Bouças of Netlify. Hasura - Sponsor With Hasura, you can get a fully managed, production-ready GraphQL API as a service to help you build modern apps faster. You can get started for free in 30 seconds, or if you want to try out the Standard tier for zero cost, use the code “TryHasura” at this link: hasura.info. We've also got an amazing selection of GraphQL tutorials at hasura.io/learn. Postlight Podcast - Sponsor Postlight is a strategy, design, and engineering firm that builds platforms for some of the biggest organizations in the world. The Postlight Podcast is hosted by senior leaders Rich Ziade, Paul Ford, Gina Trapani, and Chris LoSacco. If you're looking for answers to tough leadership questions, the Postlight Podcast has you covered. Listen to new episodes every Tuesday, wherever you get your podcasts. WP Mail SMTP - Sponsor Did you know that many WordPress sites are not properly configured to send emails? With WP Mail SMTP, you can easily optimize your site to send emails, avoid the spam folder, and make sure your emails land in the inbox every time. WP Mail SMTP comes with detailed email logs, email engagement tracking, visual email reports, weekly email summaries, integrations with popular email providers like SendLayer, Gmail, Outlook, and more! Try WP Mail SMTP Pro today and get 50% off or start with their free version by downloading it from the WordPress plugin directory. Show Notes 00:36 Welcome 02:31 Who is Eduardo? EduardoBoucas.com @eduardoboucas 04:29 What is a serverless function? 06:42 What is the edge and an edge function? Edge Functions Explained Deno 08:41 Sponsor: Hasura 09:18 The internet is global, and server locations matter 17:09 Chaining multiple edge functions 20:18 Sponsor: WP Mail SMTP 21:01 Why use Deno? 24:38 What are the limitations of using Deno? 27:44 Why not run NodeJS servers on the edge? 29:34 Do you see a future where people are writing packages that work anywhere? 31:32 Sponsor: Postlight Podcast 32:25 What about databases and serverless functions? Planetscale 37:46 What language does Netlify use to write apps in? Netlify Edge Handlers 43:39 Supper Club questions Warp S Town Podcast Shameless Plugs Scott: LevelUp Tutorials Wes: Wes Bos Tutorials Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets