Comment by Nitramp | Hacker News Reader

Comment by Nitramp | Hacker News Reader

Parent Full thread

Woohoo! It's the second coming of stored procedures and PL/SQL! Party like it's 1988!

Seriously though, these kinds of architectures come at a cost. The website's claims are either misleading, or the authors haven't understood the problem domain. E.g.:

Each of your API URLs points to one of these Lambda functions. This way, the code for each API Route is completely isolated, enabling you to develop/update/configure/deploy/maintain code for specific API urls at any time without affecting any other part of your application(!!!).

Even if you add more exclamation marks, you'll still end up with front end code depending on the interface exposed by your backend code, meaning you'll have to do versioned rollouts, except you no longer have a single deployable but a zoo of store proce^W^Wlambda functions, with unclear interdependencies and (usually) no proper versioning or tracking.

This might be the right architecture for certain apps, but it's not the easy win/win that's presented here.

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.

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.

Up next, I will add the ability to define your entire JAWS API in JSON via Swagger.

Swagger JSON can be imported to create/update your REST API instantly via AWS API Gateway.

Meaning, you can still do larger, versioned roll-outs by simply updating the JSON in your Swagger file.

This will give beautiful structure and simplicity to the JAWS workflow.

The single deployable server you advocate is a single point of failure.

I'm sure you'll further improve this, good luck!

The single deployable server you advocate is a single point of failure.

I'm not talking about a deployable server, I'm talking about a deployable as a unit of deployment, e.g. a war archive. A deployable is a compile time artefact, a single point of failure is a runtime concept. In that sense, saying a deployable was a single point of failure is like saying a line of code is a single point of failure.

Lack of git/versioning integration is pretty key and is one of the downsides of requiring deployment from the browser. We're hacking on something that solves this @ https://stackhut.com.

Reply on news.ycombinator.com