I've been "funemployed" for a few months and with all that free time and idle hands I wrote a full web framework (think Rails, not Flask) for Rust.
It's boring old MVC, has its own ORM, templates, background jobs, auth, websockets, migrations and more. If you're keen but don't feel like rewriting your app in a different language, Rwf has a WSGI server to run Django (or Flask) inside Rust [1], letting you migrate to Rust at your own pace without disrupting your website.
I think Rust makes a great prototyping and deploy straight to production language. Now it has yet another framework for y'all to play with.
Cheers!
(At some point this place has to contend with the issue of “we started as people trying to build cool things and wound up with every thread being nonstop complaints or nitpicking”.)
To be serious, good job!! Building a good framework is a shockingly large task, and it’s always nice to see people exploring the design space and trying for new ideas.
One of my biggest learnings from doing a bunch of web MVC through Rails over the years is that the framework should heavily discourage business logic in the model layer.
Some suggestions:
- Don't allow "callbacks" (what AR calls them) ie hooks like afterCreate in the data model. I know you don't have these yet in your ORM, but in case those are on the roadmap, my opinion is that they should not be.
- That only really works though if you not strongly encourage a service aka business logic layer. Most of my Rails app tend to have all of these as command aka service objects using a gem (library/package) like Interactor.*
* It's my view that MVC (and therefore Rails otb) is not ideal by itself to write a production-ready app, because of the missing service layer.
Also, curious why existing ORMs or query builders from the community weren't leveraged?
Disclaimer: I haven't written a line of Rust yet (more curious as the days go by). I'm more curious than ever now, thanks to you!
I like that... we need more (or better) opiniated frameworks a la rails/django in static languages.
As a heads-up, The Pages documentation page is blank.
[1] https://levkk.github.io/rwf/views/templates/templates-in-con...
From the ReadMe example, is there a way to use macros to simplify the following line of code:
async fn handle(&self, request: &Request) -> Result<Response, Error> {
I ask because many web developers don't come from a C/C++/Rust background - so the line above will be jarring/off-putting to many.(Awesome project btw)
Also, I don't really understand what is the reason for creating your own ORM instead of integrating with, let's say diesel.rs [0] and what is the reason for inventing your own template language instead of just picking one of the most popular existing template engines [1].
Other than that this project looks really interesting and I will definitely keep an eye on it.
Mind you, I don't assert that claim. I don't know; I'm not in web development. But I could see how having to learn a new framework that wouldn't pay back the effort would give rise to some valid complaints.
This is quite the claim. I despise service objects, personally. They end up scattering things around and hurt discoverability. There are other ways to do modelling that scale very well. There are a few blog posts on it, here's one from someone at Basecamp: https://dev.37signals.com/vanilla-rails-is-plenty/
This is of course very OO which I'm not a huge fan of. Elixir's Phoenix framework, for example, uses "contexts" which is meant to group all related functionality. In short they could be considered a "facade."
In any event, if you like services you like services, they can work, but saying MVC isn't enough for production-grade is a bit misguided.
I do agree that model callbacks for doing heavy lifting business processes is not great, though for little things like massaging data into the correct shape is pretty nice.
Rocket, Actix, Axum, Salvo, etc just to name a few. Each with different focuses (e.g. performance vs "batteries-included-ness")
[0] https://www.techempower.com/benchmarks/#hw=ph&test=composite...
The frameworks you listed are not a direct comparison to this lib, nor Rails, nor Django. They are Flask analogs. They are ideal for microservices, but are not a substitute for a batteries-included framework of the sort used in websites.
I love rust, but don't use it for web backends because there is nothing on Django's level.
As for templates, writing your own language is almost a right of passage into 30s+ nerd club. I never read the dragon book, but I always wanted to take that class in school. There will always be different implementations of the same thing, and writing this one that mimics very closely what ERB (Rails) does felt right.
Most of SSR I see is still SPA + Rest API/GraphQL backend with some scraper generating all the HTML.
Writing a stable WSGI server is possible, and not very hard with a bit of attention to detail, e.g. thread counts, vacuum (just like good old php-fpm, restart every n requests...), etc. Basically if you implement most options uwsgi has, you're on the right path. It's on the roadmap to make Rwf comparable to running Gunicorn.
less rails is... leptos, and a few others
I am curious where this comes from, because my thinking is the absolutely opposite. As much business logic as possible should belong in the model. Services should almost all be specific more complex pieces of code that are triggered from the model. Skinny controller, Fat Model, is the logic of code organization that I find makes code the easiest to debug, organize, and discover. Heavy service use end up with a lot of spaghetti code in my experience.
The other part is that from a pure OOP pov, the model is the base object of what defines the entity. Your "User" should know everything about itself, and should communicate with other entities via messages.
> Don't allow "callbacks" (what AR calls them) ie hooks like afterCreate in the data model. I know you don't have these yet in your ORM, but in case those are on the roadmap, my opinion is that they should not be.
This I agree with. Callbacks cause a lot of weird side effects that makes code really hard to debug.
my suggestions:
- async-trait should be stabilized now, so you shouldn't need the macro anymore
- Add opentelemetry integration so we get metrics and tracing out of the box
- use jemalloc for linux targets
Good work! Keep it up!
I tried to use standard async traits, but they don't support dynamic dispatch [1] which Rwf uses extensively.
I'll be adding opentelemetry tags to functions (from the `tracing` crate). jemalloc can be added to the binary apps that use Rwf, we don't need to add it as a dep to the lib.
Cheers!
[1] https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-trait...
It's also the oldest/most mature tool out there
The one I've seen he most is stuff like `UserRegistrationService` or the like. These things can end up getting scattered and in general, I would rather just talk to the business object, ie, `User.register` which can delegate to a more complex private object handling it. It's basically "inverting" things. The win here is that things are more discoverable (You can look at the user object and see a list of everything it does) and more importantly draws better boundaries. This way the web layer only has to know about `User` instead of `RegisterUserService` and `DeleteUserService` etc.
Again, services can work and aren't inherently bad, but plain MVC can certainly also work.
In a fully typesafe world, it should be pretty hard to derive from the shema this way.
I think most people agree about skinny controllers but I've definitely seen disagreement on if that gets moved to fat models or service objects.
Re templates: I understand that writing a new template engine can be a very fun task (it is both hard enough not to be boring and easy enough not to feel daunting). I also thought many times of creating my own template engine to fix things that I don't like in the language that I am currently using (mostly jinja2).
But if you intend this project to become an actual production ready solution, I see a lot of good reasons not to reinvent template language:
1. Forcing users to learn yet another template language is an additional entrance barrier
2. Tooling support. Existing languages might already have a good tooling support (coming from Python world: PyCharm supports both Django templates and jinja2 very well) including syntax highlighting, auto-complete, auto-formatting, linting etc. Are you going to create all of it yourself?
3. You mentioned planned migration from Python. How exactly I am supposed to manage templates during the transition period? Do I have to have two copies of each template: one in legacy language and one in your new language? If you had a template language compatible with Django/jinja2 [1] this problem would not arise.
4. Whether we like it or not more and more people are using LLMs for coding. This potentially could solve the issue of migrating templates. I expect LLMs to perform really well on the task of "translating" a template from a <popular template language A> to a <popular template language B>. The problem is that if your template language is brand new, LLMs probably didn't have enough examples in their training sets to "learn" its syntax. So, basically, you are setting up your users for a boring, tedious and error prone task of rewriting each template manually without a proper support from their IDE/editor. Meh.
BTW, Django makes it very easy to bring your own template engine [2].
[0] https://en.wikipedia.org/wiki/Not_invented_here
[1] https://github.com/mitsuhiko/minijinja
[2] https://docs.djangoproject.com/en/5.1/howto/custom-template-...
> I am curious where this comes from, because my thinking is the absolutely opposite. As much business logic as possible should belong in the model.
The opposite of this is what Fowler has called an "Anemic Domain Model"[0] which is ostensibly an anti-pattern. What I've learned from my own experience is that with an anemic domain model, the biggest challenge is that the logic for mutating that object is all over the codebase. So instead of `thing.DoDiscreteThang()`, there could be one or more `service1.DoDiscreteThang(thing)` and `serviceN.DoDiscreteThang(thing)` because the author of `service1` didn't know that `service2` also did the mutation.Domain models are hard to do well and I think the SOA era brought a lot of confusion between data transfer objects, serialized objects, anemic domain models, and domain models.
Other contenders were Loco (but was TOO much like Rails) and Rocket (whose macros only started to bother me after writing more Rust).
Your framework seems to perfectly match my criteria of "batteries-included, but not too prescriptive". Great addition to the ecosystem!
Also Django signals, Symfony events... makes things extensible but also hard to debug indeed.
So definitely a Flask, not a Django. And I want no Flask.
> why anyone would reach for Python for a webapp in 2024
Because it works damn fine, is complete and stable, has a gigantic ecosystem covering virtually every needs in the field and also we know the ins and outs of it.
Of course, less resource consumption is always good, particularly RAM, hence why we're interested in initiatives like RWF or why I keep an eye on the Go ecosystem.
1 & 2. It's not really a new language. It's very similar to ERB, so existing tooling, including syntax highlighting, etc., shouldn't be an issue.
4. LLMs are actually pretty good at "understanding" programming language syntax and replicating it to generate code, so even a new language would work. Besides, there is really nothing new under the sun, so similarities with existing languages would help here.
3. I migrated once from Jinja to Sailfish [1], it wasn't so bad. All template languages are roughly the same: start code tag, some simple code, end code tag, maybe a loop or an if statement, but the vast majority of it is print a variable. It would be nice to bring your templates over during a migration, but they are typically a small portion of your code compared to business logic, so I don't think it'll be a roadblock, if someone wanted to attempt this at all.
Mine has a table spec that can translate into a SQL definition or spit out a nicely formatted HTML form. There’s a separate controller that handles all DB connections / CRUD operations, with before- and after-hooks that can easily cross reference with other tables and constraints if needed.
It all works pretty nicely, although I would still switch to Laravel in an instant if I could.
I pushed hard and was able to get us to the point where stuff runs in PASE with modern languages (like PHP).
It’s not any specific licensing issue, just organizational distrust of anything that isn’t paid for.
I think makes sense when you application grows larger. Domains become more complex and eventually how data is persisted can become quite different from how it is represented in the business domain.
One of the simplest examples is that you could have a Login domain model that handles login-related business logic, that mutates properties in the User ORM model.
All your login-related business logic code goes in the Login model, and any "the data _must_ look like this or be transformed like that" logic can go in the ORM model. If some other service wants to do anything related to the login process, it should be calling into the Login domain model, not accessing the User ORM model directly.
This avoids depending on a complex framework that may or may not exist in a few years, improves security by minimizing the amount of 3rd party dependencies, keeps the learning curve low for any new developers joining the project, and is more flexible and easier to maintain. I don't have experience with Rust, and judging by the comments here, web frameworks might still be useful for it. Which is a shame, since the batteries included stdlib approach is far superior IME.
Anyway, I don't want to shoot down your efforts. Congrats on the launch and good luck!
Taken to the extreme, you could model all intrinsic constraints and triggers at the relational database level, and have a perfectly functional anemic domain model.
So when we needed a wiki (before confluence was bought and we only had file shares) I put dokuwiki on a server that already had apache and PHP from years prior. When we wanted to build internal web guis for automation and jobs, we used Bottle.py, since it can run a web server and operate without installation - just copy and paste the library.
Tldr bureaucracy leads to shadow IT.
You can write your own or you can use someone else's. Those are the two choices.
That doesn't mean you need an entire system to represent every table as an object-like thing (which is what I assume when people say ORM). It's actually possible to just emit queries to read and write the exact data that's required in the shape that makes sense for the caller.
I do agree that personally I don't like using big frameworks. My personal favourite is the express architecture: a thin substrate that allows for middleware plugins to be installed and not much else beyond that.
* it's own project because maintaining it will take up so much of your time.
* be decoupled from the web framework because users will want to use another because your own doesn't have abc feature.
From observing the ecosystems in .NET, Java and PHP, lots of people have lots of opinions on how ORMs should work.
I've also come to really appreciate a good standard library. I used to POC things in node because it's so simple, but the dependency tree is hard to justify.
I do like Rust's stdlib too, but its a different tool for a different project. My issue with Rust is the refactor cost when it needs to change.
Mine doesn't, so I don't need an ORM. Plus, I think that when people say ORM, they mean more than just a map from the relational model to the object model and back. They refer to things like hibernate and SQLAlchemy and all the extra stuff that comes with that, like the active record antipattern, and a query builder which successfully encapsulates all trivial queries (which don't need encapsulation) but then as soon as you need to do anything even remotely complicated, the abstraction leaks. I'll be honest, not a fan of ORMs.
Otherwise you have two models, the model in your web framework and the model in your DBMS.
I would take this a step further and suggest that the term "model" is unhelpful and should be eliminated and replaced with the term "table" which is much more grounding.
Even the most basic text editor and pretty much every language support interactive debugging - but if you set up a bunch of docker containers in a very careless way, you end up introducing a layer that disrupts that integration. It's fixable, but for that you need to think _a bit_ about it, and most devs I meet these days are like "eh, why do an interactive debugger, print statements exist" (and then be like "oh no signals are hard to debug :(").
Like, try to build dynamic nested ands with ors using jsonb with gorm. Maybe there are two people on this planet who would like “aha, I know”. Just use your standard sql strings with prepared statements.
The System.Drawing namespace at least as of .NET Framework 4.5 required virtually all of its operations to be done through a System.Drawing.Bitmap, which meant that no matter how your image data was represented, it needed to get rasterized. This wasn't a big deal for most desktop/local use cases, but it's very inefficient, so if you had any servers relying on this, and had a reasonably decent amount of traffic to those servers, you could be getting CPU usages way too high.
As an example, I remember one time we were hosting 30 kb TIFF images (high res, 1 bit per pixel) for download, and generating the thumbnails was done in real time, which caused literally gigabytes in memory churn per request due to the rasterizations... IIRC I fixed it by using emscripten (this was 2015-2016) to do resizing and rendering in the frontend with a small C module using LibTIFF, then the server only needed to send the 30 kb files as is. Unfortunately I've had a hard time finding people to work with these days that give me that kind of room to execute.
Does Go's standard library have these rough edges or is it actually pain-free? I'm on the fence about whether I should learn Go or Rust while I am on a short employment break.
When you have an insufficient stdlib, you often get compatibility issues, where things don’t compose. So you get these kind of pseudo-std mega frameworks like Tokio instead. It was a while ago I was deep in JS but I remember similar things there.
And db updates are either relations or tuples (and a tuple is a relation with cardinality of 1, so...)
Having to explicitly handle every type of error immediately without any support for deferring, encapsulating, chaining, manipulating, transforming etc is antiquated and tiresome.
Rust has Option and Result types and all of the niceties along with it.
I've been using Go recently, and while I'm not convinced on an active-record style ORM in Go (I don't think the language is dynamic enough, and I'm not the biggest fan of codegen), I've been loading the row data from Postgres into a Result struct (pretty much a 1:1 mapping of the Postgres result set into the struct), and then using another function to load the Result struct into struct with their relationships attached (using tags on the structs to define the relationships between them). This has worked great using reflections & generics.
As for this question, > I'm on the fence about whether I should learn Go or Rust while I am on a short employment break.
What are you learning the new language for? If for fun, then this question is longer. If for employment, I would bet that there are more devops, devops adjacent and "systems developer" roles in the Go language.
Congratulations, you've invented an ORM.
Not sure who to believe. :-D
But then it's nice to have something that generates optimised, database-specific SQL, can handle date/number conversion, supports many-many relationships, converting BLOB to binary streams etc.
I will say that I do prefer Gorm only to be used to scan the table -> model, I'd still rather write the sql by hand but I also don't want to scan the rows every time. But other than that I really cannot think of what it's missing.
> Written using the classic MVC pattern (model-view-controller)
well, the "classic web" version I assume. I've never seen a web context in which the original MVC model was used.
var cursor int64 = 0
for {
rows, cursor, err := db.PaginatedRows(cursor)
...
}
Rust has all those nice things and yet you still need to import two of the most popular error lib to work decently.
Every language need to deserialize results into some object so by definition every language that deal with a DB do some form of ORM. So ORM is meaningless in that context.
Also, if you're open to suggestions, use SemVar, and have releases on GH so we get email notifications.
Ryde: A Rust Web Framework - https://github.com/swlkr/ryde (October 2024, 5 comments)
In my experience with fat models is that it works for trivial cases. Once you get more complex business rules that span multiple models, the question becomes which model should it be implemented on. For example in a e-commerce app you might need to evaluate User, Product, DiscountCode and InventoryRow tables as part of a single logical business case to determine the final price. At that point it doesn’t make much sense to implement it on a model since it’s not inherent to any of them, but a PriceCalculator service makes sense.
But yeah, when you're building some kind of internal service with a classless CSS library that's just meant to provide some kind of dashboard to illustrate the state of your service, Go's stdlib is more than good enough and helps keep down long-term maintenance, everything will Just Keep Working.
I struggle to see where Rust fits in for web frameworks. You get the dependency tree explosion, the long compile times, difficulty collaborating with Frontend/UX. The benefit is, what, better performance? Is it really worth it?
This might have been a long time ago but I can't think of much that you cant do. I've seen this behavior though on some project, but it was usually not about the stdlib's deficiencies but more so the developers lack of understanding what they're supposed to do and so revert to another lib.
Go is a perfect language when dealing with files or network. Once you add database layer, calling external APIs, then you face the same latency of other languages due to 3rd party integration.
However, after +20 years of development, I've came to the conclusion that encapsulation is a burden, not a feature and data should be separated from actions that are being performed on that data. It's called data oriented design or data oriented programming, and I am far from the only one that came to the same conclusion.
Just use immutable data structures and be done with it. In departing from old OOP views and becoming more functional programming and data oriented programming friendly, C# introduced Records, which are immutable. Probably Java and Python have similar constructs. Javascript allowed the use of immutable data since long time ago.
If you insist of using fat models, you will still mutate the data all over the place by doing calls, but you just obfuscate it.
Business logic should sit in a business layer.
I would rather implement the Repository pattern and leave the poor model as a plain data structure.
All this encapsulation for sake of encapsulation, and interfaces everywhere even for implementations that the application is married to. I once heard a wise man say: most of these design pattern only add code! And we should be weary of adding code that does not add features. Sure in some cases it makes the code easier to understand/read/refactor. But in many cases it becomes a holy goal with very little actual benefits. Clean architecture being the epitome of this.
> data should be separated from actions that are being performed on that data
This view is shared by nearly all dev that prefer functional programming. I also consider this true. FP-langs help you to "keep 'm separated", and OOP-langs historically make this very hard.
If you build an app on top of a db, you biz logic will get intertwined in the queries and the some of the code that's close to those queries (i.e. model code). That code represents you business logic. Trying to write the biz logic separate from the db is --to me-- just a way to make your project go over budget and hurt your performance.
But great work overall!
How is that so? Can't you add a service layer and call a service from a controller? I don't know about Ruby but for .NET and most Java frameworks this is possible.
To take an example from .NET frameworks, which I am mostly familiar with, you use WebAPI for web applications and MVC for websites. An API just returns data in JSON or whatever form and MVC returns HTML + javascript + whatever media and files.
A controller receives the HTTP request, does some logic, make DB requests, receives models and uses that logic to update a view and serves that view as an HTML file.
Controller - does actions and uses logic
View - describes how the page looks
Model - contains data
Nothing stops the controller to call a service layer which will call a data layer instead of just calling directly the DB.
We have one model file per db table (a "repository") in which we define all queries that "logically belong to that table" (sure they do joins and/or sub-queries that involve other tables, but they still "logically belong to a specific table").
Once we need logic that combines queries from several "repositories", we put that in a "service" file that's named after what it does (e.g. PriceCalculator).
Most of our business logic is in the models (repositories and services), other encapsulated in the SQL queries. Repositories never call services. Model code never calls controller code. Pretty happy with it.
I don't think is just the langs, but mostly the old culture around those. I do .NET development using a data oriented approach and nobody calls me an incompetent developer. I also teach junior colleagues to be vary of OOP-ness for the sake of OOP-ness and overusing patterns.
I am not aware of any OOP language that demands inheritance, encapsulation or method overriding. It's the people who do.
>If you build an app on top of a db, you biz logic will get intertwined in the queries and the some of the code that's close to those queries (i.e. model code). That code represents you business logic. Trying to write the biz logic separate from the db is --to me-- just a way to make your project go over budget and hurt your performance.
I tend to separate, when possible, business logic from DB logic and from other kind of input like calling into external APIs. But I do that trough layers. I put a repository over the DB and its job is to just fetch data from DB and deliver it as data structures. I use that repository in a business layer.
Also Entities are usually mutable.
What clean architecture prescribes here VERY bad for performance. Some of your business logic will dictate how you write your queries if you care for performance.
Me too, but, as I understand, this is a MVC framework that is returning HTML, not a framework to build web APIs.
I agree there is no "a model", it should be "a record" or "a DTO" or "a repository" (which contains the queries to a particular table), or "a service" (that contains logic that calls several repositories).
The idea of having "a model" it closely coupled with the us of ORMs (which are an anti-pattern IMHO). They provide "models" or "entities" that try to be too much (wrap over a db record, contain logic, can back a form submission -- breaking the single responsibility principle on all counts).
I feel like "clean architecture" is trying to fix this, but only makes it worse.
And it's not the weirdness that discouraged me, is the slowness of accomplishing one task comparing with languages like C#, Java or Python.
And since I mostly do web development these days, ease of use and productivity is paramount for me. True, with Rust there might be a bit more throughput and speed, but judging from latest web frameworks benchmarks both C# and Java tend to do very well in this regard.
Please, don't read this as a critique of Rust, or me trying to take away such a great accomplishment such as writing a MVC framework from scratch, but more of a "proper tool for the proper job" type of post.
Odin[1] is a better alternative in the niche modern language space, and also shares many design choices with Go. It has operators like `or_return` and union types like `Maybe(T)`, which can in practice be used for improved error handling.
Though I honestly don't find Go lacking in this sense. The syntax is a bit verbose, but it forces you to think about how to handle every error, which is a good thing. There are far more important design topics worth discussing than this. Go usually makes more correct trade-offs where they matter compared to other languages, and most of the criticism it receives is unwarranted IMO.
But I'd agree the issue is real, and we're discussing mitigation of it, and whether it's sufficient. It's definitely possible to turn your code into aspect-oriented programming hell with careless use of signals, hooks and the likes.
Looks like it also supports some kind of models for JSON validation [0], it shouldn't be too hard to generate Swagger from them, just like FastAPI generates Swagger from Pydantic models.
Also, it is typically assumed that 5xx return codes are retryable while 4xx are not. So, I don't think that not implemented method should return 5xx, because it is pointless to retry it.
[0] https://github.com/levkk/rwf/tree/main/examples/rest#restcon...
For instance, if you are updating a ShoppingCart model, all of that code which creates/updates/deletes a ShoppingCart could be kept in the ShoppingService - which will also create/update/delete the ShoppingCartItem models which are the line items for each item in the carts. So you don't have one Service class per table - but rather one service class per module of functionality.
Not only it is important for fast iteration, but it also contributes to the fun, waiting for compiler to finish is not fun
To me there shouldn't be any new language made without hotreload and incremental compilation
It's 2024, with the HW we have, we shouldn't have to wait more than 1 second to compile code
Fun fact, my game written in D (30k LOC), fully recompiles in 0.4 seconds (Intel i3 10400f), if i can do it, you can too
I'm out of touch.. why not?
Personally my take is business logic should be in the services and object specific validation in the like can be in the model. Unless your business logic is meant to deal entirely with single object types at a time you can hardly fit it in the pure OOP dogma. A behavior that deals with ModelA and ModelB seems just at home on serviceAB as it does on either model, from an OOP sense.
Re: callbacks. They are very nice, when you have CRUD endpoints that modify models directly from JavaScript [1]. It ends up being pretty DRY, especially since you'll find yourself modifying the same model from different places in the code, and without callbacks, you'll have bad data.
Re: service layer. It's a matter of taste, and you can probably avoid it until you're way in the thousands of LOCs. Rails and Django are all about building quickly - that's an advantage you shouldn't give away to your competitors. Service layer is a drag that you may need as an "enterprise".
Re: MVC not production-ready, we know that's not true, but appreciate the hot take, always a good starting point for a great discussion.
Re: existing ORMs, they were not flexible enough. I used ActiveRecord and Django as my inspiration; those are both excellent ORMs, while existing Rust ORMs lean too heavily on type safety in Rust in my opinion. The database should be the source of truth for data types, and the framework should allow for intentional drift.
Hope you get to try Rust soon. I've been using it for years, and I don't want to go back to Python or Ruby, hence this project.
Cheers!
[1] https://levkk.github.io/rwf/controllers/REST/model-controlle...
In Python, the closest you can get is a "frozen" dataclass, but you don't get true immutability[0]. What you _do_ get is effective enough for just about all practical use cases, except for the standard foot guns around mutable data structures.
@dataclass(frozen=True)
class MyModel:
...
[0]: https://docs.python.org/3/library/dataclasses.html#frozen-in...Source: Wrote an ORM that other people actually use. Still adding features, twelve years later.
I mean, kudos for sticking to it over the years in spite of the mountain of criticism, but I personally confirmed a few months ago that it's indeed half-baked. :) Certain features work sometimes, but often fail in cryptic ways. The documentation is a mixture of missing, outdated, wrong or aspirational. I've forgotten the specifics, but I remember being frustrated by it relatively quickly, and abandoning it altogether in less than a week. Good luck with it anyway!
Pedantically, that's not true - it can be unimplemented at T0 and then a deploy happens and it will be implemented at T1. You are likely thinking of retries within the milliseconds timeframe, but even that could be true in a race-condition-esque situation where a redeploy was happening and the request just got unlucky
In the context of this thread, not allowed is quite different from "happens to not be present." I think of the distinction like 404 versus 410 Gone <https://http.cat/status/410> in a temporal state
We do have repositories. And when joining it could belong to both tables, and thus to both repositories. In those cases the devs picks one: the one that it most prominent to him.
But in Java all functions must be part of a class. All I want to say it that in OOP-langs it is possible but takes a lot more discipline. Where in FP-langs there's lots of guard rails and help in making sure you separate logic from data.
> I tend to separate, when possible, business logic from DB logic and from other kind of input like calling into external APIs. But I do that trough layers. I put a repository over the DB and its job is to just fetch data from DB and deliver it as data structures. I use that repository in a business layer.
I find a lot of biz logic ends up in our db queries in order to make things fast. Running the biz logic in the db yield big perf improvements. I cannot see how to do that in a layered approach.
This is very possible.
Anyone taking a serious look at Odin or C3 (strangely morphed from C2 into being more Jai-like or Odin-like), will know they are both no where near to being production ready or 1.0 (many years far away), despite both being old. Odin has less of a following, less contributors, minimal documentation, no books on Amazon, and many of its good ideals were admittedly "borrowed" straight from Jai. Many consider Odin a Jai-clone, where it would be better to wait on the "real McCoy", which would be Jon Blow's releasing of Jai to the general public. Jai fans[1] are about as hardcore as it gets. When Jai is finally released, nearly everybody will forget about Odin or C3 (even tsoding suggested dropping it for a public release of Jai), and very few people even know about them as it is. Just about whatever Odin (or C3) wanted or aims to do, Jai does.
[1]: https://jamesoswald.dev/posts/jai-1/ (Simplicity, Jai, and Joy)
An ORM library maps an entire relational database to a graph of objects, with the intention of abstracting away the relational database. Copying query results to structs doesn't actually do any of that.
https://en.m.wikipedia.org/wiki/Object%E2%80%93relational_ma...
If copying query results to a list of structs is enough to qualify as an ORM, then the term is so generic as to be entirely useless.