Live data from Hacker News

How we built a serverless architecture with AWS

hypertrack.com

31–40 of 68 posts

Re: How we built a serverless architecture with AWS

#31
post #7

Earlier quoted context omitted.

We haven't hit any scaling issues yet. GraphQL is nice. It's really about getting data directly from DynamoDB and Aurora to an end point that Android/iOS/React-JS can query and subscribe to. Apache Velocity Template Language that AppSync uses is a pain though. This post captures it well (unfortunately): https://www.reddit.com/r/graphql/comments/b0zomv/aws_appsync...

AppSync does have limitations we have to contend with. Custom scalar types cannot be defined hence we are not able to define strictly typed GeoJSON objects. Apache VTL has its own learning curve; once you master it you can implement functionality without leaning on invoking lambda functions and avoid paying for their usage in high volume GraphQl call scenarios and access queried data faster.

Just FYI, Hasura GraphQL Engine has native support for GeoJSON types:

https://blog.hasura.io/graphql-and-geo-location-on-postgres-...

PS: I work here. Apologies for plug.

Re: How we built a serverless architecture with AWS

#34
post #20

Earlier quoted context omitted.

I used to hate aws for how expensive their bandwidth and storage was, until I started actually using it last year. I think their new serverless stack is about to leave a lot of devops out of a job. You can setup a a CI/CD pipeline in about half an hour with amplify, at the previous company I remember it taking a good 3 weeks to get CircleCi up and running properly. And then moving a microservice over to it is basical…

Why do you say that nodejs is completely insecure by design and how does gcp or aws mitigate those security concerns?

Because you will inevitably have hundreds/thousands of dependencies, controlled by at least as many people, anyone of which could inject code to backdoor your server.

A supply chain attack will sooner or later be the cause of a major incident.

Re: How we built a serverless architecture with AWS

#35
post #30

Earlier quoted context omitted.

You can pay to never hit cold starts..

No you can't, you can just try and keep your lambdas warm, but that isn't the same thing.

wouldn't EC2 be an example of paying to never hit cold starts?

Re: How we built a serverless architecture with AWS

#36
post #20

Earlier quoted context omitted.

I used to hate aws for how expensive their bandwidth and storage was, until I started actually using it last year. I think their new serverless stack is about to leave a lot of devops out of a job. You can setup a a CI/CD pipeline in about half an hour with amplify, at the previous company I remember it taking a good 3 weeks to get CircleCi up and running properly. And then moving a microservice over to it is basical…

Why do you say that nodejs is completely insecure by design and how does gcp or aws mitigate those security concerns?

The V8 runtime itself is pretty secure. However every npm package has total access to your filesystem and network i/o. This is by design, the author of node himself has apologized for it and admitted that nothing can be done now because it'd basically break the internet. This means any package ( i.e. eslint), dependency, anything that has code from just one malicious contributor can grab away all your API keys, ssh keys(if you still use those), environment variables, crypto wallets of your users( this has actually happened a few times now at scale).

With something like aws-amplify you just go on their site and put your environment variables there, instead of keeping them on your own machine.

Now you don't have to worry about using sketchy docker images, or your junior devs using their work laptops on a malware infested gaming cafe while still running their localhost server.

Aws and gcp can afford to have way better internal security and regular pentesting of their containers and infrastructure, so now wrapping those protecting layers around node, express, etc... is their problem. You just push your code the production or testing branch and they handle all the provisioning, builds and deployments in 3-5minutes.

Re: How we built a serverless architecture with AWS

#37

How do you deal with Lambda concurrency? I have found its pretty easy to hit 1K concurrents if functions take a long time to run and receive bursty traffic.

Do you mean you don't want it to handle 1k concurrent requests (you want some to be rejected or queued instead?) or do you mean that the concurrent execution causes some other problem?

(honest question, not snark)

Re: How we built a serverless architecture with AWS

#38

Earlier quoted context omitted.

AppSync does have limitations we have to contend with. Custom scalar types cannot be defined hence we are not able to define strictly typed GeoJSON objects. Apache VTL has its own learning curve; once you master it you can implement functionality without leaning on invoking lambda functions and avoid paying for their usage in high volume GraphQl call scenarios and access queried data faster.

Just FYI, Hasura GraphQL Engine has native support for GeoJSON types: https://blog.hasura.io/graphql-and-geo-location-on-postgres-... PS: I work here. Apologies for plug.

I've been using Hasura for several months at work and it's approach to GraphQL has nailed the level of abstraction needed for early product development.

It's a great complement to serverless and static front-ends.

Re: How we built a serverless architecture with AWS

#39
post #36

Earlier quoted context omitted.

Why do you say that nodejs is completely insecure by design and how does gcp or aws mitigate those security concerns?

The V8 runtime itself is pretty secure. However every npm package has total access to your filesystem and network i/o. This is by design, the author of node himself has apologized for it and admitted that nothing can be done now because it'd basically break the internet. This means any package ( i.e. eslint), dependency, anything that has code from just one malicious contributor can grab away all your API keys, ssh k…

The npm dependency issue is a serious concern, but I'm not convinced that gcp or aws would mitigate the issue. If the problem is unaudited code that could be potentially compromised, gcp and aws will run that compromised code without protest.
Post reply on HN