I think I saw this early on, but then forgot about it. Stumbled upon it today, and it actually looks like a cool project. Have anyone any experience of using it for a real or just a toy project?
Have not used it myself, but having a quick look at it I don’t think I likely ever will. Mostly for personal preferences with the projects goals and design than anything else.
I don’t like large do everything frameworks. They are ok when you want to do what they were designed for. But as soon as you step outside that they become a nightmare to deal with. They also tend to grow more complex over time as more of what everyone wants gets added to them. A framework author’s case against frameworks is a great talk on the matter. Instead I prefer simpler smaller focused libraries that I can pick and choose from that best suit the application I want to build.
Also it seems like the MVC pattern, which I dislike. Personally I like to group code that changes together next to each other. Where as MVC groups code that has the same function together and splits up code that tends to change together. This means for any change or feature you are editing many files across many folders which gets tedious rather than just co-locating all the related code in one directory or file.
Because they include all dependencies for everything you might want they often lag behind upstream projects. This was a huge issue for me years ago when I tried out the Rocket framework. I wanted to use a hosted postgres DB that only supported https connections but the version of the library it was using did not yet include that feature - basically killing the project there.
They can be great if they do everything you want in the way you want and loco looks to be well built and maintained overall. But I find far too often that they don’t, if not at the start of a project then eventually as my projects evolve (which is far worst). I would also question its staying power though (we have seen popular and promising frameworks before that suddenly stop development) but only time will answer that.
The MVC pattern is really good for writing your endpoints.
In C# I use the mediator pattern and vertical slice.
This means the controller handles everything http related and then sends the mediator request and converts the response back to http responses.
This means I can structure my code however I want and the controllers have no awareness of it and just deal with http.
We are moving to the controller-service-repository pattern for our backend services. Basically:
- controller - handles user input, calls services, formats responses
- service - business logic
- repository - database access
This makes the code a lot more testable.
Our frontends basically do React-style MVC, which helps reduce bugs from internal state not matching the model.
Tbh that’s essentially what we do. Just with a mediator between the controller and services. Maybe a better name for it.
Ok, so it sounds like our controller is doing the mediator role, and our web framework (with the middleware and whatnot) is doing your controller work.
Our project is in Python with Flask, and Flask + middleware handles general stuff (authentication, parsing headers, etc), which is common for most requests, and then the controller loads the metadata into structures (JSON, query params, etc) with basic validation (ranges, values for enums, etc), and the service takes it from there.
AspNetCore works very much the same.
The mediator pattern is a little different though. It doesn’t talk to the service directly.
The controller creates a request object and passes it to the mediator. The mediator finds the correct handler and invokes it. The result is then returned to the controller.
It essentially completely decouples the controller from the service.
Ah, makes sense. Thanks!
This is a very good and interesting answer, thank you!
Have you taken a look to pavex? Do you think it will fall into the same path?
Looks to be in a closed beta so I cannot really tell much from it but that it is trying to be an all in one framework like rails… so to me would suffer from the same issues I mentioned as they are not really loco specific, just issues with frameworks in general.
What I feel looks interesting with “on rails” is that you get things like database management built in, like setup, upgrades aso. Of course, this also means that it might be difficult to jump off the rails if you need that. And even if I feel like I’m not the target audience, since I prefer to pick and choose smaller libraries, I’m watching this with interest since Ruby on Rails seems to be quite popular.
Rails is great for starting an app, you can get something to a functional MVP state in a ridiculously small amount of time. We used to do rapid prototyping where we could be shipping it to the client in like 2-4 weeks. I haven’t found anything that comes close to this elsewhere.
But you’re right that the big trade off is jumping off is effectively impossible, because Rails is your app. Most criticism that I see (and feel is valid) is that unless you’re willing to do a whole rewrite you will be on Rails forever. I think this is a more reasonable trade off than I see represented online; “long terms Rails is a nightmare” comes up a lot and I don’t think it’s that bad.
I personally like that we’re seeing options for both strategies here popping up. More options is good for us as devs.
As a non-Rails-developer running some apps based on it long-term the most annoying thing about Rails when trying to debug an issue in a code-base that isn’t yours is all the auto-magic stuff where the usual way to find the function called doesn’t work because it is magically auto-generated in the background somewhere out of strings concatenated together.
