The Implications of Serverless CMS (Podcast Transcript)

Amy Tom talks to Pavel Desjnuk, Co-founder and CTO of Webiny, and Richard Kubina, Full-Stack Developer Extrodinaire at Hacker Noon, about the implications of serverless CMS. They discuss serverless migration, whether to go serverless or stay on-prem, and the security implications of serverless CMS. Should you trust serverless systems? Can you easily migrate to a serverless system? Find out on this episode of the Hacker Noon podcast.

In this episode, Amy talks to Pavel Desjnuk and Richard Kubina about:

• What does serverless CMS really mean? (06:30)
• Would Richard implement a serverless CMS? (12:20)
• The security implications of serverless systems (14:30)
• Serverless systems for small businesses (18:50)
• When Coca-Cola moved to a serverless system and saved 60% of their bill (21:45)
• How to establish a connection between your Headless CMS and a page builder (30:40)
• Whether your API gets bombarded with queries with serverless CMS (36:00)

Follow Pavel Desjnuk:

• Follow Pavel on Twitter @paveldesinjuk
• Learn more about Webiny at webiny.com

Read more on Hacker Noon:

• Read Richard's stories on Hacker Noon

Shownotes:

• Join the Webiny Slack community

Machine-Generated Transcript (Please Excuse The Errors)

Amy: [00:00:00] This podcast was produced by hacker noon, hosted by me, Amy Tom, and edited by Damian. Welcome. Welcome to the hacker noon podcast. This is Amy, Tom. I hope everyone is so excited to be here. If you're not listen, I don't know what to tell you. Turn this podcast off and listen to something else. But I think that you're going to have a great time today.

Because my guest joining me today are Pavel from a webinar, the CTO of a webinar and Richard, the full-stack developer at hacker noon. So I am very excited to chat with you guys today. Pavel, how are you doing? 

Pavel: [00:00:41] Hey, everyone thinks Amy doing well 

Amy: [00:00:44] welcome back to the show. This is your second episode with us.

Yeah. Richard's first podcast appearance. Richard, how are you? 

Richard: [00:00:53] I'm doing okay. Thanks. I am so excited to have you guys on today. I want to talk to you about serverless CMS platforms. So as we discussed in one of our last episodes, a few episodes ago, Pavel is the CTO at webinar. 

Amy: [00:01:12] And Pavel would you mind giving us again a brief introduction to what Webany is?

Pavel: [00:01:16] Yeah, sure. So a webinar is an open source framework for development of full-stack applications, which run on serverless infrastructure. It's historical stepping a project, deploying it to your cloud, and it makes it really easy to get started. So you don't need to be a serverless guru. 

Amy: [00:01:34] Right. And one of the questions that I had right off the top of my head was why would one want to host a surrealist CMS as opposed to an on-prem CMS?

Pavel: [00:01:45] So there are many points to this question and answer. So, there are, of course, some, some of that we covered in our last talk. So those who missed it, please have a listen and we will just cover some of that here. Serverless is slowly starting to actually it's picking up the bass quite fast. Why?

Because it reduces the amount of DevOps. And knowledge of infrastructure and how you set it up, how you maintain it, all you care is how you write your business, logic, your application, right? I mean, some would argue that while there are still servers in the background, of course, but the point is that you don't need to manage them.

There is a cloud provider who is taking care of operating system of scaling it for you. And it just provides you with a run time, which you use to run your application. And that's one of the key reasons why someone would want to start building their applications on top of servers. One of the reasons why it's so attractive is because of course, to run your own data center and build.

Your entire infrastructure and everything you need highly qualified engineers and professionals who know what they're doing, right. Infrastructure is not simple. We used to run. So me and my co-founders and we used to run a web agency and we used to do everything from coding to infrastructure setup.

And to be honest, we hated it. So the infrastructure. Can easily be like a full-time job and then somewhere. And then on top of that, you also need to develop your app, you know, satisfy your client requirements and stuff. So when Starla's popped up, it was really a solution to all the problems for people who are not very infrastructure oriented.

And it cut costs because any small company has a very limited budget. So hiring a dev ops engineer is expensive. If you just Google an average salary in in the U S you get around from 100,000 to $150,000 per year for one engineer. It's a lot, not every startup, a small company can can afford having a team of dev ops, especially fully qualified with experience dev ops engineers in their company.

So serverless provides a solution for that. You no longer need to build your data center. You no longer need to hire those expensive professionals. And the hiring is of course, complex enough for all the roles in your company. But with dev ops it's an, a whole new level. Also very often companies need to work on MDBs or proof of concept, small applications, where they don't need to, to over-engineer stuff.

And every time you start building an MVP, Before serverless was around. You had to immediately start thinking, okay, how do I run my code? So containers right back in the days, bare metal servers, installing operating systems yourself. It's horrible. So containers solved part of the problem, but serverless is eliminating the problem.

Entirely small companies on tight budget can immediately develop their software and run it. So it's like day one, run a software in the cloud. 

Amy: [00:04:54] Right, now Richard, I feel well, as the hacker noon podcast, host and editor, I am very unfamiliar with any kind of infrastructure system that we have set up. But I feel like with a company that is the size of ours, we have about 25 employees at this point. That this would be something that would be beneficial because we're kind of more of a startup. So what are your thoughts around? 

Richard: [00:05:23] Yeah, I mean, when I first saw that the title, like the implications of self hosted serverless, I got to admit, I thought something was a little bit of miss. I was curious of what it meant to be on. Like premise and serverless that, those kind of interests. So because I think of on-premise like you have a server you know, a physical server on hand that's, you're going to be loading stuff up and provisioning or whatnot. So that was one thing that popped out at me, but yeah, I mean, this, there's definitely an allure here because, um, I am also not the greatest fan of dealing with our Google cloud platform infrastructure stuff.

So besides like writing software, we're trying to improve things for our users, but at the same time, we're managing a lot of the infrastructure and yeah, I, I wondered what it would take for someone to migrate to a system like this. So. Yeah, I definitely see the appeal of it. And I'm curious, you know, what kind of tools are there other people that have migrated from existing systems? Or do you usually see people adopting a Webany? That's like a Greenfield.

Pavel: [00:06:23] Yeah. So far, when you, when we moved little bit of history, so when we moved from bare metal servers to containers, it was pretty much the same software. It was just virtualized the operating system, everything was virtualized and you could just.

Copy and paste your code up there and it would work with serverless. Unfortunately you have to write your app differently. So an option of copy pasting is out of the window. You need to architect and then rewrite your apps. But from our experience with clients and companies, that approach us. They are totally okay with that.

So we don't see that as being a, a blocker for them. In fact, it also pushes them to upgrade their step because sometimes there is a bunch of legacy software, which companies are afraid to even try to modify because don't touch it. If it ain't broken, if it works, just let it work, but it change and move to serverless.

Forces you to rewrite. You just don't have an option. And in that case, companies are very often relieved to hear that they just have to rewrite stuff and then they can get rid of legacy stuff and maybe start using more popular and modern tools for other API APIs or whatnot. 

Richard: [00:07:40] That sounds neat. Um, yeah, I guess, um, I'm curious, like how the community is building up and  how long have you guys been on?

I know it's been like a few years, like since I saw I was looking at the project you'd like first, the first commit of your, your Git hub was pulling it all into one mana repo. Some of those kinds of interests. And I've had some discussions with some of the colleagues here about Mana repos and whatnot.

I personally am a fan of keeping things together. If you can, don't make it more complicated if you don't need to, as far as the developer's perspective. So. Yeah, project management is definitely a challenge and we run on monitor repos and it's never ending debate out there. But you just have, so use the tools that solve a problem.

Pavel: [00:08:24] We try to be as much as possible, you know, objective about things and just find the right tools to do, to do the work. If something works better in the monitor report, use that if something is better as a separate report, use that. But yeah, it's got to make a decision. Basically. It doesn't always matter what do it just be consistent, but with webinar, it solved a lot of problems and that's how we set up a projects for webinar users.

And very often they discover among the ripples when they first installed webinar, it's like, wait a moment. This is kind of different type of project organization. What is it? And then they go through our docs where we explain that stuff, and then it's like, Oh, this is cool. You know, you can have all kinds of different parts of the system within one repository, which includes infrastructure and configurations for the entire AWS cloud.

Plus your code plus, or business logic plus plugins and so on. So it is comfortable. That's interesting. So the the infrastructure is also up as code, right? It's a stick declarative. That's cool. Yeah. And below me to declare all the configurations and we like it because it's code, as we use TypeScript for everything below me is entirely.

Java JavaScript, TypeScript compatible. And it gives us flexibility to do all kinds of stuff. We are not locked into Jamo files in a weird configurations. That's also one of the up and coming tools. I mean, the tool is brilliant. There are lots of huge companies using it and their company's growing really well.

So they're not going anywhere and April so far in that we have a community of 800 developers already. And when they. Finally get their hands on, follow me because you don't need to touch it. If you don't have to right. Dharma of our users already developing production projects. And then they are adding new configurations to the infrastructure.

And every time we hear like, Hey, this balloon stuff is great because it's code, right. And it's very readable. You just go in, you read your code. 

Richard: [00:10:26] It's very transparent as to what's going on and getting all that revision history or that they being in a repo sounds very alluring. 

Amy: [00:10:33] Richard. Do you have any experience with Poloma?

Richard: [00:10:36] I do not know. I mean, I come from a background where we just had on-premise servers. We deployed like maybe three servers to a manufacturing, plants it room or something. Right. So that, to me, I'm premises always like early on the ground floor there. So yeah, even just coming to hack a new in a year ago, um, getting up to speed on a lot of this cloud infrastructure.

Amy: [00:10:58] A world where content is King demand, a solution that is able to deliver the scale and agility that businesses need webinars. Serverless. CMS is a self hosted open source headless CMS that runs on top of the serverless infrastructure. And because of that serverless infrastructure, you only pay for what you use. So give it a try and see for yourself. I'd webany.com. 

So, okay. If you were to start your own business, would you be hosting your CMS on-prem or a serverless? 

Richard: [00:11:29] I got say I still a little bit more comfortable being able to shell into a server and, uh, figure things out that way, you know, like that. I think that's, it's a hard thing to shake.

I don't know if it's just an old school thing. Right. And I'm just. I got that. It's nice to stay in the comfort zone. Right, exactly. Right. It's like, I love just being able to it's. Okay. It's just a server. It's like, I got one of these and right now I'm using it to develop on. So it's, you know, it's, it's comfortable.

It's like, it's cool. Like I can just go show him something and see all the processes. Ronnie, very simply I'm I'm used to all his commands. So. It would take some effort, but I imagine that once you get past that, there's a lot less things to worry about. So it seems like if you're trying to scale and there's a lot of people visiting your site, if you're going to have to figure out a way to not deal with all these other concerns and put in someone else's hands a little bit, but.

Yeah, it sounds like it's a, it's a good collection of tooling. It looks like you guys are using AWS. And I think it's, 

Pavel: [00:12:27] yeah, we are currently focused on AWS. We are looking at other clouds and that's also the reason why Boomi is in our tool chain because they support all kinds of. Cloud providers. So we don't need to switch configuration types or anything.

We just use the same tool to deploy to Azure or Google cloud so that you in the future. I see. Yeah. 

Richard: [00:12:47] Yeah. I mean, it just seems like a safe bet. Right? You choose Amazon to manage these things and looks like it was a good First step. Right. So yeah, I imagine that's a good way to start a new project. So I think I would have to maybe grow a little bit and give it a try, but it'd be good experience for me 

Amy: [00:13:04] from a non-developer standpoint. I, from, and from what I understand, it's the scalability. That is the real, like big one, because like we were talking about in the last episode, if you were going to have like, Say a Superbowl commercial or you are planning a tech crunch article, correct me if I'm wrong, Powell. But that means that with a, if you're on prem, you have to like plan for the increase of volume.

But if you are serverless at Autodesk, exactly that. Yeah. What else would you say Pablo, to convince a young developer of mind, such as Richards about the benefits of serverless platforms? 

Pavel: [00:13:46] So there is always the question of security, which is gaining more and more attention all the time. We hear about all these security breaches, right?

We get like 10 new articles every month about how many data leaks happened and what companies lost the huge amount of user accounts and stuff like that. Of course not. Everything will be solved by serverless and cloud in general. Bots using serverless technology does solve some of those security issues.

For example, you know, as you no longer have to install the operating system, right. And there is nothing to SSH into. As Richard mentioned, there is just no. IP address you have to attack right? There is nothing like there is nothing you can aim as an attacker. So the perimeter of the application slightly changes.

It's no longer a single domain, which you can hit or an IP address, which, you know, is an entry point into the system because Lambda functions, they just spawn and go it's spawning, or they don't have an IP address for the outside world. So that's on the plus side and how applications get more secure.

Just with that fact. And other fact is that, uh, cloud providers run all these services, which are battle tested. Obviously your app is not going to be the first one, which will run in the cloud. It's been years. And these cloud providers have really established, a good fundamentals and security policies and standards around.

How to secure your app. There are a web application firewalls which can handle bots, which can spend your API. So you no longer have to worry about it. Of course they come at some cost, but I think the cost of these security services will always be less than a scandal, all over the internet that your company lost like 5 million user accounts. Right. Does this work with hybrid cloud too, because I imagine just to play devil's advocate from the security standpoint, that if you are storing sensitive information in the cloud, that's not hosted or controlled by you, then that is a security implication as well. 

Yeah, that's the trust issue that we come, we come along to that question often. And some people just don't want to use, let's say AWS Cognito for user accounts storage. Then they opt in for services like zero or Okta. But again, those companies have so many compliances and regulations that, I mean, of course we can always say, Oh, I still, I don't trust anyone. Right. It's the easiest thing to say But do you really trust your own database in your data center?

How can you be? Sure. I mean, those companies are built over years and years and they have all the security professionals working for them. And then there is you, right. And you learn to spin up a server like two years ago. How short can you be that. The data is more secure in your own basement than it is in a professional cloud, you know, run by a huge cloud provider.

So I think it's a debate and it's more like a, it's the same debate going on between Nvidia and AMD or Intel and AMD or iPhone versus Android. I think it's more of a. Thank club issue. It's less of an actual security risk. Do you think that serverless systems are better suited for small businesses that wouldn't necessarily have a sensitive data that they are concerned about leaking?

I think serverless is just a, another product on top of a cloud. Right? So security of the serverless itself is a. Especially regarding the data is not that much of a problem, especially because serverless. He uses functions as the main compute and those functions are short-lived. They don't run long processes.

So nobody can, as I say, chain or gain like no attacker can gain access to your function and then sit there for months reading your data, right? Because that functional shutdown after the request ends, first of all, there is nothing to get into. And then even if we imagined there was a way you couldn't run a longterm process, which would collect your data.

So on that front, Functions are way more secure than running a server, which you have to monitor for had processes and open ports and, you know, do all that all that stuff. That's for serverless part of it. And for user data and business data in general. It will still live in some kind of database or an identity provider service like Kognito or Okta, which again, I think we already covered why we should trust that more than our own server running in the basement. 

Amy: [00:18:27] Right. And I guess if you wanted to have the most secure platform, you need to have your own server, have your own internal security team invest a law into various security tools. It's a huge investment. So it's kind of almost like a trade off of money versus security. How much money do you have to put into the project to create a quote unquote secure database? Yeah, 

Pavel: [00:18:55] it's, uh, it's very expensive and huge companies who really do have the requirement to run their own data centers. They invest huge amount of money on the penetration testing from outside companies, by third-party companies that have nothing to do with them. No, they pay them to hack their systems, just to uncover the vulnerabilities.

And that is expensive on its own. So it's not for small companies. Definitely not for startups, not for freelancers. So I think this whole thing is particularly interesting to small companies and startups who just need to get off the ground as fast as possible. And with regards to like go back to scalability, I guess, as well as like continue to grow and there may be security requirements change.

Amy: [00:19:42] Is there anything that can be done for that? Or what are your thoughts around growing companies and growing security needs?

Pavel: [00:19:50] I can give you an example of one of the first companies that really adopted serverless that was Coca-Cola and you know how huge that company is, and they stayed 60% of their bill by moving stuff to sort of a list.

So that's approved. That is serious. You know, a corporation can trust serverless and cloud in general. And there are many other examples, but like Coca Cola is huge right there. You don't need to explain how big the company is, how much money they spend on just the promotion. Now imagine how much money they were spending on technology that backs up that machine.

Right. And they move to serverless. And we're one of the first adopters in the enterprise world. So I think it speaks for itself. I bet that migration process was wild. So I'm quite sure. Yeah. But it did pay off, I mean, imagine saving 60% of Coca-Cola like it's how much is that? Right. Those are insane numbers, but it, it just It reduces the amount of effort and manpower you have to have in your company to manage all that. It's insane. 

Amy: [00:20:59] Yeah. And I guess from like an organizational standpoint, as well, if companies are investing into webinar, that's what got to come from their OPEX budget versus there's a separate expenditure budget for a security usually. So I feel like they're kind of two separate things in budget terms too.

Richard: [00:21:19] Well, a webinar itself, it's an open source tool, right? We can provide some general best practices from the beginning, but we cannot guarantee that if you modify your system, your bullets pro for nobody will be able to bring it down. I mean, it's the same with any open source project, like take WordPress, for example, like when you install a WordPress on your machine, like how sure.

You are in its default security setup, right? The moment you deploy any software into your cloud, you are responsible for the security, especially in your business logic and stuff like that. So cloud provider can take care of big part of those issues, but there is a lot of security enforcement going on within your actual code because we're moving to serverless.

As I already mentioned, the perimeter of your application is completely it's. It's no longer a single point of entry. It is now dispersed across different cloud services. So you need to reorganize how you think about security. So you have to integrate a lot more checks in your application. So in code, right in our business logic, a lot of that comes with security policies, which.

Are enforced by AWS IAM service. It's like user policies, right? Who can access which service. So there is a lot more going on in your actual application now, but there is a lot less going on on the network side, on the operating system side, on web application firewall, you no longer need to worry about that because that is solved by the cloud provider.

So it's kind of, it's a shift. It's a shift in a different direction. I'm not saying that cloud solves all your security problems. Of course it doesn't, but it's a change. And I think it's a positive one. Yeah. And it's risk and reward too. It's not impossible for a cloud provider to get hacked. It's not impossible for like say a VPN to get hacked.

Amy: [00:23:13] But it's a risk and reward system. Are you going to save 60% of your operating costs or are you going to take the off chance that you're a cloud provider is going to get hacked? Right. 

Pavel: [00:23:25] Sure. I mean, look at all the attacks that's happened the past years when like GitHub MPM and everything went down because of some tier one internet provider was, you know, Dede, DDoS.

I mean, it's internet, you know, there are challenges that we'll never be able to solve. So, yeah, for sure. I would also love to ask you about what other ways webinar is changing the industry. So, as the Richard asking one of the questions before is how they just switch to, to serverless, right?

And when we started with the webinar, and even today, there are no tools that can help you start developing and rewriting your business logic, because we said you need to rewrite our app entirely for serverless. So there are no complete solutions that do that. Except webinar webinar gives you the whole setup.

It gives the infrastructure. Boiler plate. Like we can figure a lot of services for you and you can of course customize them later, but you get a lot out of the box. You get a framework, you get a set of applications like headless, CMS, you get a page builder to build. Build your content like, like WordPress, right?

Uh, we have an entire file manager to handle their files and your galleries resize your images and stuff like that. And it's all built in the spirit of serverless to, to work on those AWS cloud services. We of course aim at running them on other clouds as well. But, uh, at this point we are focused only on AWS.

So we make it easier to get started with serverless. And we need to be very clear about if you go Google, like serverless framework, right? You will get that one company that is building something they branded as the serverless framework, which is a bad use of a keyword. Right? I mean, serverless is, so is so broad as a term that branding your product as a serverless framework is quite vague.

You don't know what you get. But that product in particular is only oriented towards infrastructure, but they don't help you develop your app while webinar does revenue has an entire layer of, of plugins. And it's an opinion, opinionated framework. Sure. But it does have a, an entire layer and it's plugged in.

I'm able to develop apps, client-side apps and API APIs. And we provide an entire CLI, which is also plugging Annabelle. So you can customize how things work and the processes that are happening for your project, so that there is a lot that just, you don't need to worry about that you just create a web in your project, and you're already ready to start building your product or building your MVP.

Richard: [00:26:02] Yeah, I saw that was pretty impressive. A demonstration video with like the, what you see, what you get editor there creating pages or whatnot, was that kind of geared towards folks that don't know how to make front ends or CSS? I mean, I know I'm terrible at CSS, so that looked upon. Okay. Yeah. Like an idea of no code or something like that, where it's just like, Yeah, lowering the barrier to entry.

Pavel: [00:26:25] Yeah. The page builder is actually the first app we built when we learned about serverless, because there were no other products that were running on top of serverless. There was nothing to. To consult, right? We couldn't take a product, take it apart and see how it works to learn how to do stuff in serverless environment.

So since our background is a web agency developing full stack apps, API APIs are more or less clear, right? Again, more or less, but front end stuff and snapshots and service side rendering or pre rendering. That's. Far more challenging than any API on there. And that's the first thing that we focused on.

We just had to figure out how do you build a full stack app? So it works kind of like WordPress, right? You have an administration app, you log in, you click through your editor and when you refresh your front end app, you get that content. It sounds very simple, but it's very complex, especially in the serverless environment.

So Page builder was that attempt at understanding how serverless works and how full-stack apps work. That's why we started with that. Into something that can be expanded because everything is plugging in a bubble, it can be expanded to become like a no-code content editor. And we are currently working on a, on a feature which will connect our headless CMS with the page builder.

It's something nobody did before we have a bunch of headless. CMS is out there, Contentful stroppy Dato CMS. There are like there, hundreds of them. I don't even know the names of all of them. But they're just that they're headless CMS. And then when you set up your data, You have to use Gatsby or next JS or some custom solution to pull data and render that and handle snapshots.

If you're doing it yourself with Gatsby, you have to rerender everything on each change, it's presents a whole new set of challenges, right? So again you have to glue together pieces. Like this thing is cool for generating static apps like JAMstack and then this is a headless CMS of your choice. Cool.

Now glue it together. And then you discover 50 new challenges you need to overcome. So with revenue, what we are currently working on is establishing a connection between your headless CMS, which is running on the webinar and within your administration app and the page builder. So we are effectively connecting headless, but in a way, right?

And you will, you will be able to build templates and rents or data, not leaving your one single system. And we take care of doing incremental snapshots. So your site behaves as if it was built by Gatsby. It will all be static snapshots coming from a CDN, but your data and your designs and everything will be coming from webinars.

So you don't need to be used together five or six tools to make it work. Okay. Gotcha. I can see some of the other members on our team are that aren't necessarily developers or whatnot on doing some of these pages and redesigns themselves instead of doing their work and figuring out yes, we're going to bring a ditch of the Figma mock ups and whatnot, straight into what a mini.

Amy: [00:29:48] All right, great. Pavel I think that I maybe just don't really understand this, but could you explain headless CMS? 

Pavel: [00:29:57] So every application needs data and data modeling and coding it yourself is tedious and it's repetitive and it's very technical, right? You basically need to be a developer to do that.

And headless CMS is a solution which simply provides you with a user interface where you log in and you can model your data for your API. So, let's say you're a bookshop. You can create a model called book and it has a title and author, a short summary and a price. And it's immediately available by an API.

So the consumer of an API, and that's where the word headless comes in. The consumer reads that data via an API end point, meaning a request. So there is nothing that renders your data and you returned back. Most commonly Jason data structures. It can be anything, it can be XML or whatever, but most commonly it's it's Jason.

So you can develop a mobile app, which reads data from your headless CMS. Right? So I think of headless CMS as a simple API, which you built by using a user interface and you define your data models via a friendly user-friendly interface. So you don't need to touch code. Okay. That makes sense. 

Amy: [00:31:21] Yeah. And it seems like it would be, make it easier for people to have an easier barrier to entry to these kinds of things.

Pavel: [00:31:28] Yeah. And a lot of front end developers are comfortable using that because previously when we were, when there were no headless CMS, You always need needed to have a backend developer for, you know, to, to implement an API end point and model data and write database queries, which Fetzer there today to for, uh, expose some kind of filtering sorting and that now you no longer need that.

So if you're a front-end developer, you can pretty much just. Create an account on any headless CMS, which is SAS out there like Contentful or adaptable or graph CMS or whatever, and immediately start building your data models. And. All the sorting filtering and all that is taken care of automatically for you.

So you, as a front end developer would just bring up your gods be, or next JS or whatever it is you're using. And and simply send a request to that API endpoint and gets our data and, um, you know, put it together into a nice design and that's, uh, that's why they became so, so popular in the recent years.

Like everything is headless and that we're just means there is no user. User interface too, which renders it right. There is an interface to manage data, but there is no rendering mechanism. You have to deal with that yourself, right? To a graph QL stuff. Concept here. That's a piece of the component webinar because I'm actually not too familiar with that.

Other than the fact that I believe your, your front end is doing a lot of the query now, right? As it, instead of moving a lot of the query parameters and sorting and whatnot that you would do into an API, you have a lot more power on the front end. Well, flexibility. Headless CMS has became popular exactly for a gem stick.

I mean, it's, especially because of JAMstack because you can build a, an application or a website in gods B or next JS or any static site generator. And it only communicates with your API during the build process. So it's not like every time you visit a website, it starts bombarding your API with requests.

Now it's, it's only. Contacting your API when the website or your app is being built. And that only happens when you initiate the build or your site. Right? So to answer the question, no, you don't bombard your API with the move with requests all the time, unless you have a mobile app, which is like insanely popular than, than yes.

You would be. Of course hitting it hard, but for websites and static apps, it's, that's not the case. So it is a graph QL portion of the Webany stack. Like what is the significance there could have done been done with the rest fully API  yeah, that was a really, it's a great step forward for API development.

First and foremost. You define a schema, right? And that schema provides a complete documentation for the consumer of that API. So we as developers who develop the API itself no longer need to write documentation about an updated the moment the API is deployed. The end consumer can just ask for a, Hey what's the structure of the API, right?

And there are tools that do it for you, like graph Gail playground and graphical. And there are other open source projects that allow you to open a sandbox. You just point your sandbox to the graph, QL and point, and it will pull in the schema definition and provide you with an auto-generated documentation and auto complete.

As you write your queries, there are even. Tools for like iOS developers. A friend of mine is an ISE developer. So I suggested to him and he never worked with draft KL. And then he tried the extension in excode for graph QL or completion. And as you type code it, auto completes. Your query based on API endpoint.

So he no longer needs to, and, you know, to read the dogs and figure out what the parameters are. He don't, he doesn't need to ask me, Hey, can you, can you tell me what the parameter is to sort something by price? Like, no, it's there, it's in the auto complete on the docks, man. So that part, sorry. Yes, we solve maintenance problems and speed of adoption of your API because it's all there.

You don't need to explain anything. Plus it reduces the data that travels from the API because you can query very specific fields that you need and you can query different resources at the same time in one HTTP request you can query and give me my user data, give me the latest blogs, give me related products that were sold last week.

Right? And you can do that all in one. I should request. Because one graph QL query can contain multiple fields and very specific data, which then the server can process and do it in a very optimal way. Some things of course are difficult to optimize, but very often you can optimize it. When, when targeting specific fields and not load data, which was not requested by user, why would the rest you're most likely select all from, you know, limit 100 very full door chatting, sending out information back and forth.

Richard: [00:36:56] Exactly. Yeah. I can see the appeal. Yeah. 

Pavel: [00:36:58] And then with the rest, you also need to manage several endpoints, which in big apps can grow to like hundreds of endpoints. This one is for products. This one is for users. This one is for books, for articles and whatnot with the graph. Gale, the point is to have one endpoint which serves as a source of truth for your entire application.

So whenever you're sending an API call, you are sending it to the same graph KLM point, and you're just requesting pieces of data that you need. That's interesting. And this is also something that you developed within the webinar UI as well. Is there like a UI component developing the graph QL API? No, we just integrated the existing tool.

Yeah. As a tool is. Mature it's there, it works where it's really nice. And there is this graph kale playground, which we simply integrated to be part of our administration app. So it's really, so you don't need to open separate client apps to just, you know, click the menu. And it opens the playground with all the end points we provide like four main API first headless, CMS, read, manage whatnot, and you cure immediately.

They are your. All of your requests are immediately signed with your authentication token. JWT eliminates that process of copy and pasting stuff and authorization. So that's also one of the new additions in , which speeds up the development and any iteration, especially when building new content models and you immediately may want to see how it will look for the user.

It just opened the playground and it's all there. 

Richard: [00:38:35] Hey, you just released version five, right? It was like a month ago or so it's pretty quick, 

Pavel: [00:38:40] already released 5.5. So we are doing a. A release every two weeks. You're really trying to make it, you know, a stable release cycle with the fixes improvements, the communicate with community, a lot slower system cadence.

There are lots of requests from community. So we are We are collecting all the feedback we can and try to integrate it. 

Richard: [00:39:06] Maybe I'll give you some feedback. I'm thinking there's going to be a skunkworks project of rendering, some hacker noon stories with, 

Pavel: [00:39:13] well, we'd love to hear that. Yeah, absolutely. 

All right. Thank you guys so much for joining the podcast, Richard, if we want to get with you, where can we find you? 

Richard: [00:39:27] Oh, you can, uh, you know, at [email protected], uh, the best right there. 

Amy: [00:39:33] Excellent. Maybe I'll put a link to your hacker noon stories as well in the show notes and Pavel, can you remind us where can we find you online?

Pavel: [00:39:42] Yeah, I'm mostly on Twitter, so  the same. It's spelled the same as my name so there and Webany community Slack. Of course. 

Amy: [00:39:52] Amazing. All right. Thank you very much, guys. If you like this episode, don't forget to like it. Subscribe it and share it with your friends. You can find us at hacker noon on Instagram, Twitter, and LinkedIn.

And until next time stay safe, stay happy, stay healthy. Stay whole. See you guys next week.