For clients, I (we) generate AWS Lambda as the service access layer for application control and CRUD implementation. For NoSQL scenarios, we directly use MongoDB and for relational database scenarios we access a generated remote data layer to handle the state maintenance required for fast database transactions. Otherwise, due to the stateless nature of Lambda, firing queries to a relational database directly or through an ORM (like Hibernate) is painfully slow. All in all, performance is not an issue in either scenarios.
We will take a look at Dashbird to help with debugging and monitoring function execution/performance.
I too have seen a lot of companies using Lambda for the simple CRUD implementation and they do seem to be a great fit for those "fire and forget" type functions. I'd love to talk more about the way you guys are using Lambda inhouse. Send me a twitter message @johndemian
if you think you have the time to talk.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For clients, I (we) generate AWS Lambda as the service access layer for application control and CRUD implementation. For NoSQL scenarios, we directly use MongoDB and for relational database scenarios we access a generated remote data layer to handle the state maintenance required for fast database transactions. Otherwise, due to the stateless nature of Lambda, firing queries to a relational database directly or through an ORM (like Hibernate) is painfully slow. All in all, performance is not an issue in either scenarios.
We will take a look at Dashbird to help with debugging and monitoring function execution/performance.
I too have seen a lot of companies using Lambda for the simple CRUD implementation and they do seem to be a great fit for those "fire and forget" type functions. I'd love to talk more about the way you guys are using Lambda inhouse. Send me a twitter message @johndemian if you think you have the time to talk.