Open aldrinmathew opened 3 years ago
I'm working on a project that requires an HTTP server and some kind of ORM data presentation model. Initially, I used an aqueduct, but with the closure of the project, I began to write my own server and managed to implement the part that is related to HTTP. Then I saw your library and decided to take a shortcut. I think I can help write your framework, it would be a good experience for me.
@ifuterman
Glad to hear that you are interested. I actually have no idea on how to implement an ORM from scratch. So your interest is of great use for the project and the community. I have written some basic abstraction for Server, Route and UrlParameters. But that's not even barely boilerplate.
Are you fine with me adding you as a contributor to the project?
Thank you all for your interest in this. I think this is really important work but we should be careful about planning things before going forward in my opinion.
What was the major value add with aqueduct was their ability to provide an ORM and also more importantly the ability to run database migrations with that ORM. If something like this can be released to users that is maintained that would be a unbelievable value add to the community.
regarding the rest of what aqueduct does, I would vote for a more modular approach rather than some other huge framework. It would be great to have someone focused on moving the code over from the acqueduct ORM and providing users value there first and separating out the other value streams, such as HTTP middleware, etc
On April 23, 2021, Sean Pianka @.***> wrote:
@ifuterman https://github.com/ifuterman
Glad to hear that you are interested. I actually have no idea on how to implement an ORM from scratch. So your interest is of great use for the project and the community. I have written some basic abstraction for Server, Route and UrlParameters. But that's not even barely boilerplate.
Are you fine with me adding you as a contributor to the project?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aldrinsartfactory/liquidart/issues/7#issuecomment- 825691244, or unsubscribe https://github.com/notifications/unsubscribe- auth/AAASQON7LXVVCC245CUEB43TKF6UPANCNFSM43M66WHA.
@ifuterman
Glad to hear that you are interested. I actually have no idea on how to implement an ORM from scratch. So your interest is of great use for the project and the community. I have written some basic abstraction for Server, Route and UrlParameters. But that's not even barely boilerplate.
Are you fine with me adding you as a contributor to the project?
Ok. But from tomorrow until 06.05 I'm on vacation in the mountains. The Russian North Caucasus challenged me, after i could
ORM has 2 main issues
Codegeneration is clear task but first issue to hard for me at this moment. Now i have http server on isolates, and some code in ORM. But the first issue stoped me:)
I am an amateur programmer(who only know about flutter and Dart)from China,I may can't help anything,but I do thank you for what you do now,I wish you every success...祝你们,一帆风顺。
@AldrinMathew If you're still interested in using the Aqueduct codebase, we're pretty stable now. https://discord.gg/FyJj45NXPx
Just looking for beta testers. One user switched over from an old version of Aqueduct to Conduit and converted his code to NNBD and claims to have reolsved the issue of his migrations stalling out. Apparently this project was in a production environment.
I put the word out that I was looking for collaborators for almost two months now. Lol did you just not see it?
@seenickcode Thanks for the input and suggestion. The server abstraction is already in progress, and it is going well. There will not be an ORM initially. Mostly because it is not easy to port into the rewritten framework. And I kind of had to reinvent some of the concepts while writing the server part of the framework. I have been thinking about initially providing some utilities to use when communicating with the database, instead of an ORM. Projects like Hive, PostgREST and database all seems to be pretty good.
If conduit picks up the pace and jaguar and alfred gains more attention, then I might not even have to go forward with rewriting aqueduct. But I will do it anyway. This was never intended to be a product. This was supposed to be a dependency framework of a huge project that I have been working on. I intended the dependency to be aqueduct, but later found out that it was abandoned. Even the logo of liquidart was initially designed by me for another Open Source project completely unrelated to Dart and Servers.
@j4qfrost I actually saw conduit while I was beginning to refactor aqueduct to liquidart. But there was no readme, documentation or information regarding the project, so at that time I thought that someone was just trolling by creating a dummy package. I just listened to the meeting about the conduit project and now I honestly think that conduit will be what I wanted aqueduct to be. I hope you release the initial version soon so that I can try it out.
I am an amateur programmer(who only know about flutter and Dart)from China,I may can't help anything,but I do thank you for what you do now,I wish you every success...祝你们,一帆风顺。
@DDL1154497347 Thanks for your appreciation and support. I am also an amateur at this. Just exploring more areas of programming one by one. Thanks for this comment.
Hi @AldrinMathew 🖐
Initially, I would like to thank you for reviving the aqueduct as liquidart👍
However, there are some discomforts that can be appeared whether the framework is written fully from scratch. Here is why:
As may you know that the framework created a long time ago and until march, it was supported by old masters. During this period many programmers have included this framework in their business. I believe that it would be hard for them to migrate from Aqueduct to Liquidart if you rewrite all code from scratch.
Reinventing bicycle is bad because it takes a lot of time and the framework grow very slowly.
And other obstacles can appear possibly for you and for old users
I would like to ask you to keep abstraction of Aqueduct.
@II11II @conduit
Don't worry. Even though I am rewriting Liquidart from scratch, the Conduit team is reviving the Aqueduct project, without any breaking changes. So this ensures that the community is provided with what I initially promised. And since I am rewriting Liquidart, I can possibly experiment with the methodologies and possibly provide more intuitive approach to server-side programming. I am also looking forward to contributing to the Conduit Project. I have a designed a logo for the Conduit project and am currently having a discussion about it in their discord server. So, the community will get what they wanted in the end. And once the Conduit team releases their first Stable version, I will link to it from this project so that people will have an option to choose from.
Please read to the end to understand how Liquidart started
22nd April 2021 - 11:10 PM IST
The initial idea I had, before beginning Liquidart was to create a server framework from scratch. At that point, even the name Liquidart didn't exist. The idea was simple. The idea was to provide a minimalistic framework which was fresh and modular, so that people can use it to expand their server applications.
When I found out that Aqueduct was discontinued, I decided to migrate the package and revive it. I actually liked Aqueduct and it was the reason that I never wanted to learn nodejs just for server side programming. There were great tutorials explaining the use of Aqueduct for Server Applications, from programmers like Nick Manning @seenickcode ... The Aqueduct documentation was also helpful in explaining the structure of the framework and the proper way to use it.
The entire Aqueduct package was a nightmare to migrate to Null Safety with more than 6000 errors showing up during migration. It took me 4 consecutive days of work to resolve all of those. I rescheduled all of my other projects to accommodate this. I barely had proper sleep for those 4 days. I hoped that the migration to null safety will prepare the package for publishing. Little did I know that the entire Aqueduct codebase was absolutely messed up. I have been trying to solve some list-related errors for the past 2 days, only to find out that those errors have been present in the project for more than 8 or so months. It was not the migration that caused all these problems. The codebase was messed up even before migration. That's why it is almost impossible to bring this package to a functioning state. And I am all alone working in this project, which makes it even worse.
At this point, after going through so much complexities and troubles trying to revive the project all on my own, I am forced to go back to my initial decision. I will be creating a server framework from scratch and changing the documentation and examples to support the new codebase. I believe that is the right decision to make at this point, especially since the Liquidart package hasn't been adopted by many programmers. It is only a month old. It's better to provide a working alternative than to shove a broken package on people's faces pretending that it is the best thing in the world.