AWS Serverless React Native Starter App(github.com)
github.com
AWS Serverless React Native Starter App
https://github.com/awslabs/aws-mobile-react-native-starter
71 comments
As a startup, the last thing to worry is vendor lock-in. With an architecture like this, you got fast time to market, minimal operations, scalability, zero starting cost, fair pricing. Just my 2c.
actually it's not the last thing to worry about. I deliberately didn't vendor lock-in with my startup, and now I can deploy to Azure, AWS, and anyone who has a linux box. Being vendor independent has opened the door to a lot of sales that would not have been possible otherwise
Once you reach a certain size I think it makes sense to explore rolling your own infrastructure but for an MVP or early stage startup not having to worry about infrastructure has got to be a god send. I recall hearing Kevin Systrom (Instagram) talk about how the app kept crashing on launch while it was being hosted on his single laptop. Imagine if he had EC2 :) (not that they needed it to grow)
You only need to look at how well PUBG has handled the load of quickly becoming one of the most popular games to see the benefits of AWS.
Yeah, their server software itself sucks a bit (low tick-rate, odd "de-sync"), but scaling itself has not been any issue: it feels the same now as it did with a tenth or a hundredth of the players it has right now.
Compare that to the growing pains that, for example, league of legends had, where even several years in the whole of EUW would be practically down on weekends. (log in "queue" over 9000)
Yeah, their server software itself sucks a bit (low tick-rate, odd "de-sync"), but scaling itself has not been any issue: it feels the same now as it did with a tenth or a hundredth of the players it has right now.
Compare that to the growing pains that, for example, league of legends had, where even several years in the whole of EUW would be practically down on weekends. (log in "queue" over 9000)
I think the problem is more serverless architectures than EC2. If you build for EC2 you can probably fairly easily migrate between hosts (at least, for our codebase it is). But if you build for Amazon Lambda there's more vendor lock in.
How so? My Python Lambda functions have almost zero AWS boilerplate besides passing in the event and context to the function whether I use it or not.
I would argue that real infrastructure or vendor "lock in" is due to the friction of learning the API's associated with each cloud platform. Obviously, one can choose to use all the services of the cloud platform they will deploy to. However, and in most cases, that is not a strict requirement to use the cloud platform to begin with. "Lock in" seems more like a self-created problem than anything.
I would argue that real infrastructure or vendor "lock in" is due to the friction of learning the API's associated with each cloud platform. Obviously, one can choose to use all the services of the cloud platform they will deploy to. However, and in most cases, that is not a strict requirement to use the cloud platform to begin with. "Lock in" seems more like a self-created problem than anything.
> I would argue that real infrastructure or vendor "lock in" is due to the friction of learning the API's associated with each cloud platform.
And it's not just cloud platforms. Every tool you use becomes more engrained the more you use it.
Put plainly: It seems silly to me how people will shout "vendor lock-in" when using a service like DynamoDB or Kinesis, but will be more than happy to learn how to set up and maintain a Cassandra or Kafka cluster, along with Zookeeper, Puppet/Chef, and all that goes along with it. Those are not insignificant costs!
I get that those aren't vendor-specific, but at some point you're just doing a lot more work, maintenance, and tying yourself down to a stack (and whatever employees became experts in them), and for what benefit? So you'll theoretically be able to move away faster if AWS goes rogue, long after your startup gains traction?
I think those reflexively dismissing cloud services due to vendor lock-in need to take a step back and look at the big picture.
And it's not just cloud platforms. Every tool you use becomes more engrained the more you use it.
Put plainly: It seems silly to me how people will shout "vendor lock-in" when using a service like DynamoDB or Kinesis, but will be more than happy to learn how to set up and maintain a Cassandra or Kafka cluster, along with Zookeeper, Puppet/Chef, and all that goes along with it. Those are not insignificant costs!
I get that those aren't vendor-specific, but at some point you're just doing a lot more work, maintenance, and tying yourself down to a stack (and whatever employees became experts in them), and for what benefit? So you'll theoretically be able to move away faster if AWS goes rogue, long after your startup gains traction?
I think those reflexively dismissing cloud services due to vendor lock-in need to take a step back and look at the big picture.
It's unimportant until it is.
Costs are high for aws. You might be able to pay a little more now but when you need to scale you may find you are priced off of aws.
Costs are high for aws. You might be able to pay a little more now but when you need to scale you may find you are priced off of aws.
You're not paying more to start out. It will be far, far cheaper to just use Kinesis / Lambda / S3 than to pay someone to learn about, set up, manage, and maintain remotely comparable infrastructure. It will take far less code, infrastructure, maintenance, know-how, and time. It's not even close.
More importantly, though: you quite possibly won't ever find yourself "priced off of aws." Netflix isn't. Workday isn't. Spotify isn't. Pinterest isn't. Dropbox only transitioned off very recently (reportedly for more control). Some of the biggest players on the web were able to scale and grow beyond most of our wildest dreams without it holding them back, yet still some recommend adding significant man-hours and complexity up-front just on the off-chance it becomes necessary after it's successful?
Let's be realistic here.
More importantly, though: you quite possibly won't ever find yourself "priced off of aws." Netflix isn't. Workday isn't. Spotify isn't. Pinterest isn't. Dropbox only transitioned off very recently (reportedly for more control). Some of the biggest players on the web were able to scale and grow beyond most of our wildest dreams without it holding them back, yet still some recommend adding significant man-hours and complexity up-front just on the off-chance it becomes necessary after it's successful?
Let's be realistic here.
The pattern I've seen is that AWS makes sense for startups, then you hit a point where you need a hundred hosts in a couple of data centers and you can do that more cheaply with raw hardware and a small team to handle it. Then you hit a point where you need thousands or tens of thousands of servers in multiple countries and you need to handle legal and logistic concerns and it's better to be in AWS (or GCE or whatever) again. That's the reason I've heard that Netflix and a lot of the other big companies are there.
you only get priced off of aws at the extremely high end and the extremely low end. in between you either have huge savings in staffing costs or you have huge leverage to negotiate better rates with aws
Likewise. My lambda code can all be run outside of the lambda environment and retain full functionality. Each module has a small translation layer to take in the event and context before marshaling execution to other functions.
[deleted]
Before you have product-market fit... vendor lock-in doesn't matter. The only thing that matters is getting to product-market fit.
If you have some product-market fit, vendor lock-in probably doesn't matter.
If your business is growing quickly and you have the ability to raise a strong Series A investment (if you wanted to), then vendor relationships are worth thinking about and engineering for the long term.
Giants like Amazon, Facebook, and Google don't want to "control your stuff before you even make it" because most things that people make aren't worth their time. Once your business is growing steadily, however, this might change.
If you have some product-market fit, vendor lock-in probably doesn't matter.
If your business is growing quickly and you have the ability to raise a strong Series A investment (if you wanted to), then vendor relationships are worth thinking about and engineering for the long term.
Giants like Amazon, Facebook, and Google don't want to "control your stuff before you even make it" because most things that people make aren't worth their time. Once your business is growing steadily, however, this might change.
If you have a concern about what a particular HN user is doing vis a vis some other company, send it to [email protected]. The guidelines specifically ask you not to bring those concerns to the thread.
As a startup if you make it to the "we regret tech decisions from 5 years ago" you're doing great. Better than the vast majority of startups.
But otherwise I agree, vendor lock in seems out of control.
But otherwise I agree, vendor lock in seems out of control.
Its a bad advice as per my experience, as a startup you'll have three problems cashflow, hiring, sales. Cash is your life blood, preserve it. Money you spent on boxes can give you 3 months additional runway, what you spent on devops could have been an additional sales person.
Hiring will be a pain, especially if you are competing with giants or millions of dollar valuation startups. One less person you have to hire is eons you can spend on other things.
Sales/Marketing would suck, you would spend more on getting the deal then you will make from that in 2 years. Your first 10 ideas to make the app viral will fail. Your dev time not going in ops. can be used to squeeze in that feature, the big fat wallet is asking for.
Don't worry about vendor lockin, React patents, green earth. 90% chance you'll die before you hit that, make that 99% if you are worrying about that. You'll anyway rewrite/rearch. the thing you are writing, as your understanding of market will improve.
Hiring will be a pain, especially if you are competing with giants or millions of dollar valuation startups. One less person you have to hire is eons you can spend on other things.
Sales/Marketing would suck, you would spend more on getting the deal then you will make from that in 2 years. Your first 10 ideas to make the app viral will fail. Your dev time not going in ops. can be used to squeeze in that feature, the big fat wallet is asking for.
Don't worry about vendor lockin, React patents, green earth. 90% chance you'll die before you hit that, make that 99% if you are worrying about that. You'll anyway rewrite/rearch. the thing you are writing, as your understanding of market will improve.
I have followed that good advice for many years, but after running 5 pet projects (at least one of which has a lot of traffic) and all dev activity for over a year on Amazon for not even $90 / month in total, I started to see if differently now. With Beanstalk and all the services it is just too easy and too cheap to get going. Maybe later on it will cost more than a dedi server but the time to market and me not swearing at servers is better for business and my private life.
This isn't much lock-in though. It's just a way to server a bunch of static files. It would take a little effort to port it to google cloud or a random file server, but not that much effort.
the github account is amazon's
https://github.com/awslabs
https://github.com/awslabs
Netflix doesn't seem all that worried about locking in with AWS despite Amazon arguably being their biggest competitor.
Talk about a premature optimization.
The only goal that matters for an early stage startup is product/market fit. If you can demonstrate traction you can raise money to buy yourself more time.
For this, rapid iteration is critical. Use whatever tools help; vendor lock-in is something you solve when you have 20mm+ in the bank.
The only goal that matters for an early stage startup is product/market fit. If you can demonstrate traction you can raise money to buy yourself more time.
For this, rapid iteration is critical. Use whatever tools help; vendor lock-in is something you solve when you have 20mm+ in the bank.
As a mostly hobbyist developer, I've always had such a hard time with AWS. I've tried Serverless a couple of times, but I couldn't for the life of me really understand Amazon's billing structure. For instance, while AWS Lambda supposedly has a generous free tier for the function execution, by the time you add the rest of the infrastructure to call the function over http, you start incurring fees. Mind you, they are incredibly modest, but its hard to really pull the trigger and commit without having a lot of confidence over exactly where those fees are coming from and how to confidently stop it/put caps on it.
I fully acknowledge that there are resources or options that I could be totally missing. If there is anyone who has gone through this sort of thing and has successfully managed to get really transparent look at pricing and reliably and easily shut down/provision/cap AWS services, do let me know!
I fully acknowledge that there are resources or options that I could be totally missing. If there is anyone who has gone through this sort of thing and has successfully managed to get really transparent look at pricing and reliably and easily shut down/provision/cap AWS services, do let me know!
Personally, I've had the opposite experience.
You can set billing alerts that will e-mail you when you cross whatever thresholds you set. On the billing page, it has a line item for each thing that costs money. It's not particularly difficult to stop anything, especially when you're just doing hobby projects anyway.
If you're OK with insignificant (less than $10) charges on your credit card, it's really not that hard to get pretty far with serverless. Almost everything serverless has perpetual free tiers and the ones that don't (API Gateway, CloudFront, Route 53) have very low usage-based costs (less than $1/mo idle). If you put any value at all on your time, you'd cross these amounts almost immediately trying to setup / learn anything else.
You can set billing alerts that will e-mail you when you cross whatever thresholds you set. On the billing page, it has a line item for each thing that costs money. It's not particularly difficult to stop anything, especially when you're just doing hobby projects anyway.
If you're OK with insignificant (less than $10) charges on your credit card, it's really not that hard to get pretty far with serverless. Almost everything serverless has perpetual free tiers and the ones that don't (API Gateway, CloudFront, Route 53) have very low usage-based costs (less than $1/mo idle). If you put any value at all on your time, you'd cross these amounts almost immediately trying to setup / learn anything else.
For me the main problem is that there is no bill capping in AWS - if the bill exceeds, say, $100, just shut down all my services no matter what. As a poor hobbyist dev I just cannot bear the risk of an unexpected high bill, although the chance of that is very slim.
Hi,
I'm suffering from the AWS billing madness too, and trying to understand if others share some of the same issues I've seen. Could I contact you to hear more about your billing frustrations?
I'm suffering from the AWS billing madness too, and trying to understand if others share some of the same issues I've seen. Could I contact you to hear more about your billing frustrations?
It is definitely hard to have the foresight necessary, and this whole industry could benefit from a book of devops case studies.
That being said, turn off the EC2 instances and there is rarely an ongoing trickle of costs, as the other services mostly are billed on how much they are invoked, which is good for hobby projects.
That being said, turn off the EC2 instances and there is rarely an ongoing trickle of costs, as the other services mostly are billed on how much they are invoked, which is good for hobby projects.
I've built a couple of complete SAAS applications on an AWS stack pretty similar to this and I can say that I've been incredibly productive.
The one technology I particularly like is Cognito/UserPools for user management - I never want to write Yet Another User Management System again.
I'd never use DynamoDB though - it's never made sense to me.
* AWS Userpools
* AWS Cognito
* AWS S3 Simple Storage Service
* AWS EC2 Elastic Compute Cloud
* AWS SQS Simple Queue Service
* AWS CloudFront
* AWS CloudWatch
* AWS KMS Key Management Service
* AWS Certificate Management Service
* AWS Route53
* AWS Lambda
* Postgres/SQL
* Python 3.6
* ReactJS/ES2015
The one technology I particularly like is Cognito/UserPools for user management - I never want to write Yet Another User Management System again.
I'd never use DynamoDB though - it's never made sense to me.
* AWS Userpools
* AWS Cognito
* AWS S3 Simple Storage Service
* AWS EC2 Elastic Compute Cloud
* AWS SQS Simple Queue Service
* AWS CloudFront
* AWS CloudWatch
* AWS KMS Key Management Service
* AWS Certificate Management Service
* AWS Route53
* AWS Lambda
* Postgres/SQL
* Python 3.6
* ReactJS/ES2015
One big reason to use DynamoDB with Lambda is to avoid the VPC penalty (~10-20 second cold starts to attach ENI) in Lambda necessary to use RDS securely. DynamoDB can be used without security groups and still use IAM-based access to lock it down securely. With RDS, you need to use security groups to properly secure your DB, which requires VPC for Lambda.
DynamoDB has world-class horizontal scalability but certainly comes with a high architecture integration cost, depending on your use cases.
DynamoDB has world-class horizontal scalability but certainly comes with a high architecture integration cost, depending on your use cases.
Have you tried adding this to the first line of your handler function definition?
context.callbackWaitsForEmptyEventLoop = false;
PostgreSQL on RDS?
No, on EC2. I prefer direct control over the database and see no reason to pay more for an RDS instance.
Is there a YAUMS beta coming soon?
What is YAUMS?
> ...Yet Another User Management System...
OH sorry. That's what AWS Cognito with AWS Userpools is - a user management system. When I say that I never want to write YAUMS again, I mean that Cognito and USerpools frees me from ever having to do that task again.
Sorry. Bad joke :/
It would be great if they also included a pricing calculator/model for all those AWS things tied up together.
If cloud providers want to be seen like utility providers, they need to provide a simple pricing model analogous to Watt and kWh in electricity for users to be able to estimate costs easily.
If cloud providers want to be seen like utility providers, they need to provide a simple pricing model analogous to Watt and kWh in electricity for users to be able to estimate costs easily.
Hi,
I'm thinking about working on a solution to better understand and limit costs in AWS. Could I contact you to understand a bit more about what would be an ideal setup for you?
I'm thinking about working on a solution to better understand and limit costs in AWS. Could I contact you to understand a bit more about what would be an ideal setup for you?
I'm not a big user myself. However, what I think is missing is a tool where you map your data flows, choose the flow steps as Amazon services, get required parameters back, fill them in, get back estimated cost.
That’d go directly against their business interests. It’s in Amazon’s interest to make it as confusing as possible, so you never notice you spend orders of magnitudes more than you’d have to.
I've been using most of these services since they launched and I can say that as a whole they are significantly cheaper to both run and develop until you get to very large scale at which point the code transfers to real servers pretty easily.
I have several mobile apps that I run literaly free because the Lambda usage is under the free tier and those I don't cost dollars a month. I am very happy with it in general.
There is of course the problem with any instant scaling metered service that if you are actively attacked you can rack up a large bill but there are monitoring systems that can be used to prevent that if you want (at the cost of taking down the service) or allow it to scale (at the cost of $$ but your customers stay happy).
Edit: It is worth noting (based on discussion below) that other posters are right. It is not for everyone. It has some major tradeoffs that you need to be aware of and plan around. But if the tradeoffs are OK (and I personally found they are for many of my projects) it is a great service.
I have several mobile apps that I run literaly free because the Lambda usage is under the free tier and those I don't cost dollars a month. I am very happy with it in general.
There is of course the problem with any instant scaling metered service that if you are actively attacked you can rack up a large bill but there are monitoring systems that can be used to prevent that if you want (at the cost of taking down the service) or allow it to scale (at the cost of $$ but your customers stay happy).
Edit: It is worth noting (based on discussion below) that other posters are right. It is not for everyone. It has some major tradeoffs that you need to be aware of and plan around. But if the tradeoffs are OK (and I personally found they are for many of my projects) it is a great service.
The code for Lambda and API Gateway can be moved to servers easily enough, yes. Switching away from using DynamoDB as a backend store, though, not so much. That would be quite a migration.
As a compromise I'd look to using MySQL or Postgres as a backend, and that being the only server I'm running, so that it's easier to move later (and so I still have access to a relational database). Except Lambda cold starts in a VPC are horrid, with no sign of change.
If you haven't looked into Lambda cold start problems, you're in for a treat. The main pitch for Lambda is for little utilized services, or services that need to scale fast, right? And in this example, you're using it to power an API? Imagine if the service is lightly used, whenever a user goes to hit the API for the first time, it takes 15 seconds to respond. Or worse, imagine if the service is getting popular, users get subjected to 15+ second response times every time Lambda has to start a new instance.
As a compromise I'd look to using MySQL or Postgres as a backend, and that being the only server I'm running, so that it's easier to move later (and so I still have access to a relational database). Except Lambda cold starts in a VPC are horrid, with no sign of change.
If you haven't looked into Lambda cold start problems, you're in for a treat. The main pitch for Lambda is for little utilized services, or services that need to scale fast, right? And in this example, you're using it to power an API? Imagine if the service is lightly used, whenever a user goes to hit the API for the first time, it takes 15 seconds to respond. Or worse, imagine if the service is getting popular, users get subjected to 15+ second response times every time Lambda has to start a new instance.
> If you haven't looked into Lambda cold start problems, you're in for a treat.
What the heck are you doing for 15 second cold starts? I haven't seen more than a 1s overhead for cold starts with Node.js apps packed with webpack (more like 2 or 3s without webpack)
But yes, if the cold start time is unacceptable to you. Lambda is a terrible fit. But you have to ask yourself what is and is not acceptable. Especially in a mobile or single page app where you can eager load or do background requests.
It is not for everyone.
Another trick is to group similar functions together in the same code and have different API gateway endpoints go to the same Lambda. Using that method most apps I've made have less than 1% of requests hit a cold start situation.
Edit: for many apps 1% sold starts is unacceptable. And that's OK. Lambda isn't for you.
What the heck are you doing for 15 second cold starts? I haven't seen more than a 1s overhead for cold starts with Node.js apps packed with webpack (more like 2 or 3s without webpack)
But yes, if the cold start time is unacceptable to you. Lambda is a terrible fit. But you have to ask yourself what is and is not acceptable. Especially in a mobile or single page app where you can eager load or do background requests.
It is not for everyone.
Another trick is to group similar functions together in the same code and have different API gateway endpoints go to the same Lambda. Using that method most apps I've made have less than 1% of requests hit a cold start situation.
Edit: for many apps 1% sold starts is unacceptable. And that's OK. Lambda isn't for you.
If you're cold starting in the public cloud, Lambda can start in 1s. If you're cold starting Lambda functions with a VPC NIC (which you would need to do if you're trying to connect to a MySQL server), it can take 10-15+ seconds. The issue is provisioning the network interface, not any manner of packing the code.
Thank you for clarifying. I up voted you. I have not experience that since I run most of my Lambdas in the public cloud so I have not experienced that. That is good to know and sounds like something they really need to address.
DynamoDB does have its drawbacks and I agree it is far from perfect. But you also don't have to use Dynamo. Lambda can connect to other databases too.
Although I did try to address some of your concerns in a reply to your other post.
Although I did try to address some of your concerns in a reply to your other post.
I'm curious, what do those apps do? Surely they need a database behind the severless layer? If so, is the database also on some kind of free tier? I'm mostly interested in TCO kind of calculators for cloud computing, not calculators on a per service-type basis.
DynamoDB, which is Amazon's serverless NoSQL database offering. If your service takes off, it's also the guaranteed source of a serious amount of cash for the company. If you get big while on DynamoDB, 1) it's near impossible to restructure to optimize your tables, 2) it's near impossible to migrate off of without serious pain, 3) your only method of controlling performance is sliding read/write throughput meters for your tables (ie, paying them more money). DynamoDB is not a service I'd be comfortable locking into.
Use DynamoDB if you are absolutely sure your database structure is perfectly optimized from the get go for the traffic you're going to receive. Your indexes and structure have to be absolutely perfect starting, because there's no good way to fix them later.
Use DynamoDB if you are absolutely sure your database structure is perfectly optimized from the get go for the traffic you're going to receive. Your indexes and structure have to be absolutely perfect starting, because there's no good way to fix them later.
I value your opinion but I have had a very different experience.
1. I agree. First few attempts at DynamoDB tables were a disaster. But once you get used to them you don't have to change schemas and then it is not an issue. Note, you can add and indexes, just not the primary one.
2. Not so. It's not easy but it's far from impossible or painful. I've had my fair share of pain migrating SQL databases too.
... Export to S3
... Grab the S3 backup and write an ETL to format and load it
... Put in place a stream hook to keep your newly loaded database up to date
... Switch over your data abstraction / model layer (you did use one of those right?)
3. You can also choose your indexes wisely. How is this different than a normal database?
Most of my DynamoDB using apps I run for 100% free and I've scaled to hundreds of thousands of users for less than the cost of a small Postgres server.
Just keep a model layer between you and Dynamo to avoid vendor lockin and you'll be fine.
1. I agree. First few attempts at DynamoDB tables were a disaster. But once you get used to them you don't have to change schemas and then it is not an issue. Note, you can add and indexes, just not the primary one.
2. Not so. It's not easy but it's far from impossible or painful. I've had my fair share of pain migrating SQL databases too.
... Export to S3
... Grab the S3 backup and write an ETL to format and load it
... Put in place a stream hook to keep your newly loaded database up to date
... Switch over your data abstraction / model layer (you did use one of those right?)
3. You can also choose your indexes wisely. How is this different than a normal database?
Most of my DynamoDB using apps I run for 100% free and I've scaled to hundreds of thousands of users for less than the cost of a small Postgres server.
Just keep a model layer between you and Dynamo to avoid vendor lockin and you'll be fine.
They are mobile apps with logins, account management, social network functionality. DynamoDB as a key/value store with Elasticsearch for anything that requires, well, search.
You can also use Amazon RDS with Lambda which, while still a database "server" does not require you to manage the server yourself.
You can also use Amazon RDS with Lambda which, while still a database "server" does not require you to manage the server yourself.
I really don't think it's in Amazon's interests to have a "holy shit, what happened?" reaction when you open your credit card bill.
And if you do -- say you forgot to kill some mega-cluster you were experimenting with and it ran for a few days before you terminated it -- they'll usually just drop the charge.
in my experience aws are incredibly proactive about helping customers understand their costs and offering suggestions to save money. they regularly send me cost benefit analysis of using reserved instances, for example
Starter app always good. I hope more example on starter kit cloud mbaas, for ex: firebase and azure. Need example include push sample code. Simple thing make faster building mvp
That's a great resource, detailed step by step instructions. This will get you started.
Offtopic, but maybe it's time people used Xcode instead of XCode, xCode etc. I didn't expect the repo's README to make this confusion.
Meh, that's like when people correct me when I say legos instead of LEGO or OSX instead of macOS or Github instead of GitHub.
God forbid someone doesn't get a corporation's branding 100% correct. Correcting them seems petty and doesn't elevate the convo.
God forbid someone doesn't get a corporation's branding 100% correct. Correcting them seems petty and doesn't elevate the convo.
Surprised at the lack of tests, client or server. I'm not just talking about client view code -- there's a lot of logic in the javascript helper methods.
Also, is there any way to run something like DynamoDB locally to run tests against?
Perhaps you would need to make a separate test instance of the DynamoDB on AWS to run tests against? This would be less than ideal due to latency.
Also, is there any way to run something like DynamoDB locally to run tests against?
Perhaps you would need to make a separate test instance of the DynamoDB on AWS to run tests against? This would be less than ideal due to latency.
Am I the only one who thinks that getting all of this stuff for free is a bad thing not a good thing? If you don't know how your auth works, how your server is running, and what exactly all these third party business logic libs do under the hood, you make debugging difficult and don't have a mental model for performance and scaling considerations.
It seems like a marketing pitch for Amazon Web Services.
I'm sure this is a great resource, only "Serverless" is really the worst possible tag to put on something requires a server per definition. I mean, Zeronet or anything else truly distributed, OK, but not for something that's simply characterized by running on a formalized serverbase like AWS.
Next you'll tell me "cloud" computing doesn't happen inside a bunch of water vapor.
While not really accurate, "Serverless computing" is the accepted industry standard term for this model where server management is abstracted away with cloud-based services.
https://en.wikipedia.org/wiki/Serverless_computing
https://en.wikipedia.org/wiki/Serverless_computing
I would argue that it’s not an industry standard unless it’s back by some sort of ISO like RFC. I’d also argue that it’s not an accepted term as _many_ people don’t agree with its misleading name, for example I personally see it as marketing spin.
The thing here is that they're not using any of AWS's proper server offerings. There's no EC2 or Lightsail or even RDS. There is no thing or concrete group of things that you can point to and say, "There, those are my servers." It's based off API Gateway, S3 and Lambda, none of which is recognizable as a server in the traditional sense (though of course there are servers behind the scenes implementing the abstraction).
I think this title is missing a few buzzwords
I still have no idea why people like the lambda environment. I assume it's because their organization still makes things like docker hard.
Also, user "nslog" only posts Amazon stuff and never comments.