Yuval Hazaz:
If you want to talk about how we build a community, the most important secret sauce is to deliver value, to be open with the community and to go, let's say all in. Either you go all in with open source because you believe in it, because you want to do it this way. If you are just coming from the marketing perspective of it, don't do it.

Eric Anderson:
This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson. Today we have Yuval Hazaz, creator of Amplication on the podcast. Yuval, thanks for joining.

Yuval Hazaz:
Absolutely. Pleasure to be here.

Eric Anderson:
What is Amplication?

Yuval Hazaz:
Amplication is a code generator for backend applications, but non AI, and we'll talk about that. It generates code that is very production ready with no hallucination and no surprises. It's also focused on all the foundation of the backend, giving the developer the full freedom to actually write the business logic.

Eric Anderson:
So developers are all the time writing these backend services and to do so they write a bunch of boilerplate common patterns. Amplication allows them to avoid all that, skip that step and just write the important stuff?

Yuval Hazaz:
Exactly, exactly. So instead of wasting time on all those repetitive task, boilerplate, and not only boilerplate but everything that is kind of the foundation and you want it to be standard, you want it to be consistent. Instead of reinventing the wheel every time from scratch or growing, looking for other solution and copy paste code from other places, we allow the developer to choose and select the components and that will be on a single developer scale that will just help him create the code, but on a team scale or an organization scale, it also helps create very consistent code across the board because everybody use the same components and you know that everything is based on best practices and all the flavors of the organization.

Eric Anderson:
Amplication is useful at development, but for runtime production, your application is just running standard code? Amplication is not involved in the runtime?

Yuval Hazaz:
That's true, that's true. So we are not a backend as a service. We are not providing you any black box or anything that you need to run on your production or we are not running your code. We are sitting on top of your git repo, we are pushing code to that. You got all the regular life cycle and CI/CD and everything you want to run on that generated code. Just another PR instead of only team member, it comes to Amplication and from there it goes to whatever you want.

Eric Anderson:
I'm impressed. Amplication has 13,000. GitHub stars, which I know is not everything but it is something. It's quite a project that's popular, growing fast. I want to ask you how you got to that point. You tell me what's the best place to start? Is it your background and why you wanted to build Amplication or more recently how you grew the community?

Yuval Hazaz:
If you want to talk about how we build a community, so actually I would even say the community build itself and help us build Amplication. Of course we already had to know what to do and do things specifically and we can talk about different, I don't know, hacks for anyone who want to build the new open source project or things that help us achieve that, but eventually the most important secret sauce is to deliver value, to be open with the community and to go, let's say all in.
You cannot just say, "I'm building something open source," but under the hood or behind the curtains, try to do everything kind of secret or hidden from the community. Developers are very suspicious and they can smell that immediately. So it's either you go all in with open source because you believe in it because you want to do it this way. If you are just coming from the marketing perspective of it, don't do it.

Eric Anderson:
Let's go with your background and why you wanted to build Amplication. And then I want to circle back to some questions on community building.

Yuval Hazaz:
I've been a developer since I remember myself as a kid I was trying to build stuff with code. My career as a developer, I started 20 plus years ago and then engineering manager, VP R&D and CTO for almost 30 years in my previous role. And I was always obsessed with productivity and making things better and making sure that I'm not wasting my time and my team members, I'm not wasting their time on repetitive stuff, making sure we create something that is robust and consistent and performant. And that brought me a lot of time during my career to find those hacks and solution to allow us as a team to build faster to generate some of the scripts. I was working on a platform which had nothing to do with developer tool. It was a business platform, but we added a lot of functionality into that platform that allow our customers and users to customize the thing. Kind of a low-code before it was called low-code.
It was, I don't know called different names before that. But allowed to do things in a configuration way and settings and moving things around instead of writing everything from scratch. And when I decided to go with Amplication, or started working on Amplication, I left my previous job and I was looking on what I want to do next and I started looking on this domain and this is where I initially found about a term low-code. That was four years ago, early 2020. And I quickly discovered that it's nice but it's not really for professional developers.
So low coders try to take away all the things that developers really want to do and it's kind of grateful, citizen developers, IT developers, business developers, but as a professional developer, you don't want to give up on all the freedom just to save some time. So this is where I decided to go and start building Amplication. First decision was to build it as an open source project because I knew that in order to gain trust with the developer and build something that is robust enough and sophisticated enough, I need the help and the advice and the feedback from the community since from day one, and this is where I started.

Eric Anderson:
Maybe it would help us understand the product if you could describe what it's like setting up a service. You've already just mentioned that there's these modules and I can choose to add or customize a module to the needs of my service. What are some of these modules, for example?

Yuval Hazaz:
So Amplication as a platform is a very opinionated platform. It comes with a lot of opinions already baked in, but it's also built on top of a plugin system where all the plugins are just pieces of code, packages that can customize and can impact the code generation process where you can bring your own opinions or choose to use a plugin that were created by the community. So our plugin catalog includes things for authentication providers or caching mechanisms, [inaudible 00:07:21] like Kafka or RabbitMQ and so on. So you can just choose those things and put it into the code generation process. But the process itself start by defining the data models or define the architecture of your microservice architecture if you want to bring something more than just a single service. So you just choose, there is a nice console, UI that Amplication offers where you go and start defining your service, defining data models.
You don't have to do everything from scratch. So if you have an existing database, we know how to pull the schema and to build the APIs and everything on top of it. And once you have data, the first layer, the data layer, you can go with adding permissions, roles, define some other stuff around it, and then the next step would be to add those plugins. So for example, if you want to use a gRPC or generate the gRPC API, you can just add a plugin for gRPC. Or if you want to connect to the USBOT, you can just add a plugin for that. And then the last step would do just to customize your APIs if you want to add custom types or custom end point and so on. This is all part of the process and you just click on a button, we know how to generate all the code, push it to your Git repo.
And the nice thing about it, or maybe the most special thing about it, that it's not just like a one time thing where you get the code and you just need to take it from there and live. You can continuously come back to Amplication to make changes on those configuration, to add more data sets, more data models, more fields, more services in the mesh, connect those services with brokers and events and we know always how to continuously generate the next pull request and then you always have the freedom to take the code that Amplication generated and customize it with actual codes that you want to write as a developer.

Eric Anderson:
Help me understand, as you were building this, there's probably alternatives or other approaches to doing this sort of thing. One of those is maybe the use of backend as the service as you mentioned. As your customers adopt you, what alternatives do they consider and how do they see you relative to those alternatives?

Yuval Hazaz:
So obviously as you mentioned, backend as a service is one of the alternatives and it mostly depends on the use case. So if you just want to have a backend running and you want to focus on your web application or mobile application and this is where you put all your focus and you just need the backend to be there available, probably a backend as a service would be an easier solution. If you want to get more control on your backend and you want to be things in greater scale, of course if you want to be things in a business environment where you need to have ownership on the code, whether you want to run the code on your own clouds and data centers, that kind of service is not the right solution.
So this is where Amplication comes and bring you the full ownership and customizability and any capability that you want to add on top of it. So when talking about that kind of use case, usually the alternative would be starting from scratch, everything by hand, and more commonly you will see people having some kind of template based starting point. So you'll just have a template boilerplate where you have all the configuration already in place, all the components talking to each other, but that usually will not include all the data models and all the other option Amplication offers on top with the plugin system. But this is more or less the options that developers have today.

Eric Anderson:
What you described sounds vaguely similar to the value proposition I remember from MuleSoft years ago. Is it related, Yuval, giving people kind of a platform for building API's in their enterprise?

Yuval Hazaz:
So if you're just looking for the API layer, once again there are different alternatives, MuleSoft or if you want GraphQL, you can go with Apollo or Surat or things like that where you just get the API layer on top of a database or on top of other services. But that's an excellent option if that's what you are looking at. Amplication is more aimed at the common use case, where you just want to build something. It can be green field, monolithic service, "I want to build a new application," or I want to build a microservice mesh with different services for my product. Usually when I'm a startup or even organization and I have a new project, what developers will do, they will just go and start building it. They will not go with MuleSoft or with a Surat because they don't have anything yet. They don't want to do just the API. They want the entire thing, they want the database, they want the API, the authorization, authentication, the business logic of course, all the integration.
So this is where Amplication comes in and this is the actual goal when we're looking at Amplication, our goal is to be the go-to solution for any backend application that is built as default because you don't really want to reinvent the wheel every time from scratch. You don't want to be locked in specific vendor or specific SaaS solution for your business applications, which can save you a lot of time, but then you are locked for ages and it's not really flexible and doesn't give you all the control and flexibility that you need for your projects.

Eric Anderson:
You mentioned at the beginning that when you started this company you were generating code, which is kind of a novel thing and now a lot of AI solutions are out generating code. You've had to make the decision as to whether you should adopt these freewheeling code generation approaches or not. Tell us about the process there.

Yuval Hazaz:
So obviously today with the AI and LLMs, there is whole new world of possibilities that we must adopt to and we must leverage in order to be as good as we want and we are doing it, but just not for the actual code generation process. So we are using AI for different flows. In the UI itself, if you want to cut some time and save some time by use prompt to define your service or define your data model or define the type of API that you want. Amplication will know how to use AI in order to generate those pieces or to create the configuration for those pieces. But then eventually when you want to generate the code, that generated code is very predictable, it's very deterministic. You will do the same code generation process for 20 times. You will get exact code for 20 times out of 20.
Because you want to take it to production and application sometimes generate hundreds of files for a single service and you will never take hundreds of files that were generated by AI to production without reading it, without understanding what's going on in there. But with Amplication you can trust it because you just review that once, you know what Amplication is generating, you know the code and you can trust it across the organization. Not only trust it, you kind of pre-vet it and say, "This is the way I want my code to look like." And now all the developers in the organization could easily use that and know that they are following the same standard, the same know-hows, the same best practices.

Eric Anderson:
There's a trend towards platform engineering, I guess people are calling it, and I believe this is an iteration on DevOps where there's a team within the company that's in charge of providing platform and services and guidance on how to build services. I feel like they should be pretty excited about Amplication. What's the interplay between a platform engineering team that's trying to standardize the company and Amplication, which provides kind of an approach to modernizing and standardizing backend services?

Yuval Hazaz:
Yeah, that's a great question. There is a lot of hype today around IDP internal developer portals like Backstage and others. Part of this concept of IDP is by the platform team providing developers some kind of a self-service approach where they can get the cloud resources they need, where they can get the configuration, the Terraform files or whatever. Code generation is a small part of it. When talking about Backstage for example, they have the template engine built in and Amplication do it much better. So you are right on the point, platform teams really looking into that and that's a play that they really like. So we're helping them bringing those standards into the organization in a very controlled, streamlined way where they can easily build their own plugin of how a Docker file should look like, how a Terraform file should look like, the helm chart in the Kubernetes thing or the API if the development is also part of the standardization process.
And then not only you're getting the way to create a consistent code across the board, you also have a very built-in process, a very easy built-in process to maintain that. So you can easily get a view from Amplication on the status of each one of the services. Since we're using plugins, plugins can have versions. So for example, if the entire organization using the plugin for Kafka version one and there was an issue in that bug or just a version bump because of security in the underlying packages, you can change it to version two and just make sure that everybody upgrade to version two. You can get the monitoring and see who upgrade, who didn't. And then everything is more automatic.

Eric Anderson:
There hasn't been a great system for determining dependency upgrades in an organization. Random teams will just decide we're ready for the next version of Node and others say we're not. And then once somebody does, everyone decides that maybe we all are. So Amplication can provide that, can be a central hub for making that decision and then propagating that throughout the organization?

Yuval Hazaz:
Absolutely. So usually developers will not be happy to get a pull request with a new Node version or NestJS version or Prisma version or any call framework just one day out of the blue and they're obligated to push that to production because usually that will require a lot of testing and maybe regression and fixes and compatibility. But we do offer that as an option. So you get a visibility of who upgraded already, you can push a pull request.
The team can review that, they can decide if they want to take the pull request, if they maybe can, or need to merge and resolve conflicts and change stuff and choose the right time to go and take that update. Or they can choose to hold that update and skip it if they want, if the organization allow and maybe just keep using the current one until they're ready because usually those changes will require some time. There are different tools which are not Amplication to manage those dependencies, especially the dependencies of dependency and the entire dependency tree and the small packages.
Amplication provided out of the box when you want to get the entire thing as a whole. Because usually once you start updating something in the core of dependencies, you will find out that your, depends on 50 other packages and maybe some of them will not up to date and they're not ready and you cannot update and so on, what they call dependency health.

Eric Anderson:
I want to go back to a couple of topics you teed up earlier. One is around the growth of the project and the community. You alluded to some things being fully open, fully engaged with your community. What does it take to get 13,000 developers super excited about you? And any tips that you could extend to other projects looking to do the same thing?

Yuval Hazaz:
So first, as I mentioned, developers, they have their own opinions and if you try to use a click bait and stuff in order to hook them into your project and then give it to [inaudible 00:19:07], usually it'll not work. You need to provide a real value. And the way we decided to do it, like I said, it's to be fully transparent and fully open source, meaning our tickets are open source, the roadmap is open. We don't have a ticket system outside of GitHub where we manage in JIRA the internal stuff and then we move only the things we want. Everything is on GitHub. You can go to GitHub, you can see our roadmap, you can see what we work on. You can see all the discussion between the team members, issues. Of course we do have some private repository for securities issue and stuff that it's not right to reveal for security reasons.
But other than that, everything is open. Other than that, when talking about promoting your open source project, there are different tips of course, but investing in the community in a way that give them value, meetups. Swag is also great. Hacker News. If you can get on Hacker News and it catches, of course that's a blast, but it's really, really hard to predict. So it's not something that I can say people, "Hey yeah, go to Hacker News, it will work for sure."
Obviously it's really, really hard, so just keep working on it. It need to be a hundred percent. Like I mentioned, it's not an easy task and there is kind of organic motion that we keep getting few new stars every day and new signups every day almost without doing anything. But it's not really true because we invest a lot on content, on meetups, on videos, our blog, talking in places, being here talking about a project. So eventually that works, that create this buzz around it so people talk about it and then people write about it. Our community from time to time, we see that somebody wrote the blog or somebody held a meetup talking about Amplication and so on. So it's kind of start feeding itself, which is amazing.

Eric Anderson:
When I look at the growth of projects, you can see, if you look at GitHub star histories, there's the jumps that happen when somebody's on Hacker News or something, and then there's this kind of organic growth rate that happens every other day. And I think it's interesting that every project has kind of inherent organic growth rate that happens on a normal day. And you're right that while it seems to come out of nowhere, this is a function of the word of mouth virality. It's a function of the content, it's all the things you're doing, product quality and positioning. So the product, you've already described how it's fully open source. How did you arrive at your conclusion to open source everything? I mean, we live in an age in which people are kind of pulling back from open source in a pure sense with various other licensing. You've decided to go all in on truly open source.

Yuval Hazaz:
Yeah, that's a really difficult one to decide on. I cannot say in advance that I choose right and we'll see, I will say. I do know that in order to build a product that generates production code for developers, we need to have a very high trust with developers. And open source was a very early decision. I believe in open source. I want to do open source, but that's also something that was very apparent, that not doing the open source will be very hard to convince people that, "Hey, yeah, we have this tool, it works somehow. It's a magic. Take the code, put it in production."
It's very helpful to come to a room talking with an organization and enterprise and say, "Hey, we already have 13,000 stars on GitHub. We have more than 200 contributors. The code is open source. You can look at it, you can even contribute if you want."
So it's very helpful on the commercial side also. But building this trust is essential. It's not only building the trust, it's also getting the support from the community in order to build the product. Because like I said, we have more than 200 contributors. Our plugin catalog is full of plugins that were developed by the community. We have some modules that were almost entirely build by the community. So it's really value that helps you build the product. The feedback loop is amazing. We release a feature and even before I know that the feature is live because the team already published that somebody will write on this code, "Hey, what happened here? And what happened there? And this was not working or this is excellent." So it's really, really helpful.

Eric Anderson:
Yuval, I wonder if you could comment on something I've been thinking about which is code modernization. It's related to the work you're doing. I didn't realize as I've been looking into this generated code world with generated by AI just how much code modernization is happening. There are billions of dollars spent on outsourcing, upgrades, moving people off certain code platforms onto newer ones. Even within organizations that try to do this all, it's a lot of work. We all know the pains of tech debt. What does the future look like in order to keep our apps modern and keep our code up to speed? Is there anything changing? You certainly have an approach with Amplication. Generative AI may play a role, maybe not. How is this changing?

Yuval Hazaz:
So usually when talking about technical data and modernization of code, usually the business logic is not the essence. The business logic is fine. You take an algorithm in one language and maybe you want to convert it to another language. The big problem is the actual infrastructure is the actual frameworks, the code itself that runs everything end to end. So it may be the database, the compatibility between the database and the ORM, the APIs, the different, I don't know, security packages and so on. And this is exactly what Amplication doing best. So Amplication helps here in two fronts. One of them is if you just want to build the best code without dealing with technical debt and without giving up on the quality of the code, when you use Amplication, you get the best code ever with all the best practices, all this data. You just need to be focused on writing the business logic.
And every time there is a change and a package is updated, you want to get some new stuff, you can get it from Amplication without wasting time of it. But the other side of it is even more interesting is when talking about legacy system and now you want to go through modernization. We have several very successful use cases where organization came with an existing application, legacy application. I'm not talking about Cobalt or VB6.
Talking about, let's say PHP or something that you want to migrate from and you have an existing database, you have MySQL or any other database that you want to build the new API on top of, Amplication know how to scan, understand all the schema, bring all the schema into Amplication in order to generate a new modern API and modern code on top of your existing database, and then help you even break the monolith in that case.
So you have a database with 300 tables and you want to break it into different microservices that communicate with each other, either with APIs or in an event driven architecture. You want to break it to multiple database and so on, Amplication helps you do that very easily. And then once you're there, you can obviously keep enjoying the value of the continuous generation by Amplication to keep that up to date.

Eric Anderson:
That's awesome. Maybe to push on that a little bit further, I'll throw some scenarios at you. One might be, I'm on an early version of Angular, it's going through end of life and so now I need to move either to a new Angular or to a React. Now that's front end. So it's not Amplication, but historically we've just thrown bodies at this problem. Maybe we outsource it, maybe it's our own engineers. Is there a way in the future that we could go through that transition seamlessly? And then maybe I'll throw a couple of other scenarios your way, containerizing applications.
I think a move to the cloud feels like a big migration that a lot of the Silicon Valley's through, but most of the world has yet to go through. And then finally, if I want to go from a Windows Server, C# world to something like Linux, is that another type of migration? Does Amplication play a role in any of these? And also what does the future look like for people going through those migrations beyond Amplication?

Yuval Hazaz:
Obviously we are just, I don't know what is, one year and two months since ChatGPT was initially announced. I think that was last November or December. So we are very early in that and already progress is overwhelming and I can't really imagine what will be happening in two, three, four years from today and the concept of understanding code and know how to migrate from one language to another. Probably that will be there. Probably that would be easy. That will be commodity just, "Okay, I want to do it. There is a tool to do it."
It may be within Amplication and maybe some other tool. Right now we're not focusing on that area specifically, but obviously this is something that is part of our world in general. So AI will take a part in that for sure. There are different questions that arise when you use AI.
There is the IP thing, can I use that code in production? Where did this code came from? What type of data was used to train this model? All that questions. Second, what is the quality of the code? Can I really trust it to go to production? Because once again, when I'm using Copilot to generate the function while I'm writing on VS Code, that's fine. I see the code. I see the 20 lines of code that was generated in the best case scenario or a test that was generated, that's fine. But when you want generate an entire foundation and infrastructure of an application, that's another story. You need to get this trust and you need to get the understanding of what's going on with the code. When talking about migration to the cloud, obviously containerization is the easiest way. Sometimes you just take legacy team, Dockerize that and put it on the cloud, but that's maybe first step.
But then you really want to modernize your code, you want to use cloud services the right way, you want to break the monolith, you want to be able to enjoy the possibilities and the value of the cloud and scaling and all that. Like I mentioned, this is kind of the use case I mentioned before, when Amplication helps in breaking the monolith and migrating everything to modernization, eventually it's also kind of fitting each other.
The way I look at it, the way I see it, it's like AI will help in migration, that Dockerization and containerization is part of it. Obviously migrating from one code to another or one language or another also plays a role. But I do expect that whatever we can imagine now will be very easy to implement in A-O-2 and it'll even come with a lot of things that we can not really imagine yet.

Eric Anderson:
Well Yuval, what you've built with Amplication is well received and it's going to be part of that future. Can you let folks know how they can get involved if they haven't already, if this discussion has piqued their interest?

Yuval Hazaz:
Absolutely. So go to Amplication.com. There is a link to our Discord server. This is where our community running. This is also where you can get support from the community or from our core team. Go to our GitHub repo. If you want to contribute, you can just find issues that open for community or good for first time. And if you want to start there, find an issue to contribute. We are always happy to get contribution. We are always happy to support the community doing that. This is where we are.

Eric Anderson:
It's a great place to be. Thanks Yuval.

Yuval Hazaz:
Thank you very much. Been pleasure being here.

Eric Anderson:
You can subscribe to the podcast and check out our community Slack and newsletter at contributor.fyi. If you like the show, please leave a rating and review on Apple Podcasts, Spotify or wherever you get your podcasts. Until next time, I'm Eric Anderson and this has been Contributor.