List of Serverless Functions for JAMstack Apps(jamstackfns.com)
jamstackfns.com
List of Serverless Functions for JAMstack Apps
https://jamstackfns.com/
5 comments
Question for the frontend crowd: how have microservices/serverless aged over the past few years? I've largely avoided learning/using this type of architecture because intuitively it seems like a bad idea to split your app and business logic across a bunch of tiny services with unknown uptime stats (difficult to maintain, difficult to see macro view of your application, cascades of service dependencies, hard to onboard new people, etc). Are microservices and serverless architecture still considered a good idea? What are the benefits I'm not seeing?
For me Serverless has replaced 99% of servers and there's no going back. I have absolutely no desire to run, maintain, update and monitor servers or server processes. Once you deploy an app to AWS Lambda and API Gateway, it keeps running basically forever. The main reason for that is that there is no state (except for what is stored in DynamoDB, which in turn AWS takes care of). And thus your application is always in the same state as when it was deployed, without memory leaks or handle leaks or escaped background threads or anything like that.
The remaining 1% are apps that require a persistent TCP or UDP connection with some protocol that AWS doesn't support in its Serverless services, or that require keeping some state in RAM, e.g. for online gaming.
The remaining 1% are apps that require a persistent TCP or UDP connection with some protocol that AWS doesn't support in its Serverless services, or that require keeping some state in RAM, e.g. for online gaming.
I'm not aware of a real "consensus," but a popular view (reflected by my experience) is that they're great for a large org with many teams working asynchronously (though they still introduce headaches), but that for most startups, the payoff is reduced greatly while the pain remains consistent.
You've probably around seen this, but DHH has a good piece on this in Signal v. Noise: https://m.signalvnoise.com/the-majestic-monolith/
You've probably around seen this, but DHH has a good piece on this in Signal v. Noise: https://m.signalvnoise.com/the-majestic-monolith/
I feel this post is addressing something else. Serverless is pretty much simple especially with a framework of the same name or on say netlify. All your code is in one repo and you don’t have to worry about the servers at all.
The blogpost is more about orgs deciding to manage their servers too, going full on kubernetes, docket, etc. That’s what complicated everything because now you need dozens of other systems just to make your container architecture work.
But serverless? You need nothing. Just push to a repo and you’re done because someone else is doing the cat herding of running the containers.
The blogpost is more about orgs deciding to manage their servers too, going full on kubernetes, docket, etc. That’s what complicated everything because now you need dozens of other systems just to make your container architecture work.
But serverless? You need nothing. Just push to a repo and you’re done because someone else is doing the cat herding of running the containers.
It really depends on the scale of your organization. Microservices do have their place, but I'd argue that most of the time monoliths are fine.
Sooo... the "JAMstack" is like the inside of a controller action, where the service provider gives you a route to it? Why do this to yourself? Like you didn't have to do ./app run, okay... but what does it look like when you have 10+ "serverless" functions?
It seems to me, it would look an awful lot like a badly organized server application. Kind of like PHP sites were (generally) organized circa 2003.
Speaking of which, isn't PHP like "OG Severless?" In fact, isn't this a more complicated deployment of what you can do with PHP? I don't even care for PHP, but it seems a lot easier than this, and certainly at least as cheap and easy to deploy.
I'm just at loss what the purpose of this is... or how it isn't reinventing a specific set of wheels that everyone already passed on (or already uses for those specific purposes).
It seems to me, it would look an awful lot like a badly organized server application. Kind of like PHP sites were (generally) organized circa 2003.
Speaking of which, isn't PHP like "OG Severless?" In fact, isn't this a more complicated deployment of what you can do with PHP? I don't even care for PHP, but it seems a lot easier than this, and certainly at least as cheap and easy to deploy.
I'm just at loss what the purpose of this is... or how it isn't reinventing a specific set of wheels that everyone already passed on (or already uses for those specific purposes).
> It seems to me, it would look an awful lot like a badly organized server application. Kind of like PHP sites were (generally) organized circa 2003.
Isn't this in alignment with the theory that technology is a flat circle.
Redux became the message passing architecture of win32 programming. Java got a huge resurgence in late 2000s when it was discovered that instead of being good for running TV and refrigerators it's actually great for running web servers. How BEAM was discovered to be great for real time web (because we're finally arriving at real time web).
One day we'll go back to writing frontend apps just like late 90s embedded inline JS code used to be. CSS would be inline again. Then monolithic services architecture would be back again, and one day Facebook will introduce the ability to have 'themes' on your profile like MySpace did.
Isn't this in alignment with the theory that technology is a flat circle.
Redux became the message passing architecture of win32 programming. Java got a huge resurgence in late 2000s when it was discovered that instead of being good for running TV and refrigerators it's actually great for running web servers. How BEAM was discovered to be great for real time web (because we're finally arriving at real time web).
One day we'll go back to writing frontend apps just like late 90s embedded inline JS code used to be. CSS would be inline again. Then monolithic services architecture would be back again, and one day Facebook will introduce the ability to have 'themes' on your profile like MySpace did.
Creator here, happy to answer any questions. Here's why I built this.
JAMstack (JavaScript, APIs, and Markup) is fundamentally reshaping the web. Coined by Netlify's co-founder, JAMstack bridges the gap between static and dynamic websites. Capitalize on static site performance, security, and scalability while still having dynamic data.
I've seen this first-hand, building many JAMstacks sites myself. As a front-end developer, it was always challenging to find good examples of serverless functions. I'd usually have to dive through documentation, search StackOverflow, and ask questions on GitHub. They might have code but never had complete instructions for set up.
JAMstack Functions is a directory of the best serverless functions for JAMstack applications. Each function includes code for both Vercel (Next.js) and Netlify Functions, as well as instructions for setting up. Quickly deploy the function to your static site and start building.
Let me know which functions you'd like to see added.
JAMstack (JavaScript, APIs, and Markup) is fundamentally reshaping the web. Coined by Netlify's co-founder, JAMstack bridges the gap between static and dynamic websites. Capitalize on static site performance, security, and scalability while still having dynamic data.
I've seen this first-hand, building many JAMstacks sites myself. As a front-end developer, it was always challenging to find good examples of serverless functions. I'd usually have to dive through documentation, search StackOverflow, and ask questions on GitHub. They might have code but never had complete instructions for set up.
JAMstack Functions is a directory of the best serverless functions for JAMstack applications. Each function includes code for both Vercel (Next.js) and Netlify Functions, as well as instructions for setting up. Quickly deploy the function to your static site and start building.
Let me know which functions you'd like to see added.
>JAMstack (JavaScript, APIs, and Markup) is fundamentally reshaping the web.
How? "fundamentally reshaping the web" is a bold claim; how are those things reshaping the Web -- what's changing shape?
How? "fundamentally reshaping the web" is a bold claim; how are those things reshaping the Web -- what's changing shape?
It's not, in my opinion.
Just something old - simple generated static site with sprinkle of {{currentJSFramework}}, a CDN, and some fancy marketing.
Just something old - simple generated static site with sprinkle of {{currentJSFramework}}, a CDN, and some fancy marketing.
What's your opinion on a more full-featured framework like RedwoodJS or Blitz then?
https://redwoodjs.com/ https://blitzjs.com/
https://redwoodjs.com/ https://blitzjs.com/
So these are frameworks that generate static sites?
Static sites have evolved. Today, they can handle real-time requests, process payments, manage customer accounts, and a lot more. Some other benefits:
* Cheaper – Not making requests to the server on-demand
* Faster – Served from a global CDN close to your users
* Easier – No complicated deployments, better DX
I'm still not quite there.
>real-time requests
What's this mean? If you're describing the ability to transfer the web site's data whenever a request comes in for that data, that's been the case since day 1. Alternatively, if you're describing the ability to make changes on the fly and re-draw the web site without a full request/response cycle, is it still a static web site?
>process payments
This really doesn't count though, does it? After all, the processing is occurring elsewhere: a third-party payment service or somewhere within the infrastructure behind the web site. It's more-or-less sending a request to some place else to process a transaction.
>manage customer accounts
This is similar to the previous. There's not a whole lot new going on here; you'll have to expand.
>Cheaper – Not making requests to the server on-demand
I don't understand how not making a request is intrinsic to any type of web site.
>Faster – Served from a global CDN close to your users
This just describes the location of the data; nothing to do with the web site.
>Easier – No complicated deployments, better DX
Now this might have some merit to it. Over the course of time, technology evolves and tasks which were more complex 10 years ago may seem trivial today; the technology you're describing could indeed be one of the choices available today.
>How is this reshaping the web? In a way, we've come full circle. What's changing is how we get to a static site. JAMstack unlocks all the benefits of static sites with today's complex data requirements.
Come full circle to what?
We also haven't changed how we get to a static web site; a client calls a server and the server might respond with some data. I would navigate to your website the same exact way I would have 10, 15, ... years ago.
>real-time requests
What's this mean? If you're describing the ability to transfer the web site's data whenever a request comes in for that data, that's been the case since day 1. Alternatively, if you're describing the ability to make changes on the fly and re-draw the web site without a full request/response cycle, is it still a static web site?
>process payments
This really doesn't count though, does it? After all, the processing is occurring elsewhere: a third-party payment service or somewhere within the infrastructure behind the web site. It's more-or-less sending a request to some place else to process a transaction.
>manage customer accounts
This is similar to the previous. There's not a whole lot new going on here; you'll have to expand.
>Cheaper – Not making requests to the server on-demand
I don't understand how not making a request is intrinsic to any type of web site.
>Faster – Served from a global CDN close to your users
This just describes the location of the data; nothing to do with the web site.
>Easier – No complicated deployments, better DX
Now this might have some merit to it. Over the course of time, technology evolves and tasks which were more complex 10 years ago may seem trivial today; the technology you're describing could indeed be one of the choices available today.
>How is this reshaping the web? In a way, we've come full circle. What's changing is how we get to a static site. JAMstack unlocks all the benefits of static sites with today's complex data requirements.
Come full circle to what?
We also haven't changed how we get to a static web site; a client calls a server and the server might respond with some data. I would navigate to your website the same exact way I would have 10, 15, ... years ago.
>> Easier – No complicated deployments, better DX
I'm a big fan in many use-cases, but this one is overstated IMO. Yes, your "site" is essentially a bunch of static pages but in order to do all that fancy stuff that the JA-part is selling you now have a massive deployment challenge that's just as prone to the same problems as the distributed monolith.
The big win IMO is moving runtime concerns to build-time. There are a surprising number of scenarios where the backing data changes on predictable, not-that-frequent basis. For example, it is far easier to publish a product catalog based on some internal system via a static generator than some sort of real-time link.
There are lots of cool use-cases but JAM is not reshaping the web in any structural way, at least if you've been programming it for more than 5-10 years...
I'm a big fan in many use-cases, but this one is overstated IMO. Yes, your "site" is essentially a bunch of static pages but in order to do all that fancy stuff that the JA-part is selling you now have a massive deployment challenge that's just as prone to the same problems as the distributed monolith.
The big win IMO is moving runtime concerns to build-time. There are a surprising number of scenarios where the backing data changes on predictable, not-that-frequent basis. For example, it is far easier to publish a product catalog based on some internal system via a static generator than some sort of real-time link.
There are lots of cool use-cases but JAM is not reshaping the web in any structural way, at least if you've been programming it for more than 5-10 years...
Fair points – "reshaping the web" was a probably bit overzealous.
JAMstack is an odd term. LAMP is a stack. It's Linux, Apache, MySQL, and PHP. JAM at most is a kind of stack, and a vague one. When using JavaScript to build web apps it's assumed markup will be involved. Perhaps including "Markup" implies SSR? I don't get it. JAM is a fun word though. Maybe that's why it took off, just like AJAX.
I do like Vercel, though.
I do like Vercel, though.
I say JAMstack because saying "static sites" causes a lot of confusion. It's easy to hear static and think vanilla HTML with no backing data source. JAMstack, to me, is a better explanation for a static site generated by dynamic data.
Just FYI spelling error:
https://jamstackfns.com/f/mailgun
at the bottom "environment" is spelled wrong. :)
at the bottom "environment" is spelled wrong. :)
This is pretty cool. It's about the same concept as https://stdlib.com/ but using JAMstack providers to build the serverless functions instead of dealing with the complexity of the major cloud providers and supporting different programming languages.
Thanks for sharing stdlib, I hadn't seen it before.
Netlify Functions are essentially AWS Lambda functions. They just abstract away all the tedious parts for you. Serverless functions with Next.js & Vercel have an abstraction with (req, res) to support multi-cloud.
Netlify Functions are essentially AWS Lambda functions. They just abstract away all the tedious parts for you. Serverless functions with Next.js & Vercel have an abstraction with (req, res) to support multi-cloud.
[deleted]