3 ms·

I haven't used JAWS, and I don't see where they speak to this question, but I do work on AWS lambda "applications", and typically they're versioned using versio

by angrow 11y ago

I haven't used JAWS, and I don't see where they speak to this question, but I do work on AWS lambda "applications", and typically they're versioned using versioned S3 buckets. It's very easy to continuously "deploy" code artifacts to S3, but only update the revision working on production traffic when you're good and ready. You can also optionally spin up complete duplicates of your infrastructure using the new revision, for exceedingly realistic integration or performance tests. I'm not really sure what you mean by "tracking," but you can log anything you like from a Lambda function, and include version information in those logs. I do agree with your analogy and caution, though.

Nitramp 11y ago
My point is that the advertised separation of frontend and backend using stored procedures in your database can be a huge misfeature - it requires a lot of management and rigor to maintain a compatible API interface that allows that kind of architecture. Frankly more than I'd expect from a bunch of JavaScript snippets (where you usually don't have a lot of tooling to support you). Relying on stored procedures in a hosted database system also means you cannot write locally reproducible, reasonably hermetic tests. It also (obviously) completely binds you to a single vendor. In short, it has all the drawbacks this architecture had when it was still Oracle database servers and stored procedures in PL/SQL (and/or the equivalent from MS, IBM, ...). It also has similar benefits (no need to manage a separate server, simpler architecture, often simpler to get things done for novices). There are good reasons why that architecture largely lost in the market by now, I'd be very careful to make sure this is a good fit for your problem. But of course only you can be the judge of that.

3 ms·

I haven't used JAWS, and I don't see where they speak to this question, but I do work on AWS lambda "applications", and typically they're versioned using versio

by angrow 11y ago

Nitramp 11y ago
My point is that the advertised separation of frontend and backend using stored procedures in your database can be a huge misfeature - it requires a lot of management and rigor to maintain a compatible API interface that allows that kind of architecture. Frankly more than I'd expect from a bunch of JavaScript snippets (where you usually don't have a lot of tooling to support you). Relying on stored procedures in a hosted database system also means you cannot write locally reproducible, reasonably hermetic tests. It also (obviously) completely binds you to a single vendor. In short, it has all the drawbacks this architecture had when it was still Oracle database servers and stored procedures in PL/SQL (and/or the equivalent from MS, IBM, ...). It also has similar benefits (no need to manage a separate server, simpler architecture, often simpler to get things done for novices). There are good reasons why that architecture largely lost in the market by now, I'd be very careful to make sure this is a good fit for your problem. But of course only you can be the judge of that.