Slobodan Stojanović

Hey,

Claudia API Builder is just a Node module that does simple routing and few other necessary things, but the layer between browser and your Lambda function is Amazon API Gateway. It listens to HTTP requests and then triggers your AWS Lambda function synchronously (it waits for the reply). But it also does much more, for example, auto-scaling, security, authorization, etc.

It's not like AJAX XMLHttpRequest, as that one is used to invoke HTTP request asynchronously on the front end side. API Gateway is on the backend, and it invokes your Lambda function synchronously.

Second chapter of our book talks a bit more about API Gateway integration.


Cheers,
Slobodan

Congrats to everyone! 🎉

For everyone else, if you want to get our book, use claudia40 promo code for 40% discount.

Thanks! The only prerequisites for our book is basic knowledge of JavaScript and Node.js (a few tutorials are a good starting point), and very basic understanding of AWS, but we tried to put enough links that you can follow and learn more about AWS services, so that shouldn't be a blocker.

Can this book be a good self-starting point to enter to this new world ?

I hope it can We tried to write the book in a beginner-friendly way, and feedback so far sounds like we managed to do so, but I would love to hear your feedback

Hey, sorry for the late reply.

As you said, AWS Lambda and other AWS services used for a common serverless app (i.e., Amazon API Gateway) are PCI compliant. When you are using an Express.js with AWS Lambda, your Express.js app (which is actually Node.js app) is running inside your Lambda function, without any connection to the outside world, so it's definitely still PCI compliant. As shown in the attached image (from chapter 13 of our book), your app receives an HTTP request through Amazon API Gateway (PCI compliant). API Gateway then triggers Lambda function, that is also PCI compliant, and your Express app runs inside AWS Lambda.

We cover some of these questions in chapters 12 (payment via Stripe) and 13 (Express.js app) of our book.


Cheers,
Slobodan

Hello!

This is another great question! It will be really hard to answer it with a few sentences, but let me try.

but the real world is also a team to manage and a client to convaince  

I know, I also have clients and even multiple teams. From my experience, clients don't really care about technology, as long as it will give them the product they want, with a reasonable cost of the infrastructure. There are exceptions, of course, but most of our clients don't build that kind of specific apps. Serverless often allows us to deliver product faster, and to decrease the cost of the infrastructure, for example, our product infrastructure cost for March was $0.17 for million and a half function executions. Pretty sure most of the clients will not have any problems with that

For team, it's a bit different and it can be a bit more complex. But again, from my experience it's not that hard if you talk to your team and try serverless for some smaller project or part of the project.

I think this article will answer most of the questions from your list: http://medium.freecodecamp.org/the-best-ways-to-test-your-serverless-applications-40b88d6ee31e.

In short, our process is:

Developers have their own environments (it's cheap, why not? )

Features goes through gitflow like flow

Builds are automated using CI (CodePipeline)

This question is probably the most interesting one:

What about performance issues these architectures may enconter and your advice to avoid them ?

With serverless, you need a mind shift to start getting serious performance gains. But few really short answers (our book is trying to give some good practices in each chapter):

I would use Node.js, Python or Go with AWS Lambda, as they have the best startup performance

Try to keep your functions small and not to add too many dependencies (i.e., don't install unnecessary node modules). Packages below 5MB will have the best startup performance (cold start thing)

Use a decent architecture, I would recommend Hexagonal Architecture, and I have a few articles describing it (i.e., this and this, ignore the title, it was marketing vendor lock-in in the cloud is not a problem that you'll have unless you do something really bad)

Hope that answers at least part of your questions.


Cheers,
Slobodan

Hey,

Good question.

First, few months ago, AWS extended maximum execution time to 15 minutes for AWS Lambda. Also, AWS Lambda is not really stateless, it's more share-nothing, as you can store some data in /tmp folder for subsequent invocations, and they may or may not be there, depending if you are getting the same container/micro VM or not.

For security, I would say that serverless is more secure than what we had before. Let's talk about serverless functions, as something that holds and runs your code:

Your average function runs in less than 300ms, then it's gone. It's really hard to hack something that is available for less than a second periodically.

Your functions can and should have fine grained permissions, that make them more secure than ever. For example, our function can read just specific data from specific table from the database, or save file in a specific subpath of a specific S3 bucket.

Your function can be triggered by a specific event from AWS platform only. For example, if it's triggered by an Amazon SNS topic message, it can't be invoked by an API request (unless you are using AWS API with your admin credentials, and if you exposed that, someone is probably already mining bitcoins with your account and a security of your function is not your main concern at that moment).

A Lambda function is read-only, except /tmp, which is temporary. No one can change your code from the function itself.

I can go on, as the list is really long, but I hope this is enough to illustrate the point and answer your question.


Cheers,
Slobodan

Hey Paul,

As I explained in some other thread, serverless is just a name. I agree it's not a perfect name, but we have a long history of unfortunate names in IT (hello Cloud, JavaScript, and many other things).

The best explanation I can offer is the one by my friend Gojko Adzic, from his old but excellent "Serverless architectures: game-changer or a recycled fad?" article:

It is serverless the same way WiFi is wireless. At some point, the e-mail I send over WiFi will hit a wire, of course, but I don’t have to pull along a cord with my phone. With serverless technologies, developers no longer have to worry about running a server process that listens on a socket, waits on a queue or dispatches tasks.

There might be even Apache below (it's not for AWS), but it's not your job to configure it, maintain it, and even know about it.

It's not exactly the same as Apache for your web app, as there are multiple pieces of the common serverless app. For example, your business logic and code will be in serverless functions (i.e., AWS Lambda), but the function is fully isolated from the external world, and you need to attach some triggers to it. If you want to make a public (or even private) HTTP API, you'll need some kind of managed API gateway (in AWS, that's Amazon API Gateway). When you receive an HTTP request, you can do different processing inside your function, but you don't have a database (or any permanent storage) inside, so you need another service for that. It might sound complicated, but it's not at all, and it's really powerful, because you can easily give different permissions to different functions in your code. Imagine that two route handlers in your Express app can do only a thing that it's their business logic, i.e. POST /books can just save a book in the database, but it can't read anything, or GET /book/:id can just read a single book, but don't have any additional permissions.

With serverless, you'll get a highly scalable, fully isolated, production-ready app out of the box. And even better, you'll pay per request. For example, my startup infrastructure costs $0.17 for March, and we had 1.5M function executions (and earned much more).

Hope that answers your question. I would recommend checking the free first chapter of our book for more info. In later chapters (chapter 13-15), we show how to use serverless with Express.js, how and why to migrate existing app, and some case studies, exactly because most of the people use Node.js with Express.js at the moment.


Cheers,
Slobodan

Hey Jose,

As anything else, Node.js can seems too hard in the beginning, but don't worry, we all went through that. There are no some specific prerequisites, you should just try to read/watch some tutorials and books, and try to build some smaller projects with Node.js. Your skills will grow everyday, and I am sure you'll be able to build amazing things very fast.

Good luck with your learning

As my friend Gojko Adzic explained: it's serverless the same way wifi is wireless. You don't need to drag a wire to your phone to send an email, but your email will go through the wires soon after you sent it. Wires still exist, but they are not your wires, if something breaks, someone else will fix them, and your wifi will just work.

Hello everyone! Thanks for having us here, and for excellent questions so far

Hey Eric,

You can use microservices and serverless together, it's not one vs other.

Serverless is basically a managed infrastructure for you. You write your business logic, deploy it to any serverless provider (i.e., as a combination of functions, queues, databases, etc.) and then cloud provider manage it automatically. You'll get auto-scaling, auto-failover, full isolation, and many other things out-of-the box.

You can deploy a monolithic application to a single serverless function (for example, AWS Lambda), but as we describe in the chapter 14 of our book, that's not an ideal use case. Much better is to split your application in multiple services (micro or even nano services) and let AWS manage them automatically. You'll see case studies in the last chapter of our book (how MindMup and CodePen are using serverless), both apps are using some kind of micro services.

For my product, Vacation Tracker, high-level infrastructure looks similar to the attached diagram. You can see a few services there, but in reality they are split into even more small functions and other pieces. We have more than 60 functions, and they communicate via Amazon Simple Notification Service messages, queues, and many other triggers.

So, short answer to your question is that you can't compare microservices and serverless, as they are different things and you can use them together. I hope that answers your question.


Cheers,
Slobodan

Hey Awais Bajwa,

There are a lot of new things going on in Node.js, but unfortunately this book will not teach you all of these things. However, it'll teach you a few things about cool new things in applications infrastructure and architecture! As you can guess, it's that serverless thing

We used Node.js as a language for all of our examples, but you can use basically any programming language to write your serverless application, and the concepts will be the same.

Why serverless? The idea is simple: it is an evolution of the cloud, you focus on your application business logic, and your vendor manage the infrastructure. You get auto-scaling, auto-failover, full isolation, and many other things out-of-the-box. And you pay for used capacity, not for reserved capacity. For example, our product, Vacation Tracker, infrastructure costs $0.17 for March for more than 160 teams using the product (and most of them are paying for it). You can read more about it in the free first chapter of our book here: https://www.manning.com/books/serverless-applications-with-node-js (see table of content or click to the liveBook link).


Cheers,
Slobodan

Hi Carl,

If you are a web developer comfortable with JavaScript and Node.js (for example, you know how to use Node, NPM and maybe basic Express.js) you should be able to follow everything in the book without significant issues. Basic knowledge of AWS is nice-to-have, but it shouldn't be a blocker for you.

We tried to make our book beginner friendly, and I would love to hear your feedback if we managed to do that.

Cheers!