Full-Stack Development in the Era of Serverless Computing

How serverless technologies are changing what it means to be a full-stack developer.

In the past, front-end developers and front-end development was not viewed as equally important or complex as back-end development. This has changed.

Front-end development is now being taken much more seriously. If you are a front-end developer, it is now likely that you are not only in demand as much as your back-end peers, you may even be more sought after depending on your specialty.

While the back end has jumped forward in automation and ease over the past 10 years, the front end has actually started getting harder as complexity was shifted to the client space.

Because of the rise of SPAs, more complex data concerns, multiple device targets and increased expectations of user experience, client-side development has gotten more complex over the past decade or so

We are entering an era where the front end is becoming increasingly more important. Front-end developers are now shipping robust full-stack applications using almost zero back end code.

As technology progresses, abstractions get better. As you are about to see, being a front-end developer no longer limits you to only building the front-end of your application. Let me explain.

One of these is not like the others.

On Premise


These workloads still usually run on servers which you had to patch, update, and maintain uptime. Scaling is still left up to the developer or team maintaining the server.


These applications scale seamlessly and do not require any server operations.

Serviceful Serverless

He responded with a link to the talk where the term may have been coined:

While I have subscribed to a similar philosophy, I had never heard of the term until then. I had described similar ideas and labeled them as Managed Serverless, but I like Serviceful Serverless better because I think it describes exactly what it is.

Serviceful services assume responsibility for providing a defined set of services and are “serverless” in the sense that they do not require any server operations, scale seamlessly, and require no need to manage uptime but most importantly they are essentially codeless.

A few examples of serviceful services include Auth0 / Amazon Cognito(managed authentication), Algolia (managed search), Contentful (content infrastructure), AWS AppSync / Cloud Firestore (managed API services), Amazon Lex / Rekognition / Textract (machine learning services), and Cloudinary (managed image & video hosting service).

In the past, each of these back-end features (search, API layer, auth, etc..) took a competent back-end engineer weeks / months to build securely and properly.

Now a front-end developer can hook into these services and implement these features with no knowledge of the actual back-end implementation, with little to no back-end code at all, and they can do so at a fraction of the time and cost.


Less code leads to less bugs and your application becomes that much more easy to maintain.

When a new developer comes onto your team or you hand off your project to someone else in your organization, on-boarding becomes easier because the mental overhead is also decreased (there is simply less to understand).

Less Complexity

This moves the discussion from “managing complexity” to “removing complexity”, the complexity simply does not exist anymore for these features since they are no longer in your codebase.

Developer Velocity


Instead of paying an engineer x amount of dollars to reinvent the wheel, you are subscribing to a defined feature set and API and not worrying about the underlying implementation. You are also only paying for your usage (vs the up front cost of building out the feature yourself).

Sophisticated and Secure

This means you basically have a team of specialized engineers that have built out and iterated on something that you or your team simply could not do alone without investing an impractical number of hours.

They have been confronted with and solved issues and problems that you may have never thought of, “unknown unknowns” that only come with scale and experience.

Relying on something tried and tested always makes a lot of sense.

What is Serverless

For instance, when people think of serverless, they typically think of a collection of Lambda functions calling each other and being invoked from the client application.

“Instead of a collection of functions calling each other, the best serverless/serviceful applications are: (a) thick client code handling all interaction logic, (b) heavy use of services (e.g., AppSync, Cognito, @Auth0, @Algolia, @Cloudinary), and © small glue functions.” — Joe Emison

I not only agree with this opinion of how modern serverless applications should be engineered, I see it in practice every day (from side project to startup to fortune 500 company).

What I don’t see though is enough discussion around the subject. I feel that it’s the ultimate enabler of innovation because of how fast and cheap it is now to prototype and test new ideas. Failing becomes much more tolerable because the up front cost is almost completely diminished as the services can now trivially and quickly be torn down and rebuilt over and over.

More and more companies and developers are ditching the need for a traditional back end and engineering team and instead focusing their efforts on delivering value to their users, with their important workloads being moved onto these types of managed services.

2019 and Beyond

This Serviceful Serverless philosophy will be something we see a lot more of in the coming months and years.

As complexity associated with software development continues to go up and the demand and cost for quality software engineers continues to skyrocket around the world, I think we’ll see cloud providers doubling down on these managed services while software companies and developers will increasingly leverage them to take advantage of the benefits that they offer.

If you’re interested in how my team is enabling developers to build these types of apps, we’ve built an entire framework around this philosophy. Check out AWS Amplify.

My Name is Nader Dabit .

I am a Developer Advocate at AWS Mobile working with projects like AWS AppSync and AWS Amplify. I’m also the author of React Native in Action, & the editor of React Native Training & OpenGraphQL.

Developer Advocate at AWS Mobile — Specializing in Teaching and Building React & React Native — http://reactnative.training https://aws.amazon.com/mobile

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store