2

A project is structured as so:

A build server listens to changes in two repositories: a frontend and backend repo. When it picks up a change it builds, tests, and deploys the updates to a production server that exposes a publicly accessible endpoint.

On the production server, the backend is a Golang https server that serves static files and then has a designated endpoint handling CRUD interactions with the database via REST API. The frontend is split between a static react app built and updated by the build server that reads dynamic content from the backend REST API and then a similarly static authenticated CMS interface to manage the content itself.

Is this a solid or terrible way to structure a non-commercial webapp? Are there any obvious weaknesses I'm overlooking (besides pushing from build to production automatically)?

Improve this question

1 Answer 1

Reset to default
-1

a designated endpoint handling CRUD interactions with the database via REST API

Directly allowing interactions from the frontend to your database is very risky, especially when the database contains sensitive information. Instead of a POST request to /api/db/addItem containing the body { "foo": "bar" }, do something which is more like /api/db/addFoo with no body.

All of the verification should be done on the server's REST api.

Improve this answer
1
  • 3
    Not sure I agree with that statement. It's risky to concatenate a database command (SQL or otherwise) with user supplied data. That doesn't change whether it's supplied with addItem and addFoo or with a JSON body. But if you aren't concatenating strings and using prepared statements (or equivalent), then you are typically safe.
    – Berin Loritsch
    Mar 1, 2022 at 3:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.