
AWS Serverless React Native Starter App - nslog
https://github.com/awslabs/aws-mobile-react-native-starter
======
notaboutdave
As a developer or startup the last thing you want to do is tie yourself into
absurdly proprietary platforms like this. Giants like Amazon, Facebook and
Google are buying up all established competition, but now they want control of
your stuff before you even make it.

Also, user "nslog" only posts Amazon stuff and never comments.

~~~
40acres
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)

~~~
sbov
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.

~~~
monkmartinez
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.

~~~
moduspol
> 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.

~~~
wolco
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.

~~~
moduspol
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.

~~~
novembermike
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.

------
ChicagoBoy11
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!

~~~
moduspwnens14
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.

------
andrewstuart
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

~~~
wahnfrieden
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.

~~~
ryall
Have you tried adding this to the first line of your handler function
definition?

    
    
       context.callbackWaitsForEmptyEventLoop = false;
    

I only came across this last night, so haven't had a chance to test yet.
Supposedly reduces the cold-start VPC delay significantly.

------
polskibus
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.

~~~
kuschku
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.

~~~
throwaway2016a
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.

~~~
joecot
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.

~~~
throwaway2016a
> 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.

~~~
joecot
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.

~~~
throwaway2016a
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.

------
bernadus_edwin
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

------
GrumpyNl
That's a great resource, detailed step by step instructions. This will get you
started.

------
frusciante29
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.

~~~
always_good
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.

------
gt2
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.

------
hamburglar1
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.

------
jijji
It seems like a marketing pitch for Amazon Web Services.

------
dingdingdang
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.

~~~
bigtunacan
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)

~~~
mrmondo
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.

------
chollier
I think this title is missing a few buzzwords

------
alexnewman
I still have no idea why people like the lambda environment. I assume it's
because their organization still makes things like docker hard.

