potygen
cornucopia
potygen | cornucopia | |
---|---|---|
3 | 20 | |
86 | 704 | |
- | 10.8% | |
2.8 | 4.2 | |
6 months ago | 11 days ago | |
TypeScript | Rust | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
potygen
-
Monodraw
OMG this is one of my favorite tools paid for it all the way back when it went out. Have used it so many times just to write documentation for things like:
https://github.com/ivank/potygen/blob/main/packages/potygen/...
ASCII is just so versatile and allows you to put nice graphics in places where one does not expect, making things more easily understandable.
-
Pql, a pipelined query language that compiles to SQL (written in Go)
I also wrote a parser (in typescript) for postgres (https://github.com/ivank/potygen), and it turned out quite the educational experience - Learned _a lot_ about the intricacies of SQL, and how to build parsers in general.
Turned out in webdev there are a lot of instances where you actually want a parser - legacy places where they used to save things in plane text for example, and I started seeing the pattern everywhere.
Where I would have reached for some monstrosity of a regex to solve this, now I just whip out a recursive decent parser and call it a day, takes surprisingly small amount of code! (https://github.com/dmaevsky/rd-parse)
-
Is ORM still an anti-pattern?
I used to agree 100% with this sentiment, as dissatisfaction with available ORMs at the time (early days of doctrine in PHP) drove me to actually write my own. Turned out an amazing exercise in why orms are hard.
Anyway a few years later I was in a position to start things fresh with a new project so thought to myself, great lets try to do things right this time - so went all the way in the other direction - raw sql everywhere, with some great sql analyzer lib (https://github.com/ivank/potygen) that would strictly type and format with prettier all the queries - kinda plugged all the possible disadvantages of raw query usage and was a breeze to work with … for me.
What I learned was that ORMs have other purposes - they kinda force you to think about the data model (even if giving you fewer tools to do so) With the amount of docs and tutorials out there it allows even junior members of the team to feel confident about building the system. I’m pretty used to sql, and thinking in it and its abstractions is easy for me, but its a skill a lot of modern devs have not acquired with all of our document dbs and orms so it was really hard on them to switch from thinking in objects and the few ways orms allows you to link them, to thinking in tables and the vast amounts of operations and dependencies you can build with them. Indexable json fields, views, CTEs, window functions all that on top of the usual relation theory … it was quite a lot to learn.
And the thing is while you can solve a lot of problems with raw sql, orms usually have plugins and extensions that solve common problems, things like soft delete, i18n, logs and audit, etc. Its easy even if its far from simple. With raw sql you have to deal with all that yourself, and while it can be done and done cleanly, still require intuition about performance characteristics that a lot of new devs just don’t possess yet. You need to be an sql expert to solve those in a reasonable manner m, just an average dev could easily string along a few plugins and call it a day. Would it have great performance? Probably not. Would it hold some future pitfalls because they did not understand the underlying sql? Absolutely! But hay it will work, at least for a while. And to be fair they would easily do those mistakes with raw sql as well, but with far few resources to understand why it would fail, because orms fail in predictable ways and there is usually tons of relevant blog posts and such about how to fix it.
It just allows for an better learning curve - learn a bit, build, fail, learn more, fix, repeat. Whereas raw sql requires a big upfront “learn” cost, while still going through the “fail” step more often than not.
Now I’m trying out a fp query builder / ORM - elixir’s ecto with the hopes that it gives me the best of both worlds … time will tell.
cornucopia
-
We built our customer data warehouse all on Postgres
There are multiple queries each separated by ; and on top of each query, there's a comment giving a name to the query (it's more like a header)
I think the only thing that would require specific support in postgres_lsp is using the :parameter_name syntax for prepared statements [1] (in vanilla Postgres would be something like $1 or $2, but in Cornucopia it is named to aid readability). But, if postgres_lsp is forgiging enough to not choke on that, then it seems completely fit for this use case.
[0] https://github.com/cornucopia-rs/cornucopia
[1] https://cornucopia-rs.netlify.app/book/writing_queries/writi...
-
Is ORM still an anti-pattern?
Some examples for anyone else reading:
https://github.com/kyleconroy/sqlc
https://github.com/cornucopia-rs/cornucopia
This is my preferred method of interacting with databases now.
Very flexible.
-
What ORM do you use?
I like Cornucopia. It’s a SQL-first approach, so I don’t have to worry about an ORM generating pathological queries. It’s also basically zero cost compared to directly using rust-postgres and supports both sync and async. I also like that my SQL queries end up separate from my Rust code, so it’s easy to update all the relevant queries when the schema changes.
-
What is the recommended way to implement session authorization?
Also, I moved away from SQLx due to slow compile times and now use https://github.com/cornucopia-rs/cornucopia
-
Oops, You Wrote a Database
While we're on the subject of ORM's I really like the https://github.com/cornucopia-rs/cornucopia way of doing things.
Basically write SQL in a file and code generate a function that runs the SQL for you and puts it into a struct (this one is for rust)
I think there's a library to do the same thing with typescript.
For me, the best way to talk to the database is with SQL and I don't have to learn an ORMs way of doing it.
-
Thoughts about switching from sqlx to tokio_postgres?
You can take a look at https://github.com/cornucopia-rs/cornucopia which is a thin codegen layer on top of tokio-postgres for ease of use.
-
Ormlite: An ORM in Rust for developers that love SQL
I think we have that https://github.com/cornucopia-rs/cornucopia
-
Ask HN: ORM or Native SQL?
The best solution I've ever seen is this Rust library https://github.com/cornucopia-rs/cornucopia
You write plain SQL for you schema (just a schema.sql is enough) and plain SQL functions for your queries. Then it generates Rust types and Rust functions from from that. If you don't use Rust, maybe there's a library like that for your favorite language.
Optionally, pair it with https://github.com/bikeshedder/tusker or https://github.com/blainehansen/postgres_migrator (both are based off https://github.com/djrobstep/migra) to generate migrations by diffing your schema.sql files, and https://github.com/rust-db/refinery to perform those migrations.
Now, if you have simple crud needs, you should probably use https://postgrest.org/en/stable/ and not an ORM. There are packages like https://www.npmjs.com/package/@supabase/postgrest-js (for JS / typescript) and probably for other languages too.
If you insist on an ORM, the best of the bunch is prisma https://www.prisma.io/ - outside of the typescript/javascript ecosystem it has ports for some other languages (with varying degrees of completion), the one I know about is the Rust one https://prisma.brendonovich.dev/introduction
- Anything like sqlc for Rust?
-
What features would you consider missing/nice to haves for backend web development in Rust?
Does Cornucopia satisfy this requirement?
What are some alternatives?
jOOQ - jOOQ is the best way to write SQL in Java
sqlx - 🧰 The Rust SQL Toolkit. An async, pure Rust SQL crate featuring compile-time checked queries without a DSL. Supports PostgreSQL, MySQL, and SQLite.
NORM - NORM - No ORM framework
metrics
SQLpage - SQL-only webapp builder, empowering data analysts to build websites and applications quickly
rbatis - Rust Compile Time ORM robustness,async, pure Rust Dynamic SQL
sqlite-fast - A high performance, low allocation SQLite wrapper targeting .NET Standard 2.0.
diesel_async - Diesel async connection implementation
sqlc - Generate type-safe code from SQL
bb8 - Full-featured async (tokio-based) postgres connection pool (like r2d2)
postgres - Postgres.js - The Fastest full featured PostgreSQL client for Node.js, Deno, Bun and CloudFlare
typed-session-axum - Typed-session as axum middleware