Remix Conf Europe

Remix Conf Europe 2022

Full Stack Components

Kent C. Dodds

React Summit Remote Edition

React Summit Remote Edition 2021

RedwoodJS: The Full-Stack React App Framework of Your Dreams

Tom Preston-Werner

Remixing Your Stack in a Monorepo Workspace

Juri Strumpflohner

How Remix and Prisma Make Frontend Devs Fullstack

Sabin Adams

Remix Architecture Patterns

Andre Landgraf

React Advanced

React Advanced Conference 2022

Killing Bugs With Kindness

Hello everyone, my name is Darshita and I'll be talking about how to reduce bugs in a React codebase by understanding antipaths. A little bit about me, I'm the maintainer of the open source project Athree Engine, which is a new full-stack web development framework. I'm also the co-founder and CEO of Athree Labs, which is the company behind this project. So using Athree framework, the front end of a website can be created by writing React code and its package in Node.js, Python, etc. There are many productivity tools baked into it, such as a visual editor that can be used to create the front end of a website to complement your React code. This is how that visual editor looks like. As you can see, there are numerous interactions on one page. For example, we can add components, style them, and move them around. And we can also see how responsive our website is by clicking on different screen sizes. So while creating this framework, for our team, it was very important to understand and characterize antipatterns in our large React codebase, because suboptimal code in one interaction can affect the entire application. Moreover, the objective of our framework is to support building production-grade websites. Consequently, building internal standards that are rigorous around code quality were very important to us. So in this talk, I will share the types of bugs we have identified in our codebase and the guardrails we have built to avoid them in future. I will cover how to prevent three types of unexpected code behaviors. First, a component does not update upon a user event. Second, the component updates partially upon a user event, since the previous state is still there. And thirdly, the component renders unexpectedly. Initially, while building our framework, we were encountering these bugs repeatedly. So our first resort was to use random print statements like a true developer. But of course, later on, we had to use, we had to create some method around it. So we used one central theme to codify hints that are easy to remember, and can lead us to identify antipatterns. And that theme comes from React's official documentation, which states that a React code should be independent of the sequence in which components will render, and when they will render. The first hint is if we are using hooks without a dependency array. We think that one way to visualize a React code is as a collection of interdependent pieces of code. Hence, if a code's dependency relationship cannot be established, then there is a high likelihood that it will result in bugs. So if we can just take one thing away from this talk, it should be this. Be as paranoid as Charmi was in this iconic Always Sunny episode, when you see or write hooks such as useState, useRef, etc, that do not take dependency arrays. Another way to avoid unnecessary useState is by using the context of the event handler to store state. Here I am demonstrating this using the custom slider component. The code on the left has antipatterns. For example, there are four useStates and three callbacks. The startPosition state records the initial position of cursor. The code on the right is its refactored version. Note that we do not have any useState and only one callback because we have used the local context of the callback to store all the ongoing information related to user interactions. When we applied this refactoring to our framework, we were able to drastically reduce the ratio of useState per component. Our current ratio of number of useState to total number of custom hooks and components stands at around 1 is to 3. To give you a context of the size of our codebase, it has around 100 custom hooks and around 200 components. The next hint for antipatterns is if you are using nesting for arranging components. Note that while using nesting, if you are not paying attention, you might pass down duplicate states to children. This may lead to inconsistencies of states between parent and children. Recall that our code should be independent of the sequence in which components will render. Moreover, there should be a single source of truth for each state, otherwise it will result in bugs. The second thing to note here is that tracing changes in state is the most time-consuming step in debugging. Since nesting allows change in state at each level, it takes longer to debug. The third hint is if you are using many uncontrolled components. We are aware that there is an active debate on the use of controlled components, but we believe that controlled components should be preferred, especially if the number of interactions per page is high. In our framework, we have been able to reduce bugs by more than 80% by using controlled components. So, to summarize, be extra careful when you are using hooks without dependencies and using nesting to arrange components. We should definitely avoid two anti-patterns. First is using props in context or as initial state. And the second is using destroy and recreate anti-pattern. As the name suggests, this anti-pattern refers to removing the component from DOM and destroying all the hooks and states created during the first function call. This is followed by creating the component again from scratch. This anti-pattern can lead to issues such as flickering effect. There are four coding patterns that we recommend our developers to prefer to reduce bugs. First is using props in JSX. Second using the context of the event handler to store state. Third, instead of trying to make useState work somehow with patchwork, switch to a hook that takes dependencies, such as useMemo. And fourth, use controlled components wherever possible. Thanks for listening. These are my social media handles. If you're interested in reading more about these anti-patterns, you can check my blog post. There I discuss these anti-patterns in more detail. I've also used an example app in the blog that demonstrates these anti-patterns. Finally, this is the link to the full stack web development framework we are building. If you're interested in contributing to our project or sharing feedback, please check it out. And if you like what we are building, please start our repository. Thank you.


Darshita Chaturvedi

Building full-stack applications on the Edge

Hi everyone. Wow, thank you all so much. So yeah, I have five minutes. So we're going to get right into it. I'm going to be talking about building full stack applications on VEdge in five minutes. Right? Okay, cool. First thing, my name is Obina. I'm a weekend filmmaker so if you see me with a camera around here, just ask for permission, of course. I'm up to a lot of things recently and you can find me on Twitter at Obina Speaks. This is a picture of me before my hair like blew up. So yeah. So yeah, you want to build an application but like how, right? Before we start to like talk about all the awesome things that are happening right now in the industry, let's take a step back and look at what like the most basic application would look like or would entail. You would have some clients, you know, some web server that like interact with each other. You had like some, you know, passing Jason around or it got more complicated as you would go to like adding services. Oh, there goes my phone. Yeah. I like that you all laugh because yeah, that's good. So yeah. Services. We have services and like all of these like connect to each other and somehow like the more you keep going, the more stuff like you have to learn and the more stuff like you have to add. And the basics of it all is that you have, you know, clients, the client view, the front end, the API, some data access layer, some database and some like error handling and stuff, right? But then it gets a bit confusing because if you're like me and you just like writing front end code and now there's like a bunch of stuff that I need to learn because everyone says it's cool and then now I have to learn something else and there's a new course and there's a new tab and there's a new tab, you're like, oh, wow. How am I going to build that startup, right? But the thing is, the line currently in this industry right now, the line between front end and back end keeps getting blurry. I had this tweet by someone that I lost but this is actually someone's 3 a.m. tweet and it made me wonder what was he doing up at 3 a.m. and why was he thinking about this thing? Maybe he's building a startup, I don't know. But this is what the line kind of looks like now. You have like front end engineers like building full stack applications which I will show you one of my top secret applications and then without having to learn how to, you know, scale a database or learn like some new stuff that they probably won't use only on a one-off project. And I like that this line now is some sort of a jump rope because we're entering into a new era of web development and we've gone from like having clearly defined roles to having people that build both front end and like both back end applications using APIs and services which brings me to the point of like the JAMstack. Has anyone heard of the JAMstack? Show of hands. Yes. My people are here. That's good. If you haven't heard of it, it's about using JavaScript and like APIs and relying on services to kind of scale. So you know, write your code, write what you can, deploy it, let someone else that has a bigger server and more employees like care about the scaling and all of that. And since we've started like using this new paradigm, we are moving into something else that's really like exciting. The edge. Yeah. I needed to play sound for that. But yeah, we have the edge, right? Which is like this really cool thing that everyone keeps asking, okay, cool. I've heard about this, but like what is the edge? So Neil had to talk about it. I will also just try to like explain it from the concept of like edge computing which exactly means that data structure, I said structure, storage is now being like brought to the place where it is also generated so that you have something cool that looks like this. So if you want to talk about the edge or try to understand it, think of like this little dot being like data centers where like I can deploy like a serverless function or an edge function now and then you would have, when I deploy this, it doesn't go to like a US East one or like some region and obviously have someone in like Singapore or like Lagos reaching for data from like a place in the US. Now it's going to be on a global network. This is just an example. Different companies have like all of these services like Fastly, Fly.io, Dino is also doing the same thing. This is just Cloudflare's data, I mean the representation of what they have as data centers. And with this improvement comes the simple fact. Everything we do as engineers in some way or the other ties into delivering high quality experiences to the customers like around the world, right? With low latency. I forgot to add this but you know my website is faster than yours so yeah. And the thing I love about this industry is that we're never really doing anything new per se. We're just like switching out some old tires for like faster ones, you know, rims that spin, you know, and that's good. So some of the things that we've improved on is moving from something like origin, moving from serverless to like originless which is what I've explained as like deploying functions on the edge, better edge caching and like all of those things and getting like database locations, being more conscious about like where you're storing stuff, where it's being used, how you're delivering it to users and all of those things, right? I have a very quick demo and I'm going to show you something. If you want to like see what the application looks like, scan this. This is my very, very, very secret project that I'm showing you. So yeah, because I mean, you all have been amazing. So if the demo gods will allow me, I'm going to show you something very simple. So I have this application that really looks like this if you're looking at it from your phones or laptops. This is what it looks like. It's just like a simple chat, you know, add some comment, leave a comment, like for a friend, all of those things. I had some of my friends test it out already. And this application is powered like with edge technology. So I have like some serverless functions which if you've ever written serverless, wait, has anyone deployed like serverless functions? Show of hands, please. Yes, okay. Thank you. Thank you so much. So yeah, you have like serverless functions basically just like JavaScript deployed on like someone else's server. But in this case, this is deployed over like data layers and data centers like around the world. So if you're in London now and maybe you deployed to Cloudflare's network, for example, there's this really cool thing on workers.cloudflare.com where you can see like the ping seconds that it would take for your functions to fire. So this function now, last time I checked, it was like nine milliseconds away from where we are. So that's pretty fast. And if someone, if I sent the same application to someone in Lagos, for example, they would get it at a different, they wouldn't have to like fetch from like data center here in London. So like that's why the edge is cool. And then I have like a very simple thing I'm doing here, which is where I store like comments in like some KV store, which is like a key value store. And you know what they don't tell you is that these lights are very hot. So I'm sweating. But yeah, so I put in, I put in like the, oh, thank you. Oh, you're so sweet. So yeah, you put in like the information, like the comments and stuff, I store that in a KV store and the way I'm using Cloudflare as a point of reference, this doesn't mean that the only people that do it, however, like you have like this key value store, like stored over different data centers. So I'm caching where it's, the data is created so that it can be retrieved closer to that, but it still replicates itself. And then I also have like these functions that deployed on the edge network as well. And if you scanned the QR code, you should be able to see like the code is on GitHub, it's open source. Feel free to leave me a comment. My TypeScript is not very good. Don't judge me. But I also have this thing here called a durable object, which is literally, if you listen to Sunil's talk, the real time like collaboration bits of what he did, you would see some use of this bit of code here. And yeah, that's like a bit of the demo I wanted to show. But wait, the final slide is the most important one. Thank you so much for listening and may the force be with you.


Obinna Ekwuno

React Summit

React Summit 2022

A Frontend Developer’s Guide to Web3

Welcome everyone to my talk, a front-end developer's guide to Web3. Really excited to be here at React Summit, talking a little bit about Web3 and giving you an introduction to it. Here's a high-level agenda of what we're going to be going through today. We're going to be talking about what smart contracts are, going over how to develop them. We're going to talk about how to connect to the blockchain, talk about things like wallets and RPC endpoints. We'll go over that in a bit, don't worry. We'll look at how to actually fetch data from the blockchain and some really dope tools that you can use to build with and dive into the Web3 rabbit hole, as I have. So a little bit about me. My name is Rahat. I'm a developer advocate at a company called Polygon. Previously I've been a front-end developer as well as a freelance Solidity engineer. Overall, I'm like an indie hacker, Web3 enthusiast. And these are just some places you can find me, Twitter, LinkedIn, GitHub, if you ever want to look at some code examples of some of the things that we talk about during this talk. And Polygon, which is the company that I work for, we're specifically going to be talking about one of our products, which is a proof of stake blockchain. One of our popular offers, this is pretty much our most popular offering. It is a carbon negative blockchain. We're striving to be completely climate positive. Uses about 99% less energy than Ethereum or other blockchains. And it's a great way to start diving into the Web3 space without having to worry as much about energy wasting and usage that comes up with a lot of the other blockchains that are out there. But going to the actual main crux of our talk, smart contracts. Smart contracts are essentially the code of the blockchain. It's just a file, contains some code, some instructions for what your app or your DAP, which is a decentralized application, needs to do when it's deployed onto the blockchain. How do we write smart contracts? What do we need to know about them? The languages that smart contracts are generally written in include Solidity, Rust, Viper, or Go. I'm going to be talking mainly about EVM chains during this talk. EVM means Ethereum Virtual Machine, meaning everything that we talk about, all of the code that we do, kind of like review and go over, are all compatible with the Ethereum blockchain. Our blockchain Polygon is also compatible with Ethereum. So anything you learn on that side of things is one-to-one compatible on Polygon. Although Solidity is generally the most popular use language, another popular one is Viper. So definitely if you ever wanted to go into smart contract development, those are some good languages to know. Now let's say you've written your smart contract, you've written some Solidity code, you want to actually get that out onto the blockchain. Development takes a few different steps. First you need bytecode. Bytecode is essentially machine-readable code that is compiled from Solidity. Solidity is a very high-level language, meaning it has the code, but it needs to be really compiled down to something that the Ethereum virtual machine can read, and that's what this bytecode is. The next thing you need to know is what gas is. Gas, not like what you would use at the pumps, but gas fees associated to blockchain developments include essentially a fee that you need to pay in order to transact with the blockchain. This fee is comprised of a base fee that may get burned. So a certain amount of coins or tokens on that blockchain might get burned during this transaction, and then a certain amount of it is given to what are called miners or validators. These are folks who have nodes or computers that essentially keep track of the blockchain, have copies of it, and are validating transactions to be added to the overall blockchain. Next you need a deployment script. A deployment script can be taken from environments like Hardhat and Truffle, both of which are tools for creating environments for deploying, testing, and essentially creating your smart contracts on your local machine. Finally you need an Ethereum node. So Ethereum nodes is just basically a computer that has a copy of the Ethereum blockchain on it. Think of the Ethereum blockchain as this gigantic database, and the node essentially houses a lot of all of the information that is on that blockchain, and you have everything on what's called a distributed network. So there's nodes and computers all over the world keeping track, validating transactions, and they together form the consensus of what the blockchain data is. Polygon works very similarly in this case. We have several nodes all across the world, and rather than using folks like miners who mine these transactions, we have validators who validate it. Next there are services like Alchemy and Infera, which can help you with actually accessing an Ethereum node. Not everyone can run their own Ethereum node or Polygon node on their own computers. These services are essentially providing you with endpoints, or RPC, or what's called a remote procedure call endpoints, that allow you to interact with Ethereum, that allow you to interact with Polygon as well. Finally let's talk about interactions. So interactions usually happen with a wallet. Wallets are usually inside of your browser. So I'm going to show you right now what's called a MetaMask wallet, which is an in-browser wallet. I have a little bit of Ethan here, but I can switch between different networks. I'm going to switch to the Polygon testnet just to showcase, this is the Polygon network. You can have access to different blockchains via this wallet. The wallets all interact using an RPC endpoint, so they have their own built-in endpoint from services like Infera and Alchemy. But for now let's go ahead and break down what some of these interactions are. So I showed you a little bit about wallets, which is that MetaMask wallet I popped up here. And what wallets really do is ask for user consent for actually accessing their wallet and connecting to the blockchain. Many of the different interactions that you need to do require sometimes some type of transaction fee. Usually this is some type of mutation that needs to be done on the blockchain, or sometimes there's a signature required from you to prove your identity, to prove that you're the one using your wallet. This is all done through a wallet like MetaMask or through hardware wallets like the one you see here from Ledger. These are great for when users need to conduct transactions like minting or buying an NFT, transferring tokens, anything that requires interaction between you and the blockchain or you and some other folks who are using Web3 applications. The other type of interaction is just like a read-only type of interaction. So RPC endpoints, like we mentioned before, these are endpoints given to us by a node provider. These are great for dApps that only have read transactions like a block explorer. Block explorers will give you essentially a UI that acts as a full ledger for looking through transactions, for looking through the history of those transactions, for looking through any failed transactions that you might have. So when you're trying to figure out what's going on, what's debugging certain calls in your application, you can look at block explorers to see, okay, so what happened during this call? Why was it rejected? Why didn't it go through? These are great for debugging. So let's look at some code and take a look at how do we actually interact with the blockchain wallet edition. On my screen, I have a JavaScript function called handle wallet connect. This would generally be attached to something like a button. So this is an async function. And what I'm doing here is taking the Ethereum object out of the window. Now you might be like, whoa, Rahat, what do you mean, Ethereum object in the window? So the reason I'm able to pull out an Ethereum object from the window is because I'm considering that this person might have a MetaMask wallet like I have set up right here. As long as you have a browser injected wallet like that, that wallet will also inject the Ethereum object into your window. And then from there, just a couple of little bit of boilerplate of like accessing the account associated to that wallet, and then accessing the address and logging that out. If the Ethereum object doesn't exist, we'll just alert that, hey, there's no wallet detected. The person should go and install MetaMask or something like that. And you can provide a better alert than I did. So here's a quick demo on how that works. So on this page, I have this connect wallet button. I hit it. And once that happens, my MetaMask pops up. I hit sign in, and it displays my address on the page. This is essentially half of what you would use for something like sign in with Ethereum, which I'll cover in just a little bit as well. Now I'm going to talk about another common connect wallet pattern. This is done quite a bit through a lot of decentralized applications where we take that handle wallet connect function. I didn't bother rewriting it here and put it inside of a use effect and call it right away, specifically like unmounting of the actual application. Please do not do this if you ever dive into the Web3 space. What this essentially does is as soon as I land on the website, the website will automatically request that I connect my wallet. This is sort of like the same kind of situation of you going to a website, music starts playing, or a video automatically starts playing. Nobody wants to actually have that happen right away. This is a bad security practice and is something that just leads to bad UX overall in your application because it removes the ability for the user to give consent. One of the main things we talked about with wallets is that this is the gateway for a user to consent to using the blockchain, to doing certain transactions. This removes that ability. And some folks might say, you can still cancel the transaction, but no, you've got to stop because if your wallet immediately pops up, you don't have that opportunity to actually go through the application and understand what's going on. So I mentioned this a little bit, just a couple of slides ago, going beyond ConnectWallet and using something called Sign-in with Ethereum. One of my favorite things that have come up sort of like out of the Web3 space is this sort of like true single sign-on experience where you can take a wallet, connect it, validate your address as we kind of looked at before. And then from there, do something like connecting to a server as you would normally do for like authentication for actually pulling someone in, creating a user profile for them on your DAP or application. And the cool thing here is like that user profile can travel with them anywhere. They don't need to create a new email or password every single time they go to a new application. They don't need to trust their credentials to a service like Sign-in with Google or Sign-in with Facebook. Everything is actually specifically owned by them. That user profile is owned by them through this wallet. And the way that wallet works is that like the wallet gives you access through a key value pair, a public address and a private address. The public address is the one we displayed on the page. And then there's a private address that only they have access to that actually allows them access to the blockchain and is what allows them to approve transactions, view their holdings, and just access the overall Web3 space. So we talked about the wallet side of things of doing interactions of like actual user interactions, but how do we interact with the blockchain RPC endpoint edition? In this case, we may only want to do read-only transactions. Maybe we want to create our own block explorer. Maybe we want to just display some data in the form of graphs, dashboards, whatever it is. On here I have this provider and this provider is something given to us from the ethers package, which is a popular JavaScript package you can use in your front ends. And all you really have to do is just like use this method and enter an RPC endpoint. These RPC endpoints are basically just like a URL, an HTTP endpoint given to you like the services I mentioned earlier from Alchemy and Infura. And this is like a blob of information that you can actually get from the RPC endpoint. So here what I'm doing is I'm getting the information about the latest block on the blockchain. And what does that mean? What is the latest block? So blockchain data is broken up into these blocks. They all have some type of number associated to them, a timestamp, different hashed values. And this is what houses all of the data on this block. So on this specific block, there's several transactions. There's only one displaying here. This is a timestamp and just some information about like the miner who actually validated this as well as just like additional data like the gas that was used. And this is sort of like the information you can use to build out some of those dashboards, some of that information. I'm going to give you a quick demo of something that I built using that blob of data. This is just like a list of like the last 10 blocks on the Polygon blockchain, including their block number, their timestamp, and the number of transactions on each of those blocks. You can dive a little bit deeper into that JSON data that's returned from some of these calls, but this is just like a very basic implementation of like what a block explorer might start off as. So cool. But how do we actually fetch data from smart contracts, right? Sure, maybe there's like someone wrote some like developer, smart contract developer wrote a contract for us and that houses some information. How do we access that information? We need a map. So Solidity code, like I mentioned before, gets compiled down to bytecode. We need instructions on how to actually traverse that bytecode. So what we need is an ABI or an application binary interface. This is usually exported out by a Solidity developer, passed on to like a front end developer. And this is just a JSON object with instructions on like the different types of functions that are available on a smart contract, what input some of those functions need and the types of outputs that they give to you. This is just going to allow you, allow JavaScript to use certain libraries to traverse through the blockchain and get the proper information that it needs. So rather than doing an HTTP request, it's using this ABI along with a function given to us from a package like ethers to actually interact with the blockchain itself. So how does this work? First, you would import dependencies. This is done in like assuming you're looking at a React application. So you're going to import like ethers from the ethers library and an ABI that some smart contract developer may have given you. This is an example from a contract that I wrote where it showcases like a little Pokemon battle between two Pokemon. The next thing is that you want the address of the deployed contract. So every single deployed contract similar to your wallet has its own address. So we need to get the address to see where on the blockchain that contract lives. We supply the ABI, the address of the contract as well as the Ethereum object into this contract method given to us from ethers. Once we supply it all that, we then get access to the actual functions listed out inside of the ABI file. One of those functions here is this attack functionality where our Pokemon is going to attack each other and then certain amounts of like HP or hit points are going to be taken away. So let's take a look at that in action. So what's going on here is I decided, okay, I need to attack this Pokemon. I hit use flamethrower. My MetaMask is going to pop up. I'm going to pay a small amount of gas to make sure this transaction goes through on the blockchain. And once it's completed, all of the hit points of the two Pokemon will go down and all of this is tracked on the blockchain itself. So the main things to really understand here, front end development in web3 remains the same. The UI is still built using all of the same practices. You don't, as a front end developer, you don't need to know the deep sort of like intricacies of how to build your own smart contracts. You just need to know how to interact with them. Like we talked about, you go from a shift in mindset from doing HTTP requests to using ABI code and libraries to call the smart contract. And the other main thing to remember is that mutations cost money. Read transactions are free. Mutations will always cost money. Some web3 front end development tools that you can definitely dive into and learn more about are the ethers and web3 library, as well as the Wagme library. Wagme library provides a lot of react hooks for easily hooking into and transacting with the blockchain. Web3 UI is an awesome library that gives you a bunch of react components that you can use as well. And different block explorers like polygon scan, if you're interacting with a smart contract on the polygon network or ether scan, if you're interacting with a smart contract on the Ethereum network. These are all tools that I'm going to be touching on as well during my workshop here at react summit. So if you want to learn more about that, we'll be going into greater detail there. And overall, if you feel like you want to learn more, you want to check out how to build on the blockchain, how to build on polygon. We do have a lot of resources on academy.polygon technology. There's a lot of like gamified approaches there of like learning and building your own dApps. I also wanted to quickly call out polygon village. If you decide to like go in and learn about web3, learn about how to develop in it and start developing your own projects, we do give grants, which are no strings attached grants for actually building out your projects. And eventually, if you wanted to go into the web3 ecosystem, we do have an ecosystem job board for that as well. So this is not just for polygon jobs, but for overall folks in the polygon ecosystem. So just to wrap up, I'm Rahat, again, developer advocate at polygon. These are just a few places you can find me. Really awesome to have you all dive into a little bit of web3 with me. And really excited to see you all possibly in my workshop as well. Thank you.


Rahat Chowdhury

Full-stack JS today: Fastify, GraphQL and React

Cody Zuschlag

Design-Driven Full-stack: an End-to-End Dev Workflow that Scales

David S. Price

Node Congress

Node Congress 2022

A Glimpse Into the Future of Fullstack Development with Blitz.js

Aleksandra Sikora

GraphQL Galaxy

GraphQL Galaxy 2021

When (Not) To Create A GraphQL Server

Hello everyone, my name is Roy and welcome to my talk, when not to create a GraphQL server. So who's this for? So it's very easy to build a GraphQL server, but it's really hard to make a GraphQL server that's scalable. So scalability will sometimes kick you in the ass whenever you start writing a GraphQL server. So there are many libraries to build a GraphQL API and there are many different patterns to build a GraphQL API and we'll be exploring them all in this talk. We'll also be showing a way to create a GraphQL server automatically based on your existing backends. A little bit about myself. So my name is Roy. I'm a software engineer and public speaker. You can find me on Twitter with the handle at gethackteam and I wrote a lot of books, definitely about React and also GraphQL. The latest one is Full Stack GraphQL. So before diving into how to build a GraphQL server, also let's have a look at why you want to build a GraphQL server in the beginning. So there are many reasons to build a GraphQL server and I think the very first one is to optimize a client request. So you have a client, it's consuming an API, but somehow your REST API or maybe different sort of API calls aren't that efficient. You want to have that efficiency and you also want to give some autonomy to the user. So GraphQL isn't only there to solve the M plus one problem where you might be over or under fetching too many GraphQL, too many REST endpoints, but instead GraphQL also gives autonomy to the user. So as a client, you have more control about the types, about the data that's flowing into your application. But optimizing client requests isn't the only way or the only reason to create a GraphQL server. It could also be to wrap your microservices. So GraphQL is perfectly fine to bring together multiple microservices that can be GraphQL microservices, but also microservices built with something else. And it's also very good in wrapping legacy services with that GraphQL data lane. So there are multiple reasons to build a GraphQL server and these are three perfectly fine reasons to build one. But there are multiple ways to create a GraphQL server. So as I mentioned in the beginning, there is no correct way. There are many different ways and many different patterns and libraries to help you with it. So the first pattern we have here is a code-first GraphQL server. So with a code-first GraphQL server, you always start by writing resolvers. And these resolvers, they usually use classes or if you're using TypeScript, you'll probably use a TypeScript type system in order to define the result returns of these resolvers. And based on that result, a code-first GraphQL server will generate its schema based on the resolvers. And then of course, create a server for you. And it has one major downside. It has an upside. You can do everything programmatically, but the downside, it's very hard to have a separation of concern. So there literally is no separation of concern because your schema gets created from the resolvers and resolvers is the only code to write. So you don't have any control about how the schema actually will look like in the end. So there was a solution for this, which is SDL-first GraphQL server, also known as schema-first GraphQL server. So the idea here is that you write your schema. You can either do it in GraphQL SDL, hence the SDL-first server, or you can do it with some external libraries. So there is the GraphQL.js library, which lets you write schema-first GraphQL servers, but not using SDL, but using their own methods instead. But the idea is simple. You create your schema, you create your resolvers based on this schema, and this will create a server for you. So you have a very nice separation of concern. You have your schema separated from your resolvers, and you're in full control of everything. But this, of course, has the major downside that writing both resolvers and schemas is a lot of work. So luckily, there's a solution. You can also create your GraphQL API automatically from a schema. And this can be done with StepZen, an example. So let's have a look about how this works. So creating a GraphQL API with StepZen is very straightforward. You just write your schema. You can define all the types that you have, and these types will be linked to a data source they're coming from. And this can be any backend, as we'll see later on. And RCLI will then generate resolvers and the server automatically for you right in the cloud. So it will be deployed serverless. You don't have to worry about any deployments or about scalability of your resolvers. So StepZen, you can connect any data source. So it can be databases, either SQL or Postgres. It can be REST APIs. It can be GraphQL APIs. You can literally connect any other data source. And then based on this data source, a fully performance serverless GraphQL API will be created for you. So no longer do you have to worry about scalability, about performance, about deployments. It will all be done for you. And this uses just GraphQL schema design language. And here are two examples for MySQL Postgres on the left and REST on the right. As you can see, it's using custom directives in order to link to data source. So right from in your schema, using just GraphQL schema design language, you can create connections with any backend or any data source. And next to Postgres and REST, you can also use any other GraphQL API as your data source, as we'll see in this example. So what we have here is a schema. And in the schema, we'll be linking the data sources for you. As you can see, we can just run StepZen Start. It will automatically create a server for us. So it's deploying to StepZen, which will mean it will be deployed in the cloud, and then an endpoint becomes available. And then, of course, we can also add more types here like a language. And this language can be linked to the country. So a country can have a language. For this, we'll be using another custom directive, and we'll link it to an existing query. So to get country language, we'll also be a REST API call that connects the information for a country. And then as soon as we start saving this, it will automatically be redeployed again. So you will always have the latest version of your schema on StepZen. You can also do this with third-party or SaaS APIs. So quite recently, we launched a new product called StepZen GraphQL Studio. So you can find it on graphql.stepzen.com. And this is an interactive IDE right in your browser where you can play with third-party APIs such as Dev.to, GitHub, or Twitter. You can link them all together either separately or by finding some combinations we made for you. And directly from the browser, you can create your own API by selecting some schemas, running some queries, and also deploy it on the cloud. So if you would scan this QR code or to go to graphql.stepzen.com, you can already find this right there for you. So that's mostly it. We had a short time to cover everything. My name was Roy. You can find me on Twitter using adcathackteam. You can find StepZen on stepzen.com. And you can also find our product, GraphQL Studio, on graphql.stepzen.com. Thank you, and I hope to see you around.


Roy Derks

Vue.js Live Conference

Vue.js London Live 2021

Vue Storefront + Vendure = Fullstack Open Source Ecommerce

Hi VGNs London. Let's talk about full stack open source e-commerce, shall we? My name is Jakub and I am a technology leader at Vue Storefront. I am also a core team member of Storefront UI, which is a UI library for e-commerce, and I'm also a core maintainer of Vue Storefront and Venger integration. Apart from work, I'm also a technical diver and currently doing a cave dive course, and I'm also a mountain hiker, and in the second picture there is me on the top of Volcano Teide de Tenerife, which was actually our Vue Storefront location this year. And yes, we are hiking. Now let me tell you a short story. In August this year I set myself a long-term and ambitious goal. I told myself next year I would like to join Filip Rakowski, who is Vue Storefront CTO, in one of the greatest Vue.js conferences and give a speech. So right now in two months I'm here giving a speech instead of next year, so everything is possible guys. Just make this first step. Have you ever wondered what it's like to build an e-commerce store from scratch? Handling all these orders, products, categories takes time, and time is the resource that you may not have as someone who wants to be a market leader. And what if I told you that there are all these solutions on the market that you can just pick and play in minutes or hours instead of waiting for the developers to develop the solution from scratch, which would basically take weeks or months? And what if I told you that these tools are free, open source, and backed by the huge community of contributors that are doing their best to make the project as good as possible? So I want to present to you something what I'm calling a dream stack for open source e-commerce, which is Vue Storefront and Venger. Vue Storefront is a lightning-fast front-end platform for headless commerce. But what exactly is headless commerce? If you have been playing some computer games in the recent years, you might probably know this character. This is a character from the game Team Fortress 2 and his name is Headless Horseless Horseman. And why am I bringing this example as a comparison to headless commerce? So Headless Horseless Horseman was a very powerful character and so is headless commerce. But in more details, what is headless commerce? So headless commerce basically means that you are separating your front-end or the UI part of your e-commerce store from the back-end. And it allows even mature businesses to have flexibility and maneuverability of a startup. So it basically means that, for example, Vue Storefront can connect to many different e-commerce platforms, headless CMSs, payment gateways, search engines, and many, many more third-party services. And what about technology stack? So basically Vue Storefront is built using three main tools. NaxxJS, which is a framework for Vue.js. We are using also TypeScript and GraphQL, but Vue Storefront works with REST API as well. Some basic concepts of Vue Storefront. Vue Storefront uses concept of composables, which are used to map certain functionality of your e-commerce or map certain domain of your e-commerce. So in this case, we will be taking a look at product domain. Each composable will contain from four main functions or four main elements. The first one will be a variable, in this case products. This products variable will contain a value of your product domain. Next, we'll have a search method or the load method that will be used to fetch the data from your e-commerce platform to Vue Storefront. Composables might have several methods, like for example, use product or use address. Might have add address, remove address, update address, get address. So it might have more than one method, but it must have at least one method which will be used to fetch the data. Next, we have an error object, which will be used to each property of this error object will be mapped to the certain methods that this composable has. So in this particular case of the use product composable, error object will contain only one property, which will be named search. And it will contain an error that might occur in a situation where you are fetching the data from your e-commerce platform. Last but not least, we have the loading property, which will be used to indicate whether we are still waiting for the data to be fetched from your e-commerce platform. This was some basic concepts. Now into customizability. Let's take another look at the use product composable. We have a search method that is used to fetch this certain product by ID. This will result in a object that will contain our product data. However, what if we would like to have a different object or a different structure or different properties? For this particular case, we could use a concept of custom queries. These custom queries will be used to override the default query that we are sending to the e-commerce platform. And how does it work in more details? In middleware.config.js, which is basically the main configuration file for Vue Storefront, we could define in an object of custom queries, we could define these custom queries, which are basically, for example, GraphQL, queries. Apart from custom queries, we can also customize Vue Storefront or our shop built using Vue Storefront by using extensions. So instead of just customizing the certain query, we can extend the API methods that are used to fetch the data or modify the data. We can extend the app itself and also the lifecycle hooks of the whole application. So as Adam Jarr and Greg Pollack used to say, let's review. So Vue Storefront is built using modern technology stack. Vue Storefront can connect to various external services and provides full e-commerce functionality. It's highly customizable, as I explained previously. Yeah, and going next into Venger. So Venger is also related to headless commerce, but in this case, it is a framework for, let's say, the backend stuff, backend part of your e-commerce. If you'd like to get more into what is Venger and how it connects to Vue Storefront, we have recently recorded an interview with Michael Bromley, who is a founder of Venger. And yeah, you can listen more about what is Vue Storefront, what is Venger, how they connect together, and what are the plans for the future releases. So Venger supports many functionalities out of the box. So we have inventory management, we have commerce, like checkouts, promotions. We have multiple languages, currencies, taxes, and sales channels. Venger is also scalable, so cloud-ready and auto-scalable. We have some media management, so image cropping, cloud storage support. And we have some team support for role-based permissions and admin UI. So technology stack. Venger is built using NestJS, which is a framework for Node.js and Express. It is also built using TypeScript, and it's built using GraphQL, and it also comes with the Elasticsearch support and the database of your choice. Some basic concept of Venger. So how Venger really works. So we have two GraphQL APIs. We have the admin API and the shop API. Shop API is used mainly for your shop operations, like fetching the data about products, collections, users, and customers. And admin API will be used for more advanced stuff, like managing roles, managing products, and so on and so on. So if you are requesting the data from GraphQL API, it will go to Venger server, which will start a queue. And this queue will create a worker, which will then access the database and return the data to Venger server. And this Venger server will return data to your GraphQL API. So we have an admin dashboard that is built using Venger. And we have a custom query. So we have an admin dashboard that is available for you, where you can add products, add collections, modify users, and so on and so on. And we also have the GraphQL API, which allows you to fetch the data to your storefront. In terms of customizability, Venger supports similar pattern as your storefront, because in terms of Venger, instead of custom queries, we have custom fields, which allows us to extend the default structure of the domains or the entities in our database. So in this case, we have a product, which we want to extend so that it will contain a new property, which will be named info URL. And it will be type of string. So next, what we can do is we can fire a or create a mutation in our GraphQL, where we will update the product with a new property info URL. So thanks to that, we don't have to create a new entity, we are just extending the default one. We can also customize the order flow, which allows us to not use the default one. But let's say we want to have a step between the adding items and arranging payment. So the default one is adding items, we will move to arranging payment. Adding items means that we are visiting the store and just, for example, adding products to our cart. And the arranging payment, which will mean that we are arranging some payment data and proceeding to checkout. So let's say that before arranging payment, we would like to have a step where we will be validating the customer. How we can do that? First of all, what we will do in the transition, we will create a new process. This process will contain a, it will be an object that will have some properties that in the big picture, what they will do is they will allow us to create a new flow. So we will add the validating customer and we will also modify the existing adding items, which will allow us to move to the step from adding items instead of going to arranging payment. And then in the validating customer, we will say that from this step, we can move backward to adding items or forward to arranging payment. And then we can just register this new process in venture config. As simple as that. Venture also supports plugins, which allows you to extend the default functionality. So we have core plugins, which is the admin UI that you have seen previously, the elasticsearch support, the email support, and also the asset server, which are provided by default. Next, we have the enterprise plugins that will be coming soon. And this is advanced search, gift card, wishlist, and so on and so on. And we also have the community plugins, which allows for Stripe, Braintree, so payment gateways, reviews, social auth with Auth0, for example. So let's review once again. Venture is built using modern technology stack. It can connect to various external services using plugins, provides full e-commerce functionality, and is highly customizable. So you might be thinking, there is some similar pattern here, and you are completely right. So both tools are built using modern frameworks like Next.js and Nest.js. They are customizable by default using custom queries and custom fields. They provide full e-commerce functionality, and they are configured to integrate with external tools and services, so payment gateways, headless CMSs, and so on. And they are open source and backed with a huge community of contributors. So I would say that this Fustralfan and Venture actually sounds and looks like full stack open source e-commerce dream. And let me show to you how it works. So basically, what we are doing here is we are creating an online store from scratch with Venture. So we are setting up a project, defining some database, a language, mailing provider, and we are also creating a new store with Fustralfont and setting a template to Venture. Next, what we are doing is installing dependencies as always and setting some environment variables in order for the store to work as expected. So here, GraphQL API and the method for authentication, and we also have to add this method to the Venture config. So two simple steps that allows us to run our store. So let's wait a second for that. Okay, we have a Venture store running, and we have a Vue store also running. So we can scroll down to listing, add some products, define some configuration, modify the quantity of the products, add some customer data to our checkout, set up some shipping data, as well as shipping method, some billing, in this case is the same, payment, and make an order. So let's go ahead and run our store. So we have a new store, we have a new customer, in this case is the same, payment, and make an order, and that's it. So in less than one and a half minute, you have a online store set up and ready to accept some orders and to play around. So if you like what you see, make sure to give a star to both Fustralfont and Venture projects, because they are open source and this is how they, let's say, live, thanks to these stars. So make sure to give a star to them. And also if you'd like to contribute, make sure to visit Slack channel of Venture or Discord channel of Fustralfont. And that will be it. Thank you very much for your attention and make sure to contact me on GitHub using the Paroshen handle or on Twitter Andrzejewski handle. See you.


#fullstack