Auf YouTube findest du die angesagtesten Videos und Tracks. Außerdem kannst du eigene Inhalte hochladen und mit Freunden oder gleich der ganzen Welt teilen.
Quite frankly I don’t really know what you’re complaining about. You’re literally describing how we reuse standard database technologies like SQL, or standard patterns like REST, or standard application and data access frameworks, which we do literally all the time.
Quite frankly, I think you don’t understand what I mean.
Don’t kid yourself, “patterns” are boiler-plates so common they have a name. Yes, SQL makes things much faster, but that’s just the beginning. As soon as you venture out of the almost trivial cases, things get ugly fast. Think about something as simple as a form. That’s a standard problem. But I can’t just write down a “form-spec” and have a frontend and backend for that. No, I need a bunch of libraries that don’t quite work together and need a lot of persuasion to work together.
Or think of Rest-APIs. How many times could you really just ingest a spec and have everything working as expected? That’s very rare. Some libraries are plain weird, some don’t support certain aspects of what you want, etc. etc. etc.
A simple CRUD app should not require a single line of code. Yet, 80% of us are essentially doing exactly that.
Think about something as simple as a form. That’s a standard problem. But I can’t just write down a “form-spec” and have a frontend and backend for that. No, I need a bunch of libraries that don’t quite work together and need a lot of persuasion to work together.
You can just spin up a Next.js project complete with API calls and ready to go forms. Pick a full stack framework and go with it, there are several.
The larger reason that there is separation between front and back end though is that there is intentional decoupling between them because the backend might also be responding to requests from native applications, or other servers.
Hell, what you’re describing with Gui based application builders also exist everywhere. That’s basically airtable or salesforce or flutterflow, and guess what, those applications all kind of suck because a form is not as standard as you think. In a good application, there will always be customized design, flow and logic that happens to capture user input on the frontend, and on the backend there are a myriad of reasons to optimize different databases for different things. Look at the limitations you run into with Salesforce and Airtable databases because every database needs to have a whole plethora of features just to support the frontend Gui interface to manipulate them. I mean if you just want a flat form use Google forms, if business logic starts connecting some of the fields with complicated relationships and flows then suddenly things aren’t so standard.
Quite frankly I don’t really know what you’re complaining about. You’re literally describing how we reuse standard database technologies like SQL, or standard patterns like REST, or standard application and data access frameworks, which we do literally all the time.
Quite frankly, I think you don’t understand what I mean.
Don’t kid yourself, “patterns” are boiler-plates so common they have a name. Yes, SQL makes things much faster, but that’s just the beginning. As soon as you venture out of the almost trivial cases, things get ugly fast. Think about something as simple as a form. That’s a standard problem. But I can’t just write down a “form-spec” and have a frontend and backend for that. No, I need a bunch of libraries that don’t quite work together and need a lot of persuasion to work together.
Or think of Rest-APIs. How many times could you really just ingest a spec and have everything working as expected? That’s very rare. Some libraries are plain weird, some don’t support certain aspects of what you want, etc. etc. etc.
A simple CRUD app should not require a single line of code. Yet, 80% of us are essentially doing exactly that.
You can just spin up a Next.js project complete with API calls and ready to go forms. Pick a full stack framework and go with it, there are several.
The larger reason that there is separation between front and back end though is that there is intentional decoupling between them because the backend might also be responding to requests from native applications, or other servers.
Hell, what you’re describing with Gui based application builders also exist everywhere. That’s basically airtable or salesforce or flutterflow, and guess what, those applications all kind of suck because a form is not as standard as you think. In a good application, there will always be customized design, flow and logic that happens to capture user input on the frontend, and on the backend there are a myriad of reasons to optimize different databases for different things. Look at the limitations you run into with Salesforce and Airtable databases because every database needs to have a whole plethora of features just to support the frontend Gui interface to manipulate them. I mean if you just want a flat form use Google forms, if business logic starts connecting some of the fields with complicated relationships and flows then suddenly things aren’t so standard.