Afaik many of these issues are why the company i worked for ended up giving up on Prisma. We ended up switching to Objection.js.
The biggest issue was the transactions which was a non starter for us. It wasn't very helpful when after explaining our use case and being told "we are doing it wrong" in the GH discussions, and instead were told to write rollback code manually instead of using transactions was a very poor answer.
Have they resolved issues where many third party packages are not available for Deno? Like i don't see things such as MikroORM/Pino/Firebase-Admin on deno.land, and even things like AWS-SDK are out of date.
I am pretty much in the same boat, i cannot afford a house where i live, and probably will never be able to at least within the next couple of years. Unfortunately between the ongoing construction, and the fact our building is slowly renovating most of the units has hurt my productivity.
While people say "oh just move somewhere else outside the city", unfortunately that means i need to now buy/maintain a car on top of everything else. Then commute into the city to be social with my friends group, or to do physical activities.
Neither of those things appeal to me, and since our work is strongly leaning to switching to be fully remote, it is kind of frustrating. A bunch of coworkers are very much just move to a city where you can buy a house! That is what i did. Or even worse a lot of people who are just "buy a house!", and are completely ignorant of how insane the housing prices have become.
Honestly the end result is probably just going to lead to me finding employment at a company that still has the ability to work onsite. A few of my like mininded coworkers pitched the idea that we could rent a small office area for people like us, and were promptly shot down by management.
Does anyone know if they have addressed the major performance problems with typescript?
This was a few months ago, but tslint takes a few seconds on one of our larger code bases. However ESLint with the typescript plugin would take up to a minute+, and seemed to make webstorm struggle with the eslint integration.
Costco is an okay place to work however, As someone who worked for Costco in the past, i think i was getting barely $1.50 more than minimum wage (this was 2015).
Furthermore you have a ton of full time employees who will sing praises about the company. However part timers get shafted hard. Oh you can't work 3 days a week due to school, okay enjoy barely 8 hours a week. There were a lot of people there who had to work multiple jobs simply because they could not get enough hours.
Unless you are fully willing to commit to them it isn't a great place to work.
Unfortunately we do not have these claims defined in our auth token or the datasource hasura is attached to. We have an external session cache service in Redis. If the user isn't cached we need to hit an internal API to attempt to fetch this information for us and return it to us. No user information is stored in our auth token/database.
Actions look painful, i don't want to write and maintain microservices just to do simple actions. I just want to be able to write code and handle the hook around the function. Also from the link it only seems like actions occur AFTER something happens, i need the ability to run before changes are persisted.
I tried Hasura in the past and unfortunately found it unsuitable for our auth requirements. There is no way currently to hook into their authorization system, you get extremely basic RBAC and if that isn't good enough for you too bad.
For example we currently are required to talk to some external auth services (depends on the customer) and fetch the users permissions based on that, (e.g. user can READ notes, and WRITE notes but not delete NOTES). At the time we had an extremely simple express middleware that handled this.
Also the entire idea that i need another GraphQL or rest server to do any sort of custom validation/custom actions made me do a double take and more or less killed any interest to me.
We ended up using NestJS with their GraphQL tooling and objection.js and never looked back. Ironically the adoption of the GraphQL version of our API compared to Rest is almost 0.
The biggest issue was the transactions which was a non starter for us. It wasn't very helpful when after explaining our use case and being told "we are doing it wrong" in the GH discussions, and instead were told to write rollback code manually instead of using transactions was a very poor answer.