Earlier quoted context omitted.
Ok we have very different definitions of very large. I mean s complete full featured SAAS workflow application. I don't actually use the AWS HTTP API gateway. I control the front end entirely so my UI just talks direct to lambda. It's very simple - instead of futzing around implementing REST API mapping layers I just connect all my front end functions to a single lambda function and specify in the params the name of…
> seriously consider using Cognito for your user management. Can you please expand on that recommendation? I tried and found it profoundly opaque, and eventually gave up in favour of auth0. I specifically wanted to use the hosted login/sign-up forms.
Serverless dev practices questions
11–20 of 30 posts
Re: Serverless dev practices questions
#12Re: Serverless dev practices questions
#13I have a very large application implemented as one single lambda python function. Works great.
Please define "very large". When I think large app, I think at least a few hundred endpoints split across tens of thousands of files. How can you have a very large app with a single endpoint? Could you elaborate?
Between the startup time (importing that much Python takes a few seconds, fine for a long running server, not good per-request), and all the dev-ops/infrastructure automation to get it all working correctly in dev/prod, I just think it would be more effort than it's worth, compared to running in "normally" on a cluster of VMs or dedicated machines.
Re: Serverless dev practices questions
#14Earlier quoted context omitted.
Ok we have very different definitions of very large. I mean s complete full featured SAAS workflow application. I don't actually use the AWS HTTP API gateway. I control the front end entirely so my UI just talks direct to lambda. It's very simple - instead of futzing around implementing REST API mapping layers I just connect all my front end functions to a single lambda function and specify in the params the name of…
> seriously consider using Cognito for your user management. Can you please expand on that recommendation? I tried and found it profoundly opaque, and eventually gave up in favour of auth0. I specifically wanted to use the hosted login/sign-up forms.
It lays out the architecture fairly well and how Cognito ties into it. Still very fiddly, and doesn't give any indication on how to use their hosted forms (which are a bit of a mystery to me as well).
Since it's still on point with the OP's question, I'll ask: What has your experience been with auth0? It's another service I have considered.
Re: Serverless dev practices questions
#15- We use the Serverless framework
- Monorepo with multiple (micro) services
- Each service exposes Lambda for particular functions (e.g. Articles service exposes GetArticle, CreateArticle, etc..)
- No business logic is being shared between services, only libraries
- Three environments, Dev, Stage, Production (and every developer can also deploy its own)
- Tests are invoking the Lambda handlers directly and are mocking responses from other Lambda calls. We use Localstack to stub AWS services, such as S3 and DynamoDB.
Still, a lot to learn of course, but so far everything is working great for us.
Re: Serverless dev practices questions
#16Earlier quoted context omitted.
> seriously consider using Cognito for your user management. Can you please expand on that recommendation? I tried and found it profoundly opaque, and eventually gave up in favour of auth0. I specifically wanted to use the hosted login/sign-up forms.
I found this tutorial had some very good information on incorporating Cognito into an app: https://aws.amazon.com/blogs/aws/build-your-first-serverless... It lays out the architecture fairly well and how Cognito ties into it. Still very fiddly, and doesn't give any indication on how to use their hosted forms (which are a bit of a mystery to me as well). Since it's still on point with the OP's question, I'll ask: What…
The thing I spend the most time on was "user_metadata" and "app_metadata", two JSON blobs on each user, RW and RO respectively. In order to read those at all from your application, you have to define a custom "rule" (arbitrary Javascript that wraps responses). The reason for this is something about standards and name-spacing, but I couldn't really follow the argument, and it's seems like this is something that very confusing to a lot of users.
Re: Serverless dev practices questions
#17I have a very large application implemented as one single lambda python function. Works great.
The python project defines a wsgi application (which is a python function meeting the wsgi spec), and Zappa runs the function on Lambda.
I wonder how large Zappa sites have gotten.
Re: Serverless dev practices questions
#18https://azure.microsoft.com/en-us/pricing/details/functions/
Re: Serverless dev practices questions
#19Re: Serverless dev practices questions
#20I'm not sure how AWS Lambda handles the charging of network latency (or failure) case of downstream external service dependencies but that is one of our biggest problems. ie pull/scrape architecture. The push portion (ie events) of our architecture is an obvious fit but that is already taken care of quite nicely.
We interact with hundreds of web services (REST APIS, SOAP, etc) that are actually external from us.
Its unclear if or how Amazon charges you for a slow external service (I would imagine its particularly bad if the code is blocking IO) or if that is even possible. I do know spawning a whole bunch of servers to connect to a single REST API endpoint is damn slow.
I have feeling Lambda for our case is probably not a good one? Obviously for data processing I can see it but that is not a challenge we have.
In an ideal world our downstream (or I guess it could be called upstream...) dependencies would contact us but... that sadly isn't the case particularly for adhoc stuff.