• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Frits Walraven
Bartenders:
  • Carey Brown
  • salvin francis
  • Claude Moore

Serverless Applications with Node.js: why a Node website is considered Serverless?  RSS feed

 
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Hi,
I have been trying to get my head around why a Node website is considered a Serverless application  .
I don't know that much about it but it seems like it ties together resources and directs web traffic ,which is what Apache does.
I worked through a book that used Node, Mongo, Express, and Angular. It seemed that Node served the role of a server in the overall application.
It is software that is running on a physical machine much the way that Apache is software running on a physical machine and both seem to tie together other resources .

Can you explain the difference?

thanks,
Paul
 
Author
Posts: 13
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Saloon Keeper
Posts: 20655
122
Android Eclipse IDE Java Linux Redhat Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you, Slobodon, I was eagerly waiting to hear your reply.

It's true, of course. When I cobble up an app using Node Express, the app is itself a server in the sense that it listens on some designated port. As it happens, I have a very concrete example of such an app. I build an e-ink display with builtin WiFi that's stuck to my kitchen wall, and it polls a Node Express server periodically to obtain time, temperature, and weather forecast for the display. It, in turn queries downstream servers, one of which listens to remote radio weather sensors, and one of which is the National Weather Service. So it's basically an aggregator and reformatter for the display unit's benefit.

I think what we can say in brief, though is that a "server" is a generic service container like Apache, Tomcat, and the like, whereas a "serverless" app is self-contained. Like Node.js or Spring Boot. And thanks to the magic of reverse-proxying, you can set up a "server" (such as Apache, IIS or Nginx) to be the public face for serverless apps, even though the "server" doesn't contain those apps itself.
 
paul nisset
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Slobodan and Tim.

I sort of get it. I'll check the first chapter of the book.

If AWS Lambda is an example ,it seems like a serverless app is basically a series of functions with independent authentication or accept tokens as a parameter but they don't store session variables in the way that Tomcat might  .

Your application would then be whatever collection of AWS Lambda functions your phone app calls.
-Paul
 
Tim Holloway
Saloon Keeper
Posts: 20655
122
Android Eclipse IDE Java Linux Redhat Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not storing session variables is a hallmark of ReST. The advantages of using ReST are twofold:

1. If every user requires "X" bytes of session data, then the amount of server memory required will increase linearly with the number of active sessions (users). By making "X" zero, there's no added memory per-user.

2. If you don't have server-side session data, then you can deploy many servers and use a load-balancer to dispatch work to whatever server is least used at the moment. A session either ties you to only one specific server or requires a back-end session-sharing infrastructure, which adds overhead.

So with ReST you can be elastic and add/remove servers from with relative impunity.

In the case of "serverless" apps, using a ReST-style architecture can make things even more elastic, since only the app needs to have multiple copies - you don't have to spin up servers and then provision them with apps.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!