Being stuck on 2.7 has been the greatest source of issues and the #1 problem we have with Lambda. If Google/Microsoft came out today with Python 3 support in their Lambda competitor, we'd move in an instant.
Common is to give the client a cookie with a session id (KJASDJKASDASDS) in a cookie. Then in a RDBMS you store this (session KJASDJKASDASDS = User 1234)... and the first part of each web (or lambda call), you go look up the user by session and know who it is.
(You can also store the user ID directly in an encrypted cookie, but that has a few other problems)
If all he needed was session id, sure, NoSQL is more or less the same. But what about when he adds other fields that are related? Say customer address or reports or .... His life may very well be easier with relational.
You should generally start relational. Then branch out if you are hitting the brick walls of relational. People using NoSQL for a 100MB database are making their life SERIOUSLY more difficult than it needs to be. (I have done it before, not fun).
I don't know if it is that easy to scale once you realize that the demand is growing, see my other reply here:
1) A NoSQL DB for the main data providing replication and scalability(e.g. Cassandra or DynamoDB).
2) Another DB for quick access and transient Data where replication is not so important, e.g. storing the session cookie. Relational vs Non-relational would not be an issue since I'm only storing very little data here and want fast access and minimize costs(in DynamoDB you still have to pay per operation). Therefore I'm looking for some simple solution like ElastiCache.
1) The data model is rather simple, basically one table with the user data(name, location, age, etc...) and some images. So it shouldn't be too difficult to do this with NoSql as opposed to SQL. Yes, simpler with SQL but not significantly so.
2) If I ever need to scale, I'd rather make the right choice from the beginning(NoSQL) so as not to need a migration later.
3) In any case NoSQL would be a learning experience for me, so another plus.
If there is a mistake in my reasoning I would be grateful for any one pointing it out.
Your are selling a basic pubsub architecture as something "innovative" when the only real innovation is the pricing. That's the exact definition of marketing, and at the same time you are making the community of web developers sound like idiots that don't understand what a server is. You can make plenty of money without being missleading, why do you feel the need to use a misleading language ?
There is a server, period.
Most reasonable people find the "serverless" moniker obnoxious to begin with. If something doesn't require administration then call it "adminless", not "serverless"
> Your are selling a basic pubsub architecture as something "innovative" when the only real innovation is the pricing.
@jomamaxx (& others): Reducing latency (and latency variability) is a critical goal for our team. We've improved p99 variability in API Gateway-related latency over the last few months, and will be addressing some of the Lambda-related latency that occurs when we refresh containers in the coming months. Additional latency optimizations coming at all levels of the stack, including networking.
A clarification on the discussions about "managed hosting": Lambda is not classic web hosting; in fact, we block Lambda functions from calling socket.listen. In the Lambda model (whatever you prefer to call the broader category), the cloud service sees every request in order to perform scaling and load balancing on the function's behalf.
Happy to chat offline with anyone who has additional questions or feedback: DM me on twitter @timallenwagner