The Challenges of Scaling Blockchain API's - Panel

all right hello start everyone's mic work yes i think so awesome okay well i'm super stoked uh for this panel because it really gets to uh the core of web3 by objectively discussing its its infrastructure specifically apis and and the challenges of building them and and scaling them and here to discuss that are are the people building them uh so we have nader on the end who is one of the most friendly approachable informative devrels in web3 right now working at edge and node which is the team building the graph um for anyone who isn't aware the graph really sits at the the center of the web 3 stack as a decentralized data layer nader will tell us more about that later really implore everyone to check out the project and and see how you can get involved uh we have eg galano here on my right who is the co-founder and chief infrastructure engineer at infura the the pioneers of apis to connect builders to to ethereum as well as ipfs eg is a deeply compassionate leader this morning he was helping set up the infuria booth he is also a leader that's extremely customer-centric and i think that that's very evident as uh over 400 000 builders use in in fiera today so how many people show of hands use inferior tools okay i see a few that's great so you can you can thank eg later for those um and lastly we have uh tamak weber so he's he's hailing from from sweden has come a long way to be with us and um he's a newcomer to web3 he is the ceo and co-founder of gateway fm founded just last year so they've been up and running about eight months uh they have a multi-chain api cloud-based solution so you know new to the space but already bringing such meaningful solutions uh which is certainly inspiring for any of the emerging projects attending uh or that are here today and and also for all those web two outliers uh who haven't quite made the switch um and i'm clarissa i i'm a technical writer consensus so um i think yeah yeah yeah so intros are done let's get right to the the challenges and then we'll get to some solutions and then i would love to open open up the floor for your questions so uh step up to the mic when when the time is ready um eg so i want to start with you you were one of the first to build an api solution for ethereum launching inferior in 2016 what are the most common barriers um you have seen to scalability over the past six six years keeping in mind that you know fear is a partially free service yeah so there's there's the traditional scaling issues which is just you never you can't project the growth you can't project traffic uh typically when you're building a project you're aware like you know say you're building a game you're going to launch the game in in may or something and you can start to prepare when when you're an infrastructure provider you don't have the ability to prepare you don't know your your customers aren't really telling you when they expect to put out say a commercial that's going to launch during the super bowl or anything that's going to put this orders of magnitude of growth on what your standard traffic pattern is so you have to be prepared for that you can't you can't really capacity plan you have to make sure that you're architecting systems that can scale almost limitlessly and aside from that there's also some operational things as well when it comes to network upgrades in particular okay great that's that's a great great summary um i'm sure many of you have experienced those challenges um later i'm gonna pass it to you because you're building a very unique type of api um a sub graph so if you could tell us about sub graphs their functions and and maybe get into some of the challenges you've seen indexers have to scale them on on the graph network yeah i mean um so thank you for the introduction um subgraphs are essentially just apis that run on the graph protocol and the graph protocol is an indexing and querying protocol for developers and applications to be able to build more robust applications on top of blockchain data so when you think of a traditional database like a relational database or a nosql database these databases are optimized for both read and read and write operations whereas blockchains do not have data that's easily able to be read so most applications need functionality like full text search relational data sorting filtering things like that but you can't really get that by querying a blockchain directly through through an rpc endpoint so subgraphs allow developers to model their data in a graphql schema deploy their api to the decentralized network and you're now given kind of the functionality that you would expect out of like a traditional database with all the robust functionality that you would kind of need for a modern app cool okay cool save your questions about the graph for for later on um and now uh tamak so gateway fm is a a multi-chain solution and you guys from what i understand specifically have an api for l2s so and this morning eg you said faster chains grow faster about our about our l2s um so kind of like foreshadowing some of the unique challenges that they may face um can you can you speak to to those what have you seen in offering uh an l2 api yeah so i think there are two parts as soon as you go multi-chain one of the biggest issues that you have is really understanding how those chains work in comparison to what exists today already so it's almost like getting to grew up with a new kid it takes time to really understand how the notes work understanding how the api's method interact and actually one of the biggest issues that we we have with new new chains is actually the disk space a lot of documentation is not there one of the reasons that we the way that we're building things is not your traditional decentralized we call it more you could say distributed we go bare metal that has some good opportunities but at the same time some big challenges which i always say is you need to have very very specific hardware requirements and a lot of the documentation out there is not really ready so the time that you have to spend in order to build those notes it's quite extensive so after a lot of spend our time spent on that we decided to go back to aws do the testing there really get the configurations and then go back to bare metal uh that's a little bit what we see with all these new chains the way that you need to build them are separate from each other a lot of new chains are either evm compatible so they'll have a lot of similarities but we're trying to go for the more more complex ones because we see that there's more rpc needs at the end of the day and then you have to spend a lot more time on all the methods really testing it battle testing that because they haven't been out there for so long so we spend a lot of time on the testing period part just to make sure that we have a good service when it comes to the l2 we're very specific on ck roll-ups we think that the locking period there for specific segments like wallets is going to be quite intrinsical and i would say for there the biggest issue right now is still very centralized we know that this year they'll be more decentralized but that's a point of failure and also the calls are a bit complex because you're not really debugging it too much i'll say just in general those are kind of the discoveries that we had in this short period of time thank you okay so um i guess we're moving through this a little bit faster than i anticipated um but you know we're all here to to build and it's the spirit of the event and and kind of web 3 at large so i want to open up now with a pretty general question you know what what advice do you have for the builders uh with us today and and you know watching at home um what advice can you give them you know to scale their own apis and and even you know selecting a service um i work with a lot of developers and i'm kind of new to the web3 space i've been a software engineer for about nine years and i've only been in the web 3 space for about one year and i think one thing that i see a lot of times uh in this space is that there's so many options for developers to build on and a lot of the incentives that are kind of built into these protocols with tokens um make people go out there and kind of like show the thing that they're you know wanting to go up as opposed to the right tool for the right job so i think like as a developer kind of really understanding the ecosystem and where everything fits in and knowing that the the right tool for the right job exists and like when and where to use that is really important and not just like sticking to one thing that you think is going to do everything but instead like understand like where the graph might fit in or where ipfs or where or we might fit in and kind of use it and the only way to do that is to kind of do some research and do some reading and understand kind of the web3 stack or the web through ecosystem yeah i mean that one's for for for everyone to answer so uh tamak if you want to go next yeah sure so i think one of one of the main things that we see i mean there's a lot of development happening both in ethereum and a lot of these new l1 chains i think everybody's trying to tackle the same problem which is scalability it's not a single kpi it's a multi-layer kpi so to actually increase the the actual apis it's not just like okay i'm just going to scale the infrastructure and everything's going to be okay one of the main major issues that we see it's actually creating a good operational support system to actually understand what the problems and react them in a good way or in a fast way and some of the things that we do is actually we built this from the ground up through cicd which allows us to do you know between five to ten software deliveries per day we then automatically test it and then deploy in production within a couple hours that gives a lot better opportunity for developers to come and test and you know if they have problems we're able to react pretty fast i think today one of the biggest pain points is if you have a new developer they come and they interact with the rpc it doesn't work they have to discover whether they need to go and get the information it could be a discord channel it could be a telegram channel they get a bit lost and it's a bit difficult but i would say it's a very exciting space and they should not give up we're the infrastructure is a key key space for the future web3 that's why we're here uh let's see so the question the question i mean yeah yeah like so you know what what's your advice to the builders in the audience um and and watching from home um to scale their own apis or even to you know to choose choose a service what are the the key things they should be thinking about so uh one of the things that i've been seeing as people are starting to build more nft applications on top of um ethereum and other evm compatible blockchains is that they want to get to market quickly and and they're picking a solution that that's immediately available that solves their problem and that that works that works fine um to get your product out to market but uh take a close look at the technologies that you're using and make sure that there's something like an api continuity plan what is this api going to be something that will continue servicing your users for many years in its current form is your application and the api that you're using whether it's something you're building yourself or something that that you're using from from us or or another api provider is it something that's going to change underneath your application um that that's one of the things that that's affected me as somebody that um has used some things in the nft space where maybe the the content disappeared because it was no longer hosted somewhere or the company that that put out the product pivoted into a different direction and it's not that your assets on the blockchain weren't accessible anymore but it was either a lot more difficult to access or you had to go through a significant amount of technical steps to migrate your content from from one space into another so that you can have it in perpetuity so what as you're designing try to keep in mind that you know our our customers our users the ecosystem the people that are going to be consuming this content are going into it without understanding everything that that holds it up and let's try to build that stuff responsibly that's very very well said great advice guys so on that note um why did each of you decide to build apis for web3 or what what brought you into the space that's for everyone okay yeah this was a pretty easy decision for me um before i joined the graph i was working at aws and aws was really compelling to me because it was like a developer platform and i really enjoyed being able to kind of work on the tools that other people kind of are kind of using as primitives to build out their own applications so when i started diving into the web3 ecosystem there was a handful of protocols that were kind of interesting for me to like work with and um while i do find nfts and define stuff like that pretty interesting i really enjoy working on developer tooling and developer protocols and stuff like that so um you know the graph fits directly kind of in the into that you know as a layer for developers to kind of like build out web3 applications just made a lot of sense for me i was also checking out a couple of other layer 1 protocols stuff like uh in addition to that or weave ipfs all these teams you know protocol labs and stuff seemed really interesting to me but the graph as kind of like a crucial part of the web3 stack seemed really interesting to me so i wanted to work with them and i also knew graphql because i was working on a graphql service at aws for a little over three years and the graph uses graphql so that's kind of how it happened cool very cool yeah so one of the reasons why i decided to go into infrastructure uh before starting my own company i was working at opera browser uh we built a non-custodial crypto crypto wallet inside the browser first time one of the first things we decided to do go multi-chain and there we actually really realized that how difficult it was to actually connect understand how to set up the notes interact with it and as we expanded more chains it just became a pretty big nightmare we understood pretty quickly that you know if you want to develop decentralized applications on top that's the first kind of pain point that you have and to really have a good ecosystem on this layer of decentralized apps you need to be able to have a very strong infrastructure i mean the reality if you move away from ethereum it's been battle tested for many years you see a lot of the higher level apis better tooling for developers really coming out which is great to see but i think a lot of these new l1s have you know they're trying to battle everything at the same time and it becomes a bit complicated for a new developer coming in i have a cause we need developers almost on a daily basis asking hey guys i have this problem how can we help you know they're not going directly to the at once we actually want the things that we spend a lot of time is really working closely with the l1 foundations to really understand what is the world map what's happening what kind of area focus do they have because i think also what you see again everybody's about scalability and you know having additional segments and really finding out what is their niche and i think a lot of the new albums need to find that space right and how to provide the development tools so yeah i believe in web3 and that's one of the reasons you know i got into the infrastructure because that's where it all begins without a very strong infrastructure anything on top is just going to be painful and we're just at the beginning so that's my story eg can you tell us your story yeah um i've always kind of worked in developer tools or very very close to like the developer focused applications and it was in 2015 that a friend of mine introduced me to ethereum he said have you heard about bitcoin i said of course i've heard about bitcoin i said well what about ethereum and i said no i haven't and i said well you should really take a look at it they've got the smart contract thing it could be really cool and um i i i i know this guy joe lubin i could introduce you to him like who's this guy joe um and he introduced me to joe and uh joe told me about what what they were doing at consensus where consensus was supposed to be this place where you you were just supposed to further the growth of ethereum build build a project that was for ethereum whether it was a smart contract application or tools it was like get funded to work on ethereum and that was like a pretty open and exciting concept and um so i joined with with no no specific idea in mind other than wanting to start to understand the problem space so i met with some other people within consensus some people were working on decentralized identity honestly i didn't know what it was at the time and or putting music rights on the blockchain and and really other really interesting ideas and nothing really clicked until uh i met somebody that said uh one of our co-founders said you know everybody that we run into in this space is super talented and extremely smart and they're all having issues running their infrastructure and coming from an infrastructure back in them that immediately clicked and i i i really felt like that was a place where i could immediately contribute and uh help further the growth of the space and provide value and it was very clear that it was a need that there was like latent demand for something like inferior and so we built it yeah and you know infuria supports like the graph and and soon-to-be gateway fm so many crucial projects so what are some of the the the projects that you've powered um you know what what are some of the the most interesting use cases that that you've seen emerge over the years um and what were their challenges what were they able to overcome as they they scale there's so the interesting thing to think about is because in inferior was the first uh first service of its kind in this space pretty much everybody was using inferior at one point and when you think back to like 2017 in particular all of the icos that happened during that phase were were basically done doing inferior um i remember getting paged in the middle of the night our team got paid in the middle of the night when the tezo sale happened when the eo sale happened uh when what were some of the other ones um can't think of can't think of any oh aragon aragon was one compound zero x there's uh when if there was an ico that happened in 2017 it was likely using inferior in the background whether it was the application itself or because people were using metamask to interact with the blockchain and and that was really when we we realized what we had helped you for for the ecosystem where so many people could participate in it without there being any sort of barrier to entry other than installing metamask so that that was really gratifying that makes sense if the barrier to entry is so low what about you nader has there ever been any um particular sub graph that's had challenges due to you know an event triggering and can you talk about um how maybe you guys were able to overcome that yeah i mean i think like as you're developing and building sub graphs to kind of learn best practices and things like that one of the things that often slows developers down is if you make too many um i'm sorry like contract calls from directly within a sub-graph because every contract call is a network request so therefore every transaction that needs to be indexed ends up kind of like multiplying that so that's like a multiplier so if you have 50 contract calls per event then you now are like multiplying the number of network calls by 50. but there's a lot of different kind of like best practices we've documented some of those in our documentation but in general like some of the work that we do is to kind of make that make it for the developer experience so developers don't even actually have to think about that that sort of stuff so you know in addition to adding new features and um you know adding new networks one of the things we do is just like working on developer experience and part of that is being able to kind of build into the actual apis and all the tooling things that kind of make developers lives easier without them having to think about it that's great okay cool so i would love to to open it up to you guys for your questions um anyone want to step up to the mic any brave souls with some questions for our our our panelists anybody no okay well we'll continue and if you feel like you'd like to ask a question just just question the question cool yeah let's open it up to you guys i've got a question for you nader i'm curious to hear about the challenges of scaling the graph across multiple protocols because i think that's something that a challenge that that all of us have uh can you repeat the question i'm sorry the the challenges of scaling the graph across multiple chains oh multiple chains right so um right now the graph is supporting a lot of different edm networks so for us to build out a new evm network into the graph it's actually not that hard because a lot of the apis and functionality is almost exactly the same but we've also recently added support for cosmos near and solana or at least road map those near is already ready to go and you can use it today so when we add a new evm network it's actually not that complicated but when we add a non-evm network it is very complicated and it takes a lot of time and work and often we actually bring in another team just to focus on that and do that um alone just because it is so much work and it is so complicated so right now we have the hosted service which supports a lot of different networks and then we also have the decentralized network which for now only supports ethereum layer one but part of our roadmap this year is to actually add more more networks to the decentralized networks but yeah it's definitely a lot of work and trying to figure out which networks to support um listening to the developers trying to understand the ecosystem see where the usage is all that drives our decisions i would say cool okay well i don't see any audience questions so we'll just kind of keep keep going um eg this morning in your talk you had mentioned um hybrid structures hybrid infrastructures um can you contextualize that within uh the scalability of of apis super super technical yeah absolutely so um i i very much like to approach things in a collaborative manner like i even though we offer similar services i'm a huge fan of the graph i i i got a chance to just know temaca and hear about their product and it sounds awesome and i'm looking forward to working with them as well but when so so our apis are very similar and very compatible in terms of gateway and inferior and it doesn't need to be a choice of just using inferior just using gateway you have the opportunity because we support this open standard api to use both and have a structure in place that's resilient more resilient by than just using one provider sure like just as a single provider we have resiliency already built into our service but when you take that and expand it out across like an organizational boundary it almost becomes uh pretty pretty much bulletproof in terms of like what what sort of disaster or or incident can affect both entities like and then it's up to the the person that's building it to really uh think about like what what their tolerance is for for failure and then build the system appropriately same thing with the graph there's a lot of data that you can get through the graph that you can also get through our services and vice versa and so it's just like a different method of querying the data so i've seen people architect things that if you use the graph you can pull the data through it or it can fall back to using inferior if somebody doesn't have that index node available yeah that's i mean that's that's super inspiring um and something you know somewhat of a best practice for building and it's it's great that this hybrid infrastructure can actually encourage us um not depending on one solution but but utilizing many um i can't recall the title of moxie's it's it's uh it's slipping my mind right now of moxie's um uh web three christmas called the moxie article yeah yeah so it was brilliant um if you haven't read it check it out um published i think it was a early january but essentially an inferior was mentioned in the context of you know still a lot of um reliance on the api but this morning you had mentioned that you know there isn't a dependency there's just a utility so um could you kind of expand on that and maybe continue to expand on the way that your projects um can be integrated and and hopefully inspire um you know a greater use of diverse apis yeah sure and i'd be interested in hearing uh their thoughts on it as well that um what i said in my talk earlier was it's there's there's some truth in it in that a lot of applications use inferior but none of them solely depend on inferior and that's a big difference where um you're able to use inferior or you can use gateway other people are also using the graph in places where you could use inferior and it's it's really up to the developer to architect their application to be resilient yeah i mean um i enjoy reading critiques of web3 and i really enjoy when someone actually comes with the approach that is a well-intentioned and isn't kind of like trying to be toxic because we've seen a lot of discourse between like people that are pro and against web 3 and it seems to be very very polarizing for certain people and they can't really have a conversation in the context of trade-offs and i don't think like you would say web 3 is like ultimately going to save the world or it's the going to destroy the world in reality there are just technology primitives that we now have to build applications and i think part of his post was i think his post overall was like very well intentioned so i think there were definitely areas where maybe he was missing the mark a little bit and maybe that uh either that or i we have very differing opinions around some of the points he was making but the overall arching point around data verifiability i thought was pretty interesting and that's kind of one of the problems that the graph tries to solve because like if you have a decentralized network of indexers and you have a network of participants that are kind of working to verify the data that's being returned you can kind of know that the data is is correct and verified verified i guess you could say any any thoughts you want to share on that piece as it relates to to what you're building tomok we've i think we've got one one minute yeah yeah just real quick so yeah so many things that we're looking at for us when we go multi-chain it's really just to understand very clearly like what's going to be the applications one of the discrepancies that we see in the space today is mainly the hardware it's not really to the level that the software is so i think in the future there's going to be more hardware dependent blockchain infrastructure i think that's going to be a big part in the future because today it's a big pain point in this space so we're talking a little bit about hybrid cloud again understanding what's the infrastructure on the lane to support all these blockchain is really complex and it just requires a lot of time so i think the future is going to be very interesting when it comes to high performance computing the metaverse the future is bright for blockchain data and apis so so keep building i think we're are we thank you thank you thank you everybody