3 ms·

for simple web application backends, why does one need more than just "models" (structs, that describe database tables/rows, using something like "an ORM" but m

for simple web application backends, why does one need more than just "models" (structs, that describe database tables/rows, using something like "an ORM" but more lightweight, so as to provide query building, caching, etc.) and "routes" (procedures, mapped to URL patterns, that execute logic such as accessing models (cached or queried) and then responding with output from a simple HTML template system, or possibly a cached template rendering, or JSON)? I was never trained/educated in the MVC pattern but back when Rails was new and I was trying it out, it just seemed like a lot of unnecessary boilerplate, and it was cool that Rails helps you scaffold it out and all—but why? I'm working on building a framework that is more or less what I describe above, and so far it's going great. I can make simple CRUD apps with it pretty dang easily. I don't really have an interest in using React or whatever the newest frontend framework is to do fancy front-end stuff. is there something I'm missing, or does my approach seem reasonable? I just don't really see the need for having separate Vs and Cs when it comes to web backend things. this article helped give me a bit more context as to where these ideas came from, and I appreciate it, but as of right now, as the article itself and some other commenters have mentioned, it doesn't seem to make sense to take this MVC pattern as-is and apply it to contemporary backend web development. but, I've never built websites from scratch that were bigger than "small to medium", so it's possible there's something I'm missing?

yawnxyz 3y ago
I'm using Sveltekit and doing pretty much what you're doing, and never touched Rails before. I'm equally confused about the MVC pattern I hear so much, and why it was so big back then, and why it isn't very big now. Was this more of a design / architecture "fad" or a design around the constraints of the time?
- lizardking 3y ago
  MVC offered a formalized separation of concerns for data, ui, and business logic at a time when many developers were cramming all of their application code into massive php or C# files. The pattern was delivered via frameworks (RoR, Cake, Asp.net MVC) that handled a lot of the boiler plate for you and made for an easier development experience than what most of the people switching to it were used to at the time. As web applications became more focused on the client code, the template driven server side rendering capabilities of these frameworks was less useful or no longer necessary. Initially when the mindshare began to move to the client code, front end tool chains actually did do a lot of hemming and hawing of what variant of mv* they were. Eventually tools like react came around and whatever variant of mv* they were wasn’t what was interesting about the building paradigm. More or less that’s where we are now.
adasdasdas 3y ago
If you are building a framework to do that, you are probably just reinventing React
- adamrezich 3y ago
  how so? I was under the impression React is a frontend framework, and I'm exclusively talking about the backend here. (plus, my thing is compiled to a single executable and not using JavaScript.)
  - adasdasdas 3y ago
    React is just a way to procedurally generate templated HTML in the frontend. You can do the same thing in the backend but it just makes rerenders more expensive which could matter depending on how input heavy your application is. For example, if you update a row in the table, do you have to reload the entire page or just the row?
    - adamrezich 3y ago
      my bad, I wrote "web application" above—I meant to say "website", like, year-2008-level-of-interactivity stuff. I'm neither interested in nor proposing a solution for anything on the frontend side of things at all, because I'd suspect you're correct, I would probably just reinvent React et al.
gls2ro 3y ago
one my wonder about what could this be: > routes" (procedures, mapped to URL patterns, that execute logic such as accessing models (cached or queried) A "route" that executes logic such as accessing models responding with an output based on what mime type was requested, can set a layout or template for the view ... changing the name to "route" does not change the pattern that you are implementing here. Rails Controllers are doing exactly everything that you describe here with the only exception that there is a big table that keeps references between a URL and the controller method associated with that URL. I am not saying Rails is better than what you build, but just noticed that a lot of what you describe as a "route" is matching what a controller is doing.
- adamrezich 3y ago
  it's been a very long time since I did anything with Rails… but I recall there being Ruby code in the "Views", which is something I'm choosing to avoid entirely. all logic is executed in the "Route" (or whatever it's called in the end) procedure, which is where, if you want to output HTML, you invoke a "Render" macro that takes in the template name and optionally any variables you want to pass in. the HTML templates have a simple, Mustache-like syntax (insert parameter, insert nested template/"partial"), but it's just plain HTML with some {{placeholdery-looking stuff}}. maybe I'll add a JSON "renderer" if I need it, and I still need to get static file loading to work, but other than that, this framework does pretty much everything I want to do as far as website backends go, and it compiles to a single executable. it's not going to be The Future Of Web Development, but it will be nice (for me at least) to make small-to-medium-sized websites with, in large part because it's much easier for me to reason about "Models (structs), Routes (code), Templates (HTML)" than "MVC", or at least, how I remember "MVC" feeling in Rails, and Django.
pravus 3y ago
You don't need more than what you have. You have essentially built a minimal MVC. Everything else you add is just stuff that other people added to other MVC projects to make life easier for them in some way. Web MVCs are basically just opinions on the way to handle HTTP requests and are meant to speed up the dev process if you agree with all of its boilerplating/tooling. My only recommendation is to just keep yourself aware of url/form encodings, path handling, and common pitfalls related to handling HTTP requests in general.
- adamrezich 3y ago
  cool, thanks for the insight. are there any materials you'd recommend for reading up on this kind of stuff? I have a fair bit of insight from having done things in various frameworks over the years, but if there's any resources you have in mind, I'd be more than happy to take a look.

yawnxyz 3y ago

I'm using Sveltekit and doing pretty much what you're doing, and never touched Rails before. I'm equally confused about the MVC pattern I hear so much, and why it was so big back then, and why it isn't very big now. Was this more of a design / architecture "fad" or a design around the constraints of the time?

lizardking 3y ago
MVC offered a formalized separation of concerns for data, ui, and business logic at a time when many developers were cramming all of their application code into massive php or C# files. The pattern was delivered via frameworks (RoR, Cake, Asp.net MVC) that handled a lot of the boiler plate for you and made for an easier development experience than what most of the people switching to it were used to at the time. As web applications became more focused on the client code, the template driven server side rendering capabilities of these frameworks was less useful or no longer necessary. Initially when the mindshare began to move to the client code, front end tool chains actually did do a lot of hemming and hawing of what variant of mv* they were. Eventually tools like react came around and whatever variant of mv* they were wasn’t what was interesting about the building paradigm. More or less that’s where we are now.

adasdasdas 3y ago

If you are building a framework to do that, you are probably just reinventing React

adamrezich 3y ago
how so? I was under the impression React is a frontend framework, and I'm exclusively talking about the backend here. (plus, my thing is compiled to a single executable and not using JavaScript.)
- adasdasdas 3y ago
  React is just a way to procedurally generate templated HTML in the frontend. You can do the same thing in the backend but it just makes rerenders more expensive which could matter depending on how input heavy your application is. For example, if you update a row in the table, do you have to reload the entire page or just the row?
  - adamrezich 3y ago
    my bad, I wrote "web application" above—I meant to say "website", like, year-2008-level-of-interactivity stuff. I'm neither interested in nor proposing a solution for anything on the frontend side of things at all, because I'd suspect you're correct, I would probably just reinvent React et al.

gls2ro 3y ago

one my wonder about what could this be: > routes" (procedures, mapped to URL patterns, that execute logic such as accessing models (cached or queried) A "route" that executes logic such as accessing models responding with an output based on what mime type was requested, can set a layout or template for the view ... changing the name to "route" does not change the pattern that you are implementing here. Rails Controllers are doing exactly everything that you describe here with the only exception that there is a big table that keeps references between a URL and the controller method associated with that URL. I am not saying Rails is better than what you build, but just noticed that a lot of what you describe as a "route" is matching what a controller is doing.

adamrezich 3y ago
it's been a very long time since I did anything with Rails… but I recall there being Ruby code in the "Views", which is something I'm choosing to avoid entirely. all logic is executed in the "Route" (or whatever it's called in the end) procedure, which is where, if you want to output HTML, you invoke a "Render" macro that takes in the template name and optionally any variables you want to pass in. the HTML templates have a simple, Mustache-like syntax (insert parameter, insert nested template/"partial"), but it's just plain HTML with some {{placeholdery-looking stuff}}. maybe I'll add a JSON "renderer" if I need it, and I still need to get static file loading to work, but other than that, this framework does pretty much everything I want to do as far as website backends go, and it compiles to a single executable. it's not going to be The Future Of Web Development, but it will be nice (for me at least) to make small-to-medium-sized websites with, in large part because it's much easier for me to reason about "Models (structs), Routes (code), Templates (HTML)" than "MVC", or at least, how I remember "MVC" feeling in Rails, and Django.

pravus 3y ago

You don't need more than what you have. You have essentially built a minimal MVC. Everything else you add is just stuff that other people added to other MVC projects to make life easier for them in some way. Web MVCs are basically just opinions on the way to handle HTTP requests and are meant to speed up the dev process if you agree with all of its boilerplating/tooling. My only recommendation is to just keep yourself aware of url/form encodings, path handling, and common pitfalls related to handling HTTP requests in general.

adamrezich 3y ago
cool, thanks for the insight. are there any materials you'd recommend for reading up on this kind of stuff? I have a fair bit of insight from having done things in various frameworks over the years, but if there's any resources you have in mind, I'd be more than happy to take a look.