Why write this article?
This article is meant for back-end developers, who does have strong back-end practices - in languages such as Java, PHP, and C#.
As a PHP developer for many years, sometimes learning a new piece of front-end technology can be a steep learning curve.
And perhaps today, you're curious about serverless. And how it could benefit your technology infrastructure in your business / personal project, and wanting to "give it a go".
What is the serverless framework?
As the Wiki describes [R.1], it is an open-source framework written using node. serverless is the first framework developed for building applications on AWS Lambda [I.1].
However, it is now expanded to more supported Serverless service providers, such as Netlify, Google, Microsoft (Azure) and more.
Why use serverless?
As developers, we only want to focus our time 'coding', rather than fiddling / tinkering with server configurations, network infrastructure and cloud networking in general.
It offers great scalability, more flexibility, zero server management and faster release time - altogether at reduced cost.
How did I learn to use serverless?
There are a couple of prerequisite learning criteria(s) that did help myself explore and understand how the serverless framework works.
Some of the early steps I began with:
- To build an understanding of how
node+expressapplications work (expressis not necessary, using any web application framework will do for your first demo). - Pick a
serverlessprovider to work with (I chose AWS, because there are already reliable existing real-world examples and open-source content to compare to, with my first demo). - Based on the
serverlessprovider picked, I did explore howserverlessservices are deployed and its general architecture. For example, 'applications' vs 'functions', why do you need an API Gateway, and more. - While learning the
serverlessframework (from official documentation) and coding a demo project in parallel, trial-and-error persisted with integrating third-partyserverlessdependencies involved - such asserverless-offline.
What I've learned so far?
Prior knowledge of knowing how to build a node + express application was crucial, and beneficial. Next, extending your project with typescript is also beneficial but optional.
The express package is definitely built to be "modular" with other dependencies, especially for extended express middleware.
In regards to using nestjs [I.2] framework (I relate this framework with Laravel / Symfony PHP frameworks), for a serverless project, the comparison with express does highlight a lot of the pros and cons, of building a serverless node + express app vs. build a serverless nestjs app.
I ended up building this serverless boilerplate, which is till this day, a work-in-progress project - there's always room for improvements, and following the serverless framework updates.
Github: https://github.com/entwurfhaus/serverless-express-typescript-boilerplate
That's it!
I do hope this article does provide additional insight, to why serverless should be learned and considered to be your next application architecture solution.
Index
- AWS Lambda - a
serverlesscomputing platform provided by Amazon as a part of Amazon Web Service. - NestJS - https://nestjs.com/
References
-
serverlessframework Wiki - https://en.wikipedia.org/wiki/Serverless_Framework -
serverlessdocumentation - https://www.serverless.com/framework/docs/ - JAMStack - https://jamstack.wtf/
- NestJS - https://docs.nestjs.com/
Top comments (2)
When I read Serverless, I always have dev.to/alexander89/did-you-know-lo... in my mind.
What do you think about the local-fist cooperation pattern.
Thanks @alexander89 ! This 'pattern' (not 'methodology'), along with the five design principles and more got my brain juices flowing - especially the 'plethora' of real-world examples, to provide additional context and to explain how
local-first cooperation pattern(local-first-cooperation.org/docs/a...). It is quite the read, unlike Uncle Bob's SOLID design principles piece.In short, I am still wrapping my head around the pattern 'concept' itself. The introduction piece did help myself the core concept of it, the IoT devices for example made sense - and some emphasis on 'decoupling' too (sounded like the other goal is to create less dependencies, between services).
Either way, thank you for sharing this pattern! We should always be open-minded to new patterns, methodologies, design principles and modern practices - especially when web development now is 'rapid' than (a decade) 10 years ago.
Lastly, my goal now is to 'attempt' on practicing this 'pattern' - through 'exercise / practice / real-world project examples' I can understand the concept of the pattern a little bit better.