 It's a little fragile. Hello, everyone. Thank you for coming to this Elixir specific presentation today. And I'm Neha. I'm currently working as a senior back-end engineer. I have served as a consultant specifically working on Google Cloud projects for the last two years before my current role at Yoji. So most of my presentation and my experience today is going to be based on my learnings from these two years. So without a due, let's get started. And Elixir is a relatively new programming language compared to other established languages like Python, Ruby, and things like that. So it doesn't have a lot of followers yet in scale, so which is why I decided to do this presentation. Particularly in Singapore, that's not a lot of people using Elixir at the moment. But before we get to that, let me introduce you why I chose Elixir and share my experience with this language and basically background. Elixir is created by one of the core Rails team members, Jose Valim, as you can see here. It's a functional programming language. Elixir is comparable to Scala from Java Land. Basically, it runs in a virtual machine called Beam, whereas in Scala it runs on JVM. And it has a very functional approach, unlike its core inspiration, which is Ruby, because Jose Valim was from the Rails team and Rails is actually a project of Ruby. So who uses Elixir? There are actually a lot of high-profile companies using Elixir. And you would see that I actually slipped in my company in the elevator, just to show. So why Elixir? Why not other languages? If you are, say, from a programmer's perspective, why Elixir? Or if you are in the C level, why Elixir? Today I'm going to focus on answering these questions. I have tried to keep it as neutral as possible without going too much into technical details, without also making it too superficial. So first thing is Elixir is very, very easy to understand. And somebody getting into the world of programming language as well can pick up something like Elixir really fast. So before this, we used to conduct training camps for students and graduate from local universities like NUS, SMU, NTU. And Elixir was the language of choice for this reason, because it's super easy to pick up, even if you didn't know much about programming languages, you could spend like half a day reading through the documentation and playing around, and you will be somewhat proficient by the next week. So this is the promise of Elixir, in my opinion, compared to other programming languages. And the simplicity comes because of a few factors like its syntax, its concepts, and things like that. The number two reason why Elixir is. Elixir is built on top of Erlang. And actually, Elixir code compiles to Erlang and runs on the beam, which is the Erlang virtual machine. Erlang, as you may or may not have known, has been the language of choice for the telecommunications industry, where reliability, scalability, and all these are key factors for the language. So you are making a phone call to somebody. You don't want the call to hang up randomly in the middle. So that's the kind of reliability we are looking forward to. And Elixir gives you this promise because it's running on top of Beam and. It has some underlying philosophies, like, for example, the fault tolerance part. If your code is somewhat messed up, it's not very good. The philosophy here is to let it crash. And let it crash, let it tell you why it's crashing, and so that you can go in and fix. This is basically the philosophy. It will not, like other languages, stop the entire application from running just because something has crashed. Of course, this also depends on the way you architect it primarily. But for the most part, this is what is exciting about this programming language. And finally, it's a compile language, so which means unlike, say, Ruby or Python, this is not a language where you write code and you only discover bugs when you actually execute that code. Whereas for Elixir, when you have finished developing something, during compile time itself, you will discover some bugs that you can actually not push to production. So yeah, let me start with the concepts. The concepts are pretty simple. So like I said, they don't have any concept of classes. Rather, there's modules and functions. And they introduce two new concepts called as pattern matching and PIPO operator. These are the key concepts I'm focusing on. There's actually many more details I have missed out simply because of the title, which is a gentle introduction to Elixir. So feel free to later check out the documentation for this language. But I hope I will allow you to explore the language in a very easy way. So this one slide looks very simple. But actually, 90% of the Elixir code is just going to be like this. There's a module definition on the top. So I'm defining a module called Hello World. And that is a function inside call wish. And it's returning a string Hello World. It's very simple. This part down here, I'm not sure if it's very clear, but this is actually how I would call or execute this function. I will put the module name. And then I will just call the function. And it will return me this value. So this is very simple. This is like, you can do this right now. And you can tell people I know Elixir. Yeah. So this is one important concept before you can go and tell people, actually, you know, Elixir. I'm sorry, I lied. Which is basically pattern matching. If you don't understand this concept, this language may be a little bit difficult. But once you understand this, this is very powerful. This will allow you to write really fault tolerant and scalable applications, in my opinion. So the first line is similar to any other language we've done. So we say x is equal to 1. And the value of 1 is assigned to the variable x. But in Elixir, you can do 1 equals to x to check if x is actually 1 or something else. So I go to the terminal. I type x is equal to 1. I set the value to 1. Now I'm checking here, actually, 2 equals to x means I'm trying to see if the value of x is 2 or not. In other languages, you could do something like x double equal to 1. That will give you a true or false. But in Elixir, this will try to match and it'll actually fail. And you can write some code to actually stop it from throwing at us, so which is the next concept I am going into, the basics of a switch case. It's similar to the previous example, except I have a variable a on top. And I have a certain set of conditions defined, 1, 2, and this underscore. So if I assign a value a equal to 1, and I execute this particular line of code, it's going to tell me a was 1 because it'll just execute this line. It'll skip everything else. If I assign a equal to something else other than 1 or 2, then it will straight away go to this underscore. Underscore means match everything. It's like a catch all phrase. It's a default kind of thing. So it will simply echo a or something else. So far, do you have any questions? It's just a basic. It's just basics. So why is this powerful is because you can do some advanced stuff. Like, I'm throwing in another programming languages. You would call this an object or maybe an array of items. In LXC, we call it a tuple. But simply because of the lack of time, I'm not going into too much details about the data structures. But please, I hope you can just translate the analogy to other languages. So we have an object with 1, 2, and 3 values. The middle one underscore says that I can pass in anything other than 2 here. And it will still match the first line. So for example, I pass in 1, 99, 3. It's still going to match the first line. But if I pass in anything else other than this format, it will go over here to the default catch all phrase. So this is powerful because if you say, for example, writing API endpoints, like API integrations for third party services, you can match responses. If I'm calling out Twitter's API, I can match JSON responses in this manner. And I don't need to write so many if or else conditions, which I would need to do in other programming languages. For example, if Twitter's response says something like success, and then pass me an array of posts, or tweets, or whatever, I don't need to check if the key success exists or not. In LXC, I can simply put it on top of there, and then match is just going to be two conditions for me, versus some other languages. So for this reason, I feel it's very powerful. Then the next building block is con. It's similar to the case. You should know the difference here. It's called case. And the other place, it's called con. This is similar to the previous example, except this will always try to match whichever equates to true. So in this first condition, 2 plus 2 is not equal to 5. So it will not match. 2 into 2 is not equal to 5. So it will not match. This one, we are explicitly saying this is true. So in this line of code, this will always equate to true and match. This will always be called as it relates to true. Yeah. So these are the three fundamental building blocks that you can use to write real world applications. If you take information from these three slides, go home and write an application today, you will be actually able to accomplish a lot more than you would with other programming languages. So this is a real world example of an e-commerce platform that I built for one of my clients. With his permission, I'm able to reproduce it here. So what happens behind the scenes in Elixir code when you add something to cart? I'm able to use something called as the piping operator over here that will take the response of this value and pass it as the first argument to the next function. So this particular function is returning me a product variant ID. So I'm basically going one by one by one by one through these steps to make sure everything is valid before you're able to add to cart. This is the power of this language, whereas if let's say we use JavaScript, for example, Node.js back in, then you would probably have a lot of callbacks, like call this function, call this. For a developer, it costs a lot of time because you need to jump through your code base up and down, up and down, up and down. Which one is calling where? Some things like that. From management perspective, it costs you more developer time. It's not only that, you are also going to introduce a lot more errors. For example, if you wrote the same thing with JavaScript, simply because you're writing more lines of code. So purely with these things, you can see how Elixir can scale really well. So scale in a sense from performance point of view as well as from development experience point of view. This is another example where we are actually making an API call and checking if the API request was successful or not. So I'm simply trying to match the status code over here. Status code 200 means it was successful. Then in that case, I return the URL. It is returning to me. Otherwise, I'm returning the reason why it failed. If this did not work out at all, then I'm throwing a generic error. I have defined somewhere above this code. These are just some examples. So when to not use Elixir. Elixir is not a good choice. If you would like to do a lot of data heavy operations, like crunching numbers a lot, those kind of things. So in such use cases, I recommend going with Python or Pandas or maybe even R language. But if you are writing a lot of crowd applications or enterprise level applications where you don't need to do a lot of number crunching, but rather add in data through forms, nested data, all these kinds of things, Elixir is very suitable for. Let's talk about Phoenix. Phoenix is a web framework built on top of Elixir. It's also created by one of the co-rails team members. His name is Chris McCord. It's highly opinionated. And the difference between Phoenix and other frameworks out there is Phoenix is probably opinionated in the sense where you need to know or understand something called DDD, which is we called as domain-driven design. Even before you go and write in these applications, a good idea would be to get a piece of paper, draw in those diagrams, try to understand which entity is calling what or how they are going to be structured, plan your application a little bit on the paper first or maybe on a board, and then you are able to write really reliable and really highly scalable applications with Phoenix. And the good news is Phoenix is actually very big enough friendly, and it has excellent documentation for people to pick it up as well. So for this, I think I still have enough time to do a very quick demo. So if somebody could do a stopwatch, we can try to actually write a new blog application. Like really fast, two minutes is all I probably need. Can somebody set up a timer? OK, thank you. So first thing I'm going to do, I'm going to create a new application or rather, I'm going to create a new Phoenix application. Yes. Oh, sorry. This command is actually creating a new Phoenix application. It's going to call all the necessary libraries and packages that are installed by default. I think this is probably the longest part of this demo because the actual code itself is not that it's not going to take so much longer. OK, sorry. Is it two minutes already? Yes, it's started. OK, you can probably keep counting. We'll see how long it actually takes. It should be done in about 30 seconds or so. Let's see. OK, let's come back to this after I finish my slides. OK, it's done. So I'm going to create, for a basic blog, we have a title and a content column. So let's just create that. mixphx.gen.html title will be string, content will be text. This should be content. Oops, sorry. I'm going into my application directory and now I'm executing this command. Sorry, I need to define post. I need to tell it. This is going to be my ddd. The contents over here is going to be my ddd entity. Post is going to be the actual thing that I'm generating. So yep, and it already created the database, necessary database, and stuff. We can just simply go in and run the server. Do you want to make it bigger, please, from the back? It's not that easy to see. OK, it's OK. So I can simply go in and start my server now. So it's going to compile all the files. It's failing because it cannot connect to my database. But actually, if I go here back to my demo here. Sorry. Let me minimize this. Let me go back to my browser here. I'm not sure if you're able to see this. So Phoenix has actually generated my application server here. And I can go in and create my posts once I have configured my database. I know this is not an optimal demo, but actually it's quite fast. If I was not talking here and doing this, just a bunch of few commands. Anyway, for the purpose of this demo, I'm leaving these commands over here, documented. Please feel free to maybe later get a copy of this and try it out. And I can assure you it's not going to take more than two minutes. So anyway, let's go to the advantages of Phoenix. Sorry if you were taking photos. Let me give you maybe 10 seconds. Let's go to the advantages. Phoenix is a very highly modular application simply because of the language. As we saw, we don't have the concept of classes. We don't have very weird concepts like we have in other languages. There's no patchwork going on under the hood. It's just all modules and functions. So you can go in and define arbitrary directories, modules, libraries, maybe specific only to your enterprise. You can have custom authentication. You can throw in whatever you want. And the framework will scale really well. It also scales really well in terms of developers for Phoenix, not just for LXL. And Phoenix supports microservices architecture out of the box. So you are able to generate something called as an umbrella application where it will go in and create so many sub-sub applications under one big umbrella application. That's why it's called an umbrella application in the first place. Although it's a little more complicated and those are more suited towards teams. But Phoenix really scales well in this aspect. Umbrella applications are also quite popular and in production in many of the companies listed previously. So those were very high-level and somewhat technical introduction to Phoenix and LXL. Now let's get into the Google Cloud part, which is particularly App Engine. App Engine is a really, really awesome platform, so much so that you can probably call me a fanboy of App Engine. Because I almost always use it for any of the client projects that come to me. And I prefer this over other things like Kubernetes, EC2, even your raw compute engine, things like that. Because it makes me, as a developer, forget DevOps. For the company, it makes them very confident. So they don't need to worry, like, when is my application going to go down? Some dependency was not fulfilled and things like that. And it scales really well. You can have multiple services defined under the same App Engine project. So let's get into a little bit more detail on why App Engine. App Engine, like I said, is fully managed by Google. It eliminates DevOps. Whereas for Kubernetes, I think you need a certain level of DevOps experience. And the configuration is a little bit more verbose than Kubernetes, in my honest opinion. Compute Engine, I would say, requires the most DevOps of all the products out there. Then finally, Cloud Run. It's suitable for small applications, particularly things like chatbot can benefit from Cloud Run. I mention only these four because these four play really well with Phoenix and Elixir in particular. There may be some other offerings for other platform programming languages. But these are my focus for today, particularly. So why App Engine? App Engine allows you to have different environments. They call it standard and flexible. Standard is something that is just there out of the box for you. So unfortunately for Elixir, standard is not supported. Only flexible is supported. But if you have the option for standard, it will mean you can even run an App Engine instance for free without paying anything. They have a free tire for that. But whereas for flexible, there isn't a free tire, it's slightly more expensive. But maybe for personal projects, it may be more expensive. But if you are working on a client-facing project, $100 a month or even $50, $60 a month only for your server is totally worth it if you can avoid the DevOps cost. DevOps is going to cost you a lot more time in comparison. So compared to the alternative, I think it's very good. If you wanted to install, get started with Google Cloud App Engine, there's only three steps in my opinion. That's first thing is you need to install the Google Cloud CLI. This is the tool that will run on your terminal, in your computer, platform-specific, Windows or Mac. Then you will need to set up a configuration file called app.yaml. This is where you'll specify how many servers you want, how you want the App Engine to scale, how you want it to manage in case there's a certain surge of traffic, how you want to balance it between applications and things like that. And finally, you just need to type in your command called gcloud app deploy. Then that will just put your local code base onto the cloud. So Google Cloud App Engine is really convenient and highly worth it, in my opinion. So this is a sample app.yaml. In this particular example, on the top, you can see I have a configuration value called staging. So if I were to access my application, it would be something like staging hyphen, myapplication.appspot.com. I can then map this to my own custom domain, which App Engine provides. Then I specify which environment I want to run, standard or flexible. So here I am choosing the flexible environment. And I'm particularly specifying I want to use the Elixir runtime. So the good news is Google actually provides a supportive runtime for Elixir in particular. So we can straight away use that. Entry point is the command, the first command that it will run once your application has been, like it's the boot up command for your application, the command that needs to start up your application on the cloud. Then you can specify environment variables like database, usernames, passwords, things like that if you wanted. Finally, I think the most perhaps important feature or my favorite feature of App Engine is this particular setting over here. If I have my database server running on Google Cloud and I want my application to talk to it, I can simply specify this socket URL, which I can find inside my database setting. And Google Cloud will actually go and directly talk to it. I don't need to specify IP addresses. I don't need to expose my database to the outside world or create network roles to make sure only my application can read it and write it. So this is basically all you need to actually deploy application to Google App Engine. I'm saying you just copy paste this file into the blog application we created previously. You just paste it there and run those three commands. You are able to deploy it to the cloud. So you can see it's highly portable. I can take this to another provider, exit the Google Cloud platform in the future if I wanted to. So it's also a very good selling point for C-level as well. So I think I have discussed the first point already. This is how my URL will change based on my environment if I'm on staging or production as I set in my app.yaml file. The other awesome feature about App Engine is it'll actually go in and create different versions of your application as and when you push. Now this is a setting you can disable in the app.yaml file. But if you don't disable it, it's going to do this because let's say your team actually deployed something to production which contains a severe bug that affects a lot of your customer. And let's say it's on a weekend. Your team is not reachable. You, as from the management level, you can simply log in into your Google Cloud console, change what percentage of traffic should be redirected to the old version. So you can technically go in and redirect to the old version without writing a single line of code. All you need to do is just log in into the Google Cloud console. I think this feature is very powerful in the sense that you don't need to rely on your technical team to push something that your developer may have screwed up or something like that. The other things that I like about App Engine is, number one is the security part. This is also a very, very useful feature. For example, that was one project where we were dealing with the government and their requirement was the data needs to be inside of a certain country and the application also should be able to be able to access only from that particular certain location and no other single request should reach or penetrate our server. This was a huge project and it was a very critical project. If we screwed it up, we had severe legal consequences, basically for noncompliance, because this is the government we were talking about. This is where I found Google Cloud IAP. Cloud IAP is identity access, program or protection or something, but it will simply put a firewall in front of your App Engine so that not a single request will pass through to your application without you having the right credentials. I can set up which Google accounts have access to my application. This means I don't even need to take care of authentication in my application. I don't need to write any code, make sure username passwords are checked and all those things. I can simply slap this on top, go into my Google Cloud console, and select who are the users with which Google IDs are able to access my application. One fun fact is this application was deployed two years ago. It's still in production and the contract had ended a long time ago. I got a support call maybe six months ago and that was for a very, very minor issue. I haven't heard back from them at all. The application is running with probably hundreds of thousands of records being inserted and deleted every day. This is the real power of App Engine. This is all done by one guy, it's me. Yeah. So I think this is a really cool feature of App Engine. Anyway, like I mentioned before, it has excellent Cloud SQL integration. That means you can create MySQL, PostgreSQL, SQL databases, and talk to them with your app. And I think I already mentioned the other points before. One more cool thing is App Engine has inbuilt image processing capabilities. Not many people know about this. So what that means is if you have a user-facing application, like you are creating your own Facebook where you need to generate user-profile images, then App Engine provides you a feature where you just call the location to the image with just some query strings of what width and height you want. The image will be screened in real time, and it will be processed in real time and displayed on your front end. You don't need to write any or you just need to copy paste some code they have in documentation and deploy a service for this. This is really cool, and not many platforms actually have this feature. In fact, I don't know of any platform that has this feature. So yeah. So I think I have shared most of this with you before. For CEOs, it's faster time to market. For CTOs, it's really portable. As we saw, the configuration is really minimal. For developers, there's really no comparable alternatives. To be honest with you guys, to be fair with you, I tried out alternatives from AWS. They have something called Elastic Beanstalk. And it's really the worst experience of my life. I'm really telling you. I'm just being honest. You don't want to be in a situation where it throws out random errors. And it's so cryptic that you need to search AWS developer forums. And those questions are all unanswered, unless that guy who posted the question comes back and answers it himself later. It's things like that. So I don't think of any other alternative out there that can beat App Engine. So yeah. And last part, I think we are coming to a close. This is about me. So about two years ago, same time, I lost my job. I was kind of stuck in a dilemma where I had to go back to my hometown, or I had to stay in Singapore for a year and try to do something about it. So I chose to stay here for about a year. And more than that, obviously, because I'm here now. I was able to pull out 20-plus clients, single-handedly, develop applications, deploy them in production, deliver happy customers, basically. Keep them happy until today where I can go and catch up for coffee with these clients. Everything done while having so much of constraints, financial constraints, like having to pay the rent without a job, take care of so many, so many issues, single-handedly fight them. This, I would honestly say from my heart, is not possible with any other platform. And Google is definitely not paying me to say all this. But App Engine can make this possible. These three combinations, App Engine, Phoenix, and Elixir. With these three, somebody like me, who just, I was just getting started with Elixir at that time, who just got started with Elixir, was able to pull this off. So that's how powerful this combination is. So I hope after this presentation, although a bit fast maybe, you would be able to hopefully experiment with it. And if you have any more questions about this, please, please feel free to contact me. I'm leaving my contact details here. Anyway, we also have, I'm from the official Elixir community in Singapore. So we have an official meetup. We scheduled meetups once in a few months. Definitely please write to us. So I can, we can focus or create more topics based on expertise level or what kind of topics you want or things like that. The other thing is, this is my company that I'm working for. So we are also hiring for Elixir positions. So if there are any Elixir, aspiring Elixir developers here, please contact us. And any queries, please feel free to just contact me. Thank you.