Nader discusses the impact serverless infrastructure and technology will have on full-stack development. He introduces the workflow that gives front-end developers the tools needed to build full-stack applications.
Nader Dabit is a Developer Advocate at Amazon Web Services. He recently published a book called Full Stack Serverless that will be released in Novemeber 2020. You can check his book out here.
A lot of the things we have to do in web development require a lot of work, time, and effort. Abstractions help lessen the amount of work we have to do. We want most efficient abstraction.
We can get ahead by focusing on best abstractions.
The old front end stack looks COMPLETELY different from what we use now.
The old stack was HTML, CSS, jQuery.
The new stack is huge. We still use HTML and CSS. But there are so many tools, languages, and frameworks front end developers are expected to know a whole lot of different things.
Why has front end engineering become so complex?
There are few things that have contributed to the high expectations employers, fellow developers, and users have for front-end developers.
-
SPAS- Single Page Applications by big companies like FaceBook have a great user experience. So everyone wants to imitate this and do this too.
-
Multiple Targets- Think about different devices. Access patterns on the backend look different for different devices. This adds complexity.
-
Increased user expectations- Because of the high quality web applications bigger companies are able to produce, user expectations are a lot higher.
-
Microservices
-
More powerful devices- With better hardware and more powerful devices, people can do a lot more with their front-end code.
Is there a way to solve these problems easily? How can smaller teams with small budgets meet these expectations? This is where front-end abstractions come in.
Here's a list of some of the front-end abstractions you might be familiar with.
-
Create React App
-
NextJS/Gatsby
-
React Native
-
Styled Components
-
GUI'S
-
Managed Auth
-
Managed GraphQL
These abstractions don't mean that there's no need to know how these things work under the hood.
Back-end development used to look a lot different than what it does today.
Servers and infrastructure was often in house. But thre are problems that come with have on premise servers and infrastructure.
Having everything on premise meant...
-
if your office somehow got destroyed, your website or app would no longer work.
-
in order to service users across world wide, you would need too maintain servers across the globe. Otherwise, users in different regions would have a hard time accessing your website.
How were these issues solved?
Cloud and serverless technologies are how we're able to solve these problems.
With cloud...
-
we don't have to deal with maintaining servers.
-
we still have to worry about scaling, uptime, updating, and server patching.
With serverless...
-
we don't have to deal with maintaining servers
-
there's no need to deal uptime, updating, and server patching.
Serverless is becoming the better solution
What's next after serverless?
Cloud Computing Simplified- A Berkeley View on Serverless Computing is an interesting read on this subject.
Nader's biggest takeway from this paper is that serverless computing is made of two componesnts - functions as a service (FaaS) and back-end as a service (BaaS).
Examples of BaaS include...
- Firebase
- AppSync
- Algolia
These are all Managed Services
The Berkely paper also predicts that...
-
more BaaS storage services will become available - like MongoDB, FaunaDB
-
serverless will become simpler - learning curve was pretty steep. Eventually it will become much easier.
-
serverless will be much cheaper than servers, regardless of provisioning
- Sometimes servers are still cheaper especially for bigger companies that have higher traffic
- The standard now is that most start ups or business that have inconsistent user traffic utilize serverless
-
serverful will become less important than serverless
-
serverless will become the default paradigm in cloud era
Serverless is more of a spectrum than a concrete standard. Ben Kehoe is a huge propenent of this idea.
Here are some things to check for when it comes to the serverless spectrum:
-
Provides servicefull services and functions as a service
-
Tighter correspondence between resources used and resources billed -> paying for what you use versus what's been provisioned
-
Smaller and more abstracted control pane. This means that you'll have less code to worry about. No more infrastructure code writing. Managed services help take off some coding burden too.
Serverless functions and servicefull services are two things on the serverless spectrum. But what do they do?
With both serverless functions and servicefull services ...
-
we don't have to worry about server operations
-
we can scale seamlessly
-
we don't need to manage uptime
-
we pay variable expense instead of a fixed expense
Servicefull services give us some extra capabilities.
-
Codeless - meaning no backend code implemented on the frontend
-
Assume responsibility for providing a defined set of services
The great thing about this is that you can do a lot with a just a few resources. On the flip side, these things could also limit you if you need to do something out of service scope.
Here are some examples of servicefull services:
-
Cloudinary
-
AuthO
-
Algolia
-
Netlify/Amplify
-
Appsync/Hasura
-
Rekognition
These are managed services.
Data is very important. But it's a bit more difficult to abstract that layer away. How can we do that?
This is where GraphQL comes in. GraphQL offers a menu of what's available. What does this mean? It means that it makes it easier to digest data.
Microservice architecture is becoming very popular and whidely used. API gateways have improved with microservice architecture.
Without microservice architecuture, API Gateway have end points that send requests to microservices. The problem with this is that there are different implementation details that differ across different services. This slows down developer velocity becuase there is no consistetnt API data on the backend.
GraphQL can help solve these problems. GraphQL gives us a consistent API gateway. GraphQL abstracts away the API layer, increasing developer velocity.
GraphQL also offers schema centric development. This means we have...
-
unified data graph
-
single entry pint
-
front end and backend in sync
-
type safety throughout
-
simple accesss tp data per client
-
consistent API to microservices, lambda functions and databases
What exactly is full stack serverless? Here are some key characteristics of full stack serverless:
-
Heavy and intentional use of managed services
-
Serviceless functions are used to fill in the gaps
-
Custom client SDK's for API interactions
-
GraphQL is the main data source
-
Agility is a key market differentiator
- Increased developer velocity and efficiency -> Do more with less
-
Code is a liability
-
Front-end skillset increasingly valuable since a lot of front end stuff isn't easily abstracted away
-
Deliberate focus on not reinventing the wheel
-
Defintions of front-end vs back-end vs DevOps vs full-stack begin to blur
Here are some of the benefits of FSS:
-
Front end devs move further up the stack
-
Increased developer velocity and efficiency --> Do more with less
-
Decreased comlexity
-
More secure, reliable and scalable
Here are some of the drawbacks of FSS:
-
Increased risk when service is no longer available and you have no control.
-
Predefined feature set defines available functionality
-
Bleeding edge
-
Vendor Lock in
How can we build FSS apps? There are 4 pieces
-
Manages Services
-
Serverless GraphQL
-
Serverless functions
-
Web/mobile framework
What are some FSS tools?
-
Cloudinary, AuthO, Algolia
-
Hasura, CosmoDB, AppSync
-
Netlify, Now, Azure/GCP/AWS
In conclusion, we can define full-stack in the era of serverless computing like this:
-
The definition of front-end, back-end, DevOps, and full-stack begin to blur
-
Front-end skill set becomes increasingly valuable
-
Serverless becomes the default computing paradigm
-
GraphQL becomes increasingly important
-
Teams organized by feature vs platform or stack
Thanks goes to these wonderful people (emoji key):
 Ceora Ford 🖋 |
 Lauro Silva 👀 |
This project follows the all-contributors specification. Contributions of any kind welcome!