181–190 of 260 posts
Can someone compare to Hasura please? What has been your experience?
Other upsides are a much better RBAC column/row permissions, migrations with up/down, a better admin UI.
I am a noob in these matters which one is advised if one is to start a GraphQL API from the beginning - use DBs that directly provide GraphQL endpoints such as Fauna, Upstash, etc. - use an ORM with more traditional DBs. What are the pros and cons of each?
I prefer having the database as a single source of truth and use something like [Hasura]( https://nhost.io ) to generate the GraphQL API.
I LOVE Prisma. I’ve used Django, SQLAlchemy, Sequelize, Knex, and TypeORM in the past. all had rough edges that continually frustrated me or didn’t provide the functionality i needed. Prisma is different. It’s absolutely got rough edges, but the extremely strong type safety makes Sequelize look like a joke. The query engine itself, written in rust, combines and optimizes queries inside every tick of the event loop so…
To be fair, Sequelize makes itself look like a joke. I normally wouldn't call out an individual library to shit on, because I understand that a lot of work has gone into it. But I used it for years and it was always buggy. Sometimes options wouldn't work correctly because the authors liked to do that clever JavaScript thing where they write `foo = optional_thing || default_value` even for BOOLEAN options. I always ha…
I don't think I've ever called out on a library, or not felt truly thankful that it was there to help me. But Sequelize... man...
When I first got into Node, and got Sequelize, after working for years with .NET, Entity Framework, NHibernate and the likes, it just felt like horrible-everything. I've forced myself to use it in some projects, because node is cheap, and I kept thinking that I'm missing something. Some brilliance behind the questionable... everything. No. I can't even bring myself to think about that design mess. Sorry for the rant, Sequelize makes me feel insecure, and little, in the chaos of the Universe.
Earlier quoted context omitted.
> SQL is an impressive technology and has stood the test of time! Yet, we claim that it's not the best tool for application developers who are paid to implement value-adding features for their organizations. I'm not sure about that. We've recently switched from JavaScript based querying code to mostly raw SQL, and we've reduced our code to about 25% of what it was, and it's much simpler to understand than it was befo…
I think the strongest argument for or against an ORM is that it changes the structure of your code, how you reason about your data. Things like performance, ease of use, reusability, schema generation etc are minor points and not the big issue you need to think about. Personally I feel that an ORM will lead your project in the wrong direction and your database schema will suffer. ORMs will usually mix both reading an…
TypeScript is like a relational database (and other structural statically typed languages) of your application behavior, allowing you to query the current possible states of your data at any given point in your application code.
I’ve been thinking about this more since TypeScript got template-string generics, and folks have experimented with eg type-checking SQL strings back into application code.
This is the piece that draws me to an ORM: that it brings the “relational model” into application code, NOT the “object” part of an ORM.
Does anyone have any opinions about which language ecosystems create the most effective type-mappings between a RDBMS and application language?
Part of me also wonders if there’s a ton of time lost on mapping between languages like this when the tooling that’s really missing (afaik) is better tooling for producing, consuming, and generally interacting with SQL and db schemas as the data runs through your application pipeline.
Earlier quoted context omitted.
> if you're trying to keep things in sync efficiently I think we are all abusing GraphQL in this sense. Caching GraphQL data is a world of hurt. The easiest way to sync is if your data is in the same model as the way it is stored, which is normalized if using SQL. Even when we do normalize most people will represent a 1-M as an array of foreign keys: `posts.comments = [1, 2, 3]` when in the db we use a foreign key on…
Ha :) Yeah, I just replied in a similar vein in the other reply to my original comment. Agreed!
I'd love to get rid of all these client-side state management libraries and just drop an SQL DB in there and allow components to subscribe to changes to queries on record updates, and then sync it to a cloud DB.
One interesting problem I came across is how to know when your local DB has enough records to be able to run a given query. E.g. If your team has 100K tasks in their cloud DB, and you run `SELECT * FROM tasks WHERE tasks.assignee = user.id`, and then another query of `SELECT * FROM tasks WHERE tasks.assignee = user.id AND tasks.completed = true`, the second task is a subset of the first, so it doesn't need to hit the server except to check if any updates were made to the tasks table. Then apply this to all queries including ones with joins. Actually some fun relational algebra can be used figure it out - one of the perks of working with SQL. The problem is actually similar to how to [incrementally maintain a materialized view](https://wiki.postgresql.org/wiki/Incremental_View_Maintenanc...) which Postgres actually does not support (Oracle does).
One of the things that is most perplexing to me is the inability to autogenerate a seed file from existing data, to reseed a new database. This would be incredibly helpful for testing and working with staging data. For example, we have a staging database and staging server, and want to be able to reseed the database with some data set, but don't want to write all the data inserts by hand. I'm sure there are many ways to avoid doing this (db-specific export/import, scripting the inserts in a loop over a collection of arrays of values which you've curated by hand, or in our case just copying the sqlite db file). Still, Prisma's story around seeding and data fixtures in general currently leaves a lot to be desired.
There have also been many rough edges I've run into around shaping results (getting category names which have been applied to all blog posts by a given user, for example), and applying schema changes, but I'm not willing to rule out user error / inexperience for many of these
To use an ORM effectively you must learn both the API of the ORM and SQL. It does not absolve you from learning SQL, which I think was one of the unstated attractions to junior developers. Then you have to map between the API of the ORM and how it translates that to SQL under the hood. Then you have to understand how it handles caching and sessions and how that all works under the hood. This has been the source of so much complexity and so many bugs over the years that I no longer think the benefits are worth the cost. As always, there are exceptions and caveats, but I now believe it's better to use SQL directly than to use an ORM. In general there is too much complexity in all the layers of abstraction in software development these days, and I think the industry is strangely blind to the consequences of this. Complexity is death to software, and it should not be taken on lightly. The entire craft of a software engineer boils down to eliminating complexity and simplifying problems, the better you can do that, the more productive an engineer you will be.[1]
[1] https://github.com/sqljoy/sqljoy/blob/master/docs/pages/orm....
Earlier quoted context omitted.
To be fair, Sequelize makes itself look like a joke. I normally wouldn't call out an individual library to shit on, because I understand that a lot of work has gone into it. But I used it for years and it was always buggy. Sometimes options wouldn't work correctly because the authors liked to do that clever JavaScript thing where they write `foo = optional_thing || default_value` even for BOOLEAN options. I always ha…
> I normally wouldn't call out an individual library to shit on, because I understand that a lot of work has gone into it. I don't think I've ever called out on a library, or not felt truly thankful that it was there to help me. But Sequelize... man... When I first got into Node, and got Sequelize, after working for years with .NET, Entity Framework, NHibernate and the likes, it just felt like horrible-everything. I'…
But I was like you- I picked up Node because we had an existing project in it. It only used libraries that had the most "stars" or whatever on NPM and they were all pretty deficient (and some were shockingly slow). But none were so frustrating as Sequelize.
IMO any discussion about Node/TypeScript data access tools deserves a reference to Zapatos, which sort of is the anti-Prisma. It has all the type safety with none of the ORM (and it's Postgres-specific, for better and worse). I think it's got one of the best designed APIs I've come across. https://jawj.github.io/zapatos/
PgTyped is similar, and it's superior to any other data access layer I've ever used. Ever.