At the end of the day the database is your one source of truth.
Uh no. That's far from true. Enterprise scaled applications are usually built around the domain meaning that the database is an implementation detail. Small apps that are usually aimed to be a POC or MVC might have their database as one source of truth but beyond that hell no.
A developer with M.Sc. in Computer Science. Working professionally since 2010. In my free time I make music and cook.
Also I don't and after the recent events will not have Twitter.
Location
Budapest
Education
Eötvös Loránd University (ELTE - Budapest Hungary) Computer Science M. Sc.
Sorry to chime in so late, but there is a viewpoint not expressed here leading to the wrong conversations. Who's responsibility is to keep data consistent or free of garbage? (i.e. invalid states)
Regarding if you say frontend, backend or database I have bad news for all of them.
If you think of the layers as an onion then...
The core would be the database (or distributed database, or databases if many services roll their own).
Then you can have n number of services that operate upon that. This means if you choose not to validate data written into your database now you have to do it n times!
Then you can have k number of frontends, plus other services and hackers with scripts that send in data. Obviously, as the article is also saying, at this point validation on the frontend is just UX ensuring a smooth user experience - i.e. when you input invalid data you do not need to wait for submitting the form to see the phone number format is wrong.
And then if you choose...
The database layer to ensure data validity/consistency you are going to face horrible source control options, inability to unit test solutions, hiring issues (sadly ORMs make hiring easier on the expense of good DB code), etc. Writing code to the DB is not a rich coding experience.
The service layer, then you need to figure out how to distribute your validator among many codebase, sometimes many languages! Good luck maintaining a validation library in Java, JS, Go, Rust etc. at the same time.
Everything sucks, just retire early and open a bar. 😐
Everything sucks, just retire early and open a bar
:D
Respectfully, but if you look at your web API as a micro service, you can ensure all clients are using the same micro service to interact with the database. Creating such "bottle necks" is often very valuable, since it implies arguably the equivalent of "single source of truth" in regards to code able to modify data, and leads to the same nice place as "single source of truth" leads to related to data normalisation and similar constructs ...
A developer with M.Sc. in Computer Science. Working professionally since 2010. In my free time I make music and cook.
Also I don't and after the recent events will not have Twitter.
Location
Budapest
Education
Eötvös Loránd University (ELTE - Budapest Hungary) Computer Science M. Sc.
The point is, you are better off if you think about the bottlenecks than if you are not.
As a side note it horrifies me whenever I read "80-90% backend applications are simple CRUD applications, therefore they can be autogenerated from a document.". If your application is a simple CRUD you either don't have data consistency or an actual useful, sellable product.
If your application is a simple CRUD you either don't have data consistency or an actual useful, sellable product
Define CRUD. Our "CRUD" generator allows you to apply.
reCAPTCHA values for individual verbs towards individual tables
Authorisation requirements for individual verbs towards individual tables
Row level security implying for instance users cannot see individual records that aren't their own "property"
Decide which rows are included in which CRUD verb endpoint
Automagically takes care of foreign keys, adding auto complete widgets in the frontend when you've got a foreign key, doing lookups into the referenced table
Publishing socket messages upon write invocations towards data
Implement caching
Log invocations
Add validators server side for individual fields
Etc, etc, etc ...
I'd say that covers about 80% to 90% of the stuff me and you typically do, assuming your background is enterprise software development ... ;)
... unless of course you're one of these guys always looking for an opportunity to make stuff more complex ... :/
an actual useful, sellable product
Psst, Microsoft Office Access ...?
Last time I checked it was selling pretty decent ...? ;)
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.
Uh no. That's far from true. Enterprise scaled applications are usually built around the domain meaning that the database is an implementation detail. Small apps that are usually aimed to be a POC or MVC might have their database as one source of truth but beyond that hell no.
Sorry to chime in so late, but there is a viewpoint not expressed here leading to the wrong conversations.
Who's responsibility is to keep data consistent or free of garbage? (i.e. invalid states)
Regarding if you say frontend, backend or database I have bad news for all of them.
If you think of the layers as an onion then...
nnumber of services that operate upon that. This means if you choose not to validate data written into your database now you have to do itntimes!knumber of frontends, plus other services and hackers with scripts that send in data. Obviously, as the article is also saying, at this point validation on the frontend is just UX ensuring a smooth user experience - i.e. when you input invalid data you do not need to wait for submitting the form to see the phone number format is wrong.And then if you choose...
databaselayer to ensure data validity/consistency you are going to face horrible source control options, inability to unit test solutions, hiring issues (sadly ORMs make hiring easier on the expense of good DB code), etc. Writing code to the DB is not a rich coding experience.servicelayer, then you need to figure out how to distribute your validator among many codebase, sometimes many languages! Good luck maintaining a validation library in Java, JS, Go, Rust etc. at the same time.Everything sucks, just retire early and open a bar. 😐
:D
Respectfully, but if you look at your web API as a micro service, you can ensure all clients are using the same micro service to interact with the database. Creating such "bottle necks" is often very valuable, since it implies arguably the equivalent of "single source of truth" in regards to code able to modify data, and leads to the same nice place as "single source of truth" leads to related to data normalisation and similar constructs ...
The point is, you are better off if you think about the bottlenecks than if you are not.
As a side note it horrifies me whenever I read "80-90% backend applications are simple CRUD applications, therefore they can be autogenerated from a document.". If your application is a simple CRUD you either don't have data consistency or an actual useful, sellable product.
Define CRUD. Our "CRUD" generator allows you to apply.
I'd say that covers about 80% to 90% of the stuff me and you typically do, assuming your background is enterprise software development ... ;)
... unless of course you're one of these guys always looking for an opportunity to make stuff more complex ... :/
Psst, Microsoft Office Access ...?
Last time I checked it was selling pretty decent ...? ;)