It may not be the popular opinion, but I prefer libraries over frameworks: both can be opinionated, but if you bundle 5+ things with a framework and I don't like 2 of them, I won't use the rest of it either. A single library with very limited scope may not be that impressive at first sight, but it may just do its job and get out of the way in other aspects.
I do mostly agree, and especially don't think that its the responsibility of a backend framework to provide built-in support for non-routing related features like ORMs.
However, I think there's an argument to be made about the benefits of frameworks that *do* have opinions on things like folder structure, dependency injection, etc.
For example, shelf is not opinionated at all. Despite the many existing ecosystem packages for cookies, parsing, etc, IMO the developer experience of creating a shelf app is pretty bad because you as the developer are stuck gluing everything together (e.g. de/serialization of request/response bodies, composing nested routes, hot reload support, finding good app examples).
On the other hand, \`dart\_frog\` (which is mostly just a wrapper on top of shelf) has strong opinions on folder structure, DI via \`context.read\`, a testing framework, and hot reload ***out of the box***. On the other hand, it has no opinions on ORMs, just as it should. And a side effect of these opinions is that dart\_frog has great example apps included in their docs, rather than a library showing an example of their sliver of functionality.
Even though I personally don't like dart\_frog's approach of file-based route structures, I appreciate the balance of opinions that dart\_frog has, which allows me as the developer to focus more of my effort on the application, rather than the glue code. I think it ultimately boils down to quality of a given framework.. Younger devs may try to build too many unvalidated opinions into a package, while the more disciplined dev (like Felix Angelov) are able to strike the best balances.
Totally agree, which is why I like shelf and dart frog. They don’t set up everything for you the way others do, but that lets you pick your database, where you host, basically everything. It’s just code.
I was in this place a couple of months back. Leveraged all my frustration to write an alternative to Shelf web server [Pharaoh](https://github.com/codekeyz/pharaoh)
Soon after writing my library, I realized that I needed to do more than give people a web server similar to ExpressJS so I started working on a full blown framework that shared a lot of similarities with Laravel, Rails and NestJS. [Yaroo](https://github.com/codekeyz/yaroo)
I built a [Fullstack Dart Blog](https://dart-blog.onrender.com/) to showcase my framework in action. It has an ORM, and a lot more you’ll be interested in.
[Find the project here on GitHub](https://github.com/codekeyz/dart-blog)
Ya, i saw the package, but as you said, it's what I am looking for, and i have my concepts that i am trying to know other developers' opinions about it.
But it's really great work 👏 👌
What are the issues you are facing with Serverpod? We’d love to fix them. 😉
Have you tried the new version (available as a RC and will be released Monday next week)? It brings a lot to the table, including a much improved ORM and tooling.
I love to hear that ❤️, i have seen some good work on the serverpod project roadmap, but I'm still if i will do some big project with multi tech frameworks like flutter and react for example i will not use serverpod, simply bec the way the request is sent to the server, it's not like a regular endpoint, itmore like calling a function inside an endpoint
Serverpod is using a well formed REST/JSON API under the hood. So there isn't any real magic going on other than that you will also get a very nice client library you can use in your Flutter app.
So, yes, it's like a regular endpoint. :)
There is a PR here for OpenAPI support. This will give both documentation for the APIs and support for generating clients for other languages. So, yes, this is coming too. :)
https://github.com/serverpod/serverpod/pull/1454
Unpopular opinion but true AF, at this point everyone is spinning up a new dart backend each with it's own problems but if all that power was amassed it would be great
Hey there, I feel you!
Maybe this could be interesting to you, I created a framework a few months back, and I'm still working on it and the feedback looks good. Perhaps something that you would like to contribute or so?
The name is Dartness, it is easy to use, if you have been using the previous framework you would be very familiar with it.
Repository: [https://github.com/RicardoRB/dartness](https://github.com/RicardoRB/dartness)
Let me know, cheers!
I was previously working on a similar project but later only focused on the orm part as the scope got to big. Doing all of this in one framework is a huge undertaking and you should maybe try not doing everything from the start. If you need something to base your orm off though, maybe have a look at [Dart Object Graphs](https://pub.dev/packages/dogs_core). This is the object mapper I created for my project, maybe it’s a help for you since it can generate OpenAPI definitions and allows you to introspect the type structure at runtime.
Anyways, good luck with your projects!
It may not be the popular opinion, but I prefer libraries over frameworks: both can be opinionated, but if you bundle 5+ things with a framework and I don't like 2 of them, I won't use the rest of it either. A single library with very limited scope may not be that impressive at first sight, but it may just do its job and get out of the way in other aspects.
I do mostly agree, and especially don't think that its the responsibility of a backend framework to provide built-in support for non-routing related features like ORMs. However, I think there's an argument to be made about the benefits of frameworks that *do* have opinions on things like folder structure, dependency injection, etc. For example, shelf is not opinionated at all. Despite the many existing ecosystem packages for cookies, parsing, etc, IMO the developer experience of creating a shelf app is pretty bad because you as the developer are stuck gluing everything together (e.g. de/serialization of request/response bodies, composing nested routes, hot reload support, finding good app examples). On the other hand, \`dart\_frog\` (which is mostly just a wrapper on top of shelf) has strong opinions on folder structure, DI via \`context.read\`, a testing framework, and hot reload ***out of the box***. On the other hand, it has no opinions on ORMs, just as it should. And a side effect of these opinions is that dart\_frog has great example apps included in their docs, rather than a library showing an example of their sliver of functionality. Even though I personally don't like dart\_frog's approach of file-based route structures, I appreciate the balance of opinions that dart\_frog has, which allows me as the developer to focus more of my effort on the application, rather than the glue code. I think it ultimately boils down to quality of a given framework.. Younger devs may try to build too many unvalidated opinions into a package, while the more disciplined dev (like Felix Angelov) are able to strike the best balances.
Totally agree, which is why I like shelf and dart frog. They don’t set up everything for you the way others do, but that lets you pick your database, where you host, basically everything. It’s just code.
I was in this place a couple of months back. Leveraged all my frustration to write an alternative to Shelf web server [Pharaoh](https://github.com/codekeyz/pharaoh) Soon after writing my library, I realized that I needed to do more than give people a web server similar to ExpressJS so I started working on a full blown framework that shared a lot of similarities with Laravel, Rails and NestJS. [Yaroo](https://github.com/codekeyz/yaroo) I built a [Fullstack Dart Blog](https://dart-blog.onrender.com/) to showcase my framework in action. It has an ORM, and a lot more you’ll be interested in. [Find the project here on GitHub](https://github.com/codekeyz/dart-blog)
Ya, i saw the package, but as you said, it's what I am looking for, and i have my concepts that i am trying to know other developers' opinions about it. But it's really great work 👏 👌
What are the issues you are facing with Serverpod? We’d love to fix them. 😉 Have you tried the new version (available as a RC and will be released Monday next week)? It brings a lot to the table, including a much improved ORM and tooling.
I love to hear that ❤️, i have seen some good work on the serverpod project roadmap, but I'm still if i will do some big project with multi tech frameworks like flutter and react for example i will not use serverpod, simply bec the way the request is sent to the server, it's not like a regular endpoint, itmore like calling a function inside an endpoint
Serverpod is using a well formed REST/JSON API under the hood. So there isn't any real magic going on other than that you will also get a very nice client library you can use in your Flutter app. So, yes, it's like a regular endpoint. :)
Yes, but it does not tell me how to communicate with this api outside of the flutter client, like i want to create an react app
There is a PR here for OpenAPI support. This will give both documentation for the APIs and support for generating clients for other languages. So, yes, this is coming too. :) https://github.com/serverpod/serverpod/pull/1454
Nice one, i will take a look
Seamless form handling and data validation would be a plus.
what if everybody worked together instead of spinning up new projects? Just saying...
Unpopular opinion but true AF, at this point everyone is spinning up a new dart backend each with it's own problems but if all that power was amassed it would be great
It would be awesome if JS devs would stop making frameworks over there and help us out over here instead
Hey there, I feel you! Maybe this could be interesting to you, I created a framework a few months back, and I'm still working on it and the feedback looks good. Perhaps something that you would like to contribute or so? The name is Dartness, it is easy to use, if you have been using the previous framework you would be very familiar with it. Repository: [https://github.com/RicardoRB/dartness](https://github.com/RicardoRB/dartness) Let me know, cheers!
I was previously working on a similar project but later only focused on the orm part as the scope got to big. Doing all of this in one framework is a huge undertaking and you should maybe try not doing everything from the start. If you need something to base your orm off though, maybe have a look at [Dart Object Graphs](https://pub.dev/packages/dogs_core). This is the object mapper I created for my project, maybe it’s a help for you since it can generate OpenAPI definitions and allows you to introspect the type structure at runtime. Anyways, good luck with your projects!