Databases?

[MichaelBrauner]

I really want to try out this new framework.

But I notice that the docs don't say anything about databases.

I mean Symfony has Doctrine, Laravel Eloquent.

I think some kind of ORM is something that's just part of a full-stack framework. Don't you think so?

Or am I missing something? How do you deal with databases?

[nyzd]

I have this issue too.

[MichaelBrauner]

I mean "real" Full-Stack-Frameworks like Django, Rails and like mentioned above (Symfony, Laravel) all have deep integrations for the database layer.

If this is not present or not even intended, than fresh is, if you break it down to the essentials, just another Gatsby with another tech stack and architecture. It just deals with the representation layer. That's not Full-Stack in my opinion.

[nyzd]

I want to use Prisma and I realized Deno doesn't have a Prisma package. I think document is not completed.

[MichaelBrauner]

@AzerothA - yes I know that you can use external services - like with Gatsby :D. For me that's not a Full-Stack-Framework, when it dependents on external services by default.

[marcus-sa]

@MichaelBrauner where does it even say anything about Fresh being a "full-stack framework"?

[MichaelBrauner]

@marcus-sa Here

[xstevenyung]

There is some information about database in the Deno Deploy documentation but I agree that some information should be included in the documentation to guide new people into Deno / Fresh

[MichaelBrauner]

@xstevenyung Ok, that means Fresh is by default dependent on an external database layer. Even if you choose to use something like Supabase (and pay for it) - you have to write your own plain SQL queries. Also that's far away from what I'm used to with web frameworks.

Thank you - for the hint. Wish you guys all the best.

[kamedan]

i think you can use eveningkid or denodb

[MichaelBrauner]

@kamedan Oh, that's cool.

Maybe fresh can make some kind of collaboration with denodb. Like Symfony does: Doctrine is a different project - but it is deeply integrated Symfony and present all over the docs.

[marcus-sa]

@marcus-sa Here

Do you know what a full stack framework is? It's a framework you can leverage to build both frontend and backend apps with, such as Next, Remix etc. It doesn't mean at all that there should be other tools integrated by default. I can see why it would be common to assume that there would be default components/modules that come with Fresh.

[MichaelBrauner]

Do you know what a full stack framework is? It's a framework you can leverage to build both frontend and backend apps with, such as Next, Remix etc. It doesn't mean at all that there should be other tools integrated by default. I can see why it would be common to assume that there would be default components/modules that come with Fresh.

Yes I know what a full stack framework is.

Imagine the big full stack frameworks like Rails, Django, Symfony etc. remove their database integrations - I am pretty sure, they would be removing their popularity and userbase to quite an extend.

I am also pretty sure that nobody really needs the next javascript frontend framework.

IMHO, once the data layer is completely ignored and the focus is entirely on the representation layer by default, it is just the next fancy frontend framework.

[crgeary]

Having the ability to pick & choose the choice of database layer / ORM is what makes tools like Next so much more powerful than they would have been if they tried to do it all.

In my opinion, I don't think Fresh needs 1st party database support. Someone can do for Fresh what Blitz did for Next, and build upon it to create a 'full stack framework' with extra features.

[thebearingedge]

It seems to work ok.

To me, the weirdest part of these newer frameworks is the implicit statelessness of the server-side code. It's assumed that you will tear everything down when you're done so you are serverless-ready. Although, I suppose that if you are self-hosting you could set up a singleton module for your db pooling.

But after messing with ORMs and crap like that for several years, just writing the SQL is better. It's more performant and doesn't have a weird "SQL with a thick accent" phenomenon. You need tests anyway for important/complex queries so the "type safety" of heavy ORMs doesn't buy you anything without sacrificing the power of the language. Stuff like Prisma is like 3x more verbose than the actual SQL the second you need moderately sophisticated aggregates. Sorry this turned into an ORM rant 😂

[marcus-sa]

It seems to work ok.

To me, the weirdest part of these newer frameworks is the implicit statelessness of the server-side code. It's assumed that you will tear everything down when you're done so you are serverless-ready. Although, I suppose that if you are self-hosting you could set up a singleton module for your db pooling.

But after messing with ORMs and crap like that for several years, just writing the SQL is better. It's more performant and doesn't have a weird "SQL with a thick accent" phenomenon. You need tests anyway for important/complex queries so the "type safety" of heavy ORMs doesn't buy you anything without sacrificing the power of the language. Stuff like Prisma is like 3x more verbose than the actual SQL the second you need moderately sophisticated aggregates. Sorry this turned into an ORM rant 😂

https://deepkit.io/library/orm - come again?

[nhrones]

Come again? The link and playground code seems to prove the point - 3x more verbose - too much cruft!

[thegaryroberts]

It does currently require the developer to manually build an integration with a database layer or storage solution. If it was 2017 it would be the labelled as a hot new "Isomorphic Web Framework". The branding (that solely appears in one readme file) is perhaps a bit misleading.

I am also pretty sure that nobody really needs the next javascript frontend framework.

But either way it fills a gap, as I did in fact need the next Typescript frontend framework for Deno. And this was/is the best one I found.

[marcus-sa]

Come again? The link and playground code seems to prove the point - 3x more verbose - too much cruft!

Yeah, but he mentioned using ORMs would decrease speed, which isn't the case with Deepkit ORM.

[juls0730]

I would like to say If fresh is supposed to be a fullstack framework, there's no mention of fullstack on their website so It's probably not trying but if it was, better ORMs are definitely needed (or the current ones need better documentation), a built-in one would be great to see as well but who knows, any also a Redis connector would be nice too.

[lucacasonato]

This is something that will come in the future. It is just not something that we have a satisfactory solution in time for the 1.0 release.

[LoganTann]

denodb

Denodb is very easy to take in hand, but is unfortunately not mature enough to be production ready. I've been using it since more than one week (not with the fresh framework though; just with deno aqua).

There is a lack of contributors, and the original dev don't seems to have enough time to review all issues and pull requests :(

Btw, sorry to come into this isue just to talk about my opinion. I'd be very happy to move on a github discussion thread (https://github.com/denoland/fresh/discussions) so we can continue talking about fresh, databases and ORMs in deno :)

[vorcigernix]

I'd support moving this to discussion. The original feature request is not clear (Fresh does support databases). For me, the first thing I'd need to solve is caching and graphql, I can definitely live without ORM. So, it is an interesting subject for opinionated discussions, but not a great feature request.

[juls0730]

I'd support moving this to discussion. The original feature request is not clear (Fresh does support databases). For me, the first thing I'd need to solve is caching and graphql, I can definitely live without ORM. So, it is an interesting subject for opinionated discussions, but not a great feature request.

I couldn't agree more, caching and graphql are a must for me if this is to be considered a fullstack web framework

[vorcigernix]

As much as I agree this is helpful and important, I respectfully disagree with the idea of anything we discuss as a "must have" for fullstack framework. Fresh is a fullstack framework - it can execute code on both server and client. Fun fact - Rails and Laravel are not. They work only on server side, if you need to write a client functionality, you need to use a JavaScript (usually a client only framework like React). I'm not writing this to amaze you with my knowledge, but 1) Terminology is important for further discussion. 2) Contributors to this amazing project can feel demotivated by unfair criticism.

On Tue, Jul 5, 2022, 7:25 PM juls0730 @.***> wrote:

I'd support moving this to discussion. The original feature request is not clear (Fresh does support databases). For me, the first thing I'd need to solve is caching and graphql, I can definitely live without ORM. So, it is an interesting subject for opinionated discussions, but not a great feature request.

I couldn't agree more, caching and graphql are a must for me if this is to be considered a fullstack web framework

— Reply to this email directly, view it on GitHub https://github.com/denoland/fresh/issues/336#issuecomment-1175315072, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABLZOFY53AWIZAQSF4FUI3VSRVZJANCNFSM52IELCLQ . You are receiving this because you commented.Message ID: @.***>

[LoganTann]

Hello, may we move into this discussion thread : https://github.com/denoland/fresh/discussions/436

A github discussion topic seems more relevant for further discussion about this issue 😊

[buzinas]

It seems to work ok.

To me, the weirdest part of these newer frameworks is the implicit statelessness of the server-side code. It's assumed that you will tear everything down when you're done so you are serverless-ready. Although, I suppose that if you are self-hosting you could set up a singleton module for your db pooling.

But after messing with ORMs and crap like that for several years, just writing the SQL is better. It's more performant and doesn't have a weird "SQL with a thick accent" phenomenon. You need tests anyway for important/complex queries so the "type safety" of heavy ORMs doesn't buy you anything without sacrificing the power of the language. Stuff like Prisma is like 3x more verbose than the actual SQL the second you need moderately sophisticated aggregates. Sorry this turned into an ORM rant 😂

Maybe you'll be as surprised (and delighted) as I was if you check EdgeDB (that runs on top of Postgres).

[MichaelBrauner]

@marcus-sa I think nobody ever worked with the integration of doctrine into Symfony framework to some extend would ever like to miss it.

It's just too good. Define an Entity, run a command to create your controller actions and even forms and lists are created for you. Then modify it. Even if you decide to don't use the code generator it's super easy, clear and flexible.

For example a form object can hold an Entity. Press submit on a Symfony form - and this entity gets saved into the correct database structure after the form is validated - no matter how deeply nested that is. Super cool.

For smaller projects it may be ok, to write that SQL all by your own over and over again, but for bigger projects or software ecosystems I need some structure.

I did big systems with that and it's super clean and super integrated and nothing is missing.

I really don't want to go back to 2012 when I wrote my own 200 Line sql monster queries and spend a day just for debugging when something weird happened.

[marcus-sa]

@marcus-sa I think nobody ever worked with the integration of doctrine into Symfony framework to some extend would ever like to miss it.

It's just too good. Define an Entity, run a command to create your controller actions and even forms and lists are created for you. Then modify it. Even if you decide to don't use the code generator it's super easy, clear and flexible.

For example a form object can hold an Entity. Press submit on a Symfony form - and this entity gets saved into the correct database structure after the form is validated - no matter how deeply nested that is. Super cool.

For smaller projects it may be ok, to write that SQL all by your own over and over again, but for bigger projects or software ecosystems I need some structure.

I did big systems with that and it's super clean and super integrated and nothing is missing.

I really don't want to go back to 2012 when I wrote my own 200 Line sql monster queries and spend a day just for debugging when something weird happened.

Then use an existing ORM? I'm beyond surprised that you EXPECT an ORM to be directly integrated with Fresh. You're still totally confused on the term "full stack" framework. Symfony wasn't a full stack framework. Why do you even compare Symfony to Fresh? What have controllers got to do with this? It's difficult to have a discussion when you're comparing apples to oranges.

[MichaelBrauner]

@marcus-sa I think nobody ever worked with the integration of doctrine into Symfony framework to some extend would ever like to miss it. It's just too good. Define an Entity, run a command to create your controller actions and even forms and lists are created for you. Then modify it. Even if you decide to don't use the code generator it's super easy, clear and flexible. For example a form object can hold an Entity. Press submit on a Symfony form - and this entity gets saved into the correct database structure after the form is validated - no matter how deeply nested that is. Super cool. For smaller projects it may be ok, to write that SQL all by your own over and over again, but for bigger projects or software ecosystems I need some structure. I did big systems with that and it's super clean and super integrated and nothing is missing. I really don't want to go back to 2012 when I wrote my own 200 Line sql monster queries and spend a day just for debugging when something weird happened.

Then use an existing ORM? I'm beyond surprised that you EXPECT an ORM to be directly integrated with Fresh. You're still totally confused on the term "full stack" framework. Symfony wasn't a full stack framework. Why do you even compare Symfony to Fresh? What have controllers got to do with this? It's difficult to have a discussion when you're comparing apples to oranges.

I did take a look on fresh because It was mentioned as a full stack framework for deno. That made me curious. But I don't blame fresh for not being a full stack framework in my definition. It's totally fine.

I just want to point out that a deep integrated ORM can be kinda nice and as more and more complexity (translation, revisions, nested sets ...) is needed, writing barebone sql queries is not the best solution in my opinion.

I don't compare apples with oranges. I just say it can be worth to not just use an ORM but to write a framework around it. Like Symfony and Django do.

But that's just my opinion at the moment because I am used to it ;).

[marcus-sa]

@MichaelBrauner If you weren't using Deno, I'd suggesting checking out Deepkit

[dector]

@buzinas

Maybe you'll be as surprised (and delighted) as I was if you check EdgeDB (that runs on top of Postgres).

OMG! Thanks a lot for the recommendation! It's absolutely amazing, functional and super easy to pick-up. 🔥

[talebisinan]

I want to use Prisma and I realized Deno doesn't have a Prisma package. I think document is not completed.

@AzerothA There is a possibility to use Prisma now with version 4.3.0. Following the instructions on Deploy to Deno Deploy should help.

[hashrock]

Close to clarify that we have moved to Discussion(https://github.com/denoland/fresh/discussions/436)