Show HN: Amplication – Instantly Generate Node.js Apps with GraphQL and REST API • Hacker News Board

Re: Show HN: Amplication – Instantly Generate Node.js Apps with GraphQL and REST API

#101

Post by thatwasunusual » Wed, Jan 13, 2021, 3:06 PM UTC

qudat wrote: post #91

thatwasunusual wrote: post #80

Earlier quoted context omitted.

Can you describe the problems you've encountered with Prisma? I'm in the process of choosing an ORM myself, and Prisma seems to be the best option of those I've tested.

I’m not a fan of ActiveRecord or ORMs in general. I’d much rather write raw sql queries with a little help to improve reusability. I found Prisma to be super basic. Anything complex like joins or a composition of where’s and ors and it didn’t work. It also nests related objects where for my purposes I wanted everything to be flat. So if a list has a user associated with it, I want to flatten it like: { list, user }.…

I appreciate your reply!

Re: Show HN: Amplication – Instantly Generate Node.js Apps with GraphQL and REST API

#102

Post by VectorLock » Wed, Jan 13, 2021, 10:14 PM UTC

ZephyrBlu wrote: post #89

VectorLock wrote: post #81

Earlier quoted context omitted.

What do you use for developing the 'front end' of your web apps with Django, do you just generate HTML from templates with Jinja, etc?

They said they use Django REST Framework (DRF), so presumably they use a frontend framework and communicate with the backend via API.

Thats what I was wondering what they use.

Re: Show HN: Amplication – Instantly Generate Node.js Apps with GraphQL and REST API

#103

Post by qudat » Wed, Jan 13, 2021, 10:36 PM UTC

matthewmueller wrote: post #99

qudat wrote: post #90

Earlier quoted context omitted.

This is where our preferences probably differ. I’m not a fan of ActiveRecord or ORMs in general. I’d much rather write raw sql queries with a little help to improve reusability. I found Prisma to be super basic. Anything complex like joins or a composition of where’s and ors and it didn’t work. It also nests related objects where for my purposes I wanted everything to be flat. So if a list has a user associated with…

Curious about the date response part. JSON.stringify(payload) turns dates into strings. Did that not work as a response for your API for some reason?

It works fine, but the typescript types that prisma generates says that type is a date, not a string. So I can't directly use that as the API response type, I have to modify the prisma type to get it to work correctly on the FE.

Does that make sense?

Re: Show HN: Amplication – Instantly Generate Node.js Apps with GraphQL and REST API

#104

Post by highmastdon » Thu, Jan 14, 2021, 3:02 PM UTC

yuvalhazaz wrote: post #2

Hello, co-founder here: as a backend developer I've had to develop web APIs for various projects over the years. Before I could spend any time on designing and testing my business logic, I had to invest hours into making sure my boilerplate code was valid and provisioning infrastructure, not to mention setting up my cloud environment. We built Amplication so that developers like us could focus on coding the parts tha…

Minor comment. On the homepage the titles of small paragraphs (like What we do, Why we do it), I can't help but notice that I'm ignoring the part that's in the pill, and reading the text only, getting confused, reading again, and spotting the pill, then realizing it's part of the full sentence.

Could be only me, but if not, maybe change that?

Re: Show HN: Amplication – Instantly Generate Node.js Apps with GraphQL and REST API

#105

Post by yuvalhazaz » Thu, Jan 14, 2021, 4:46 PM UTC

highmastdon wrote: post #104

yuvalhazaz wrote: post #2

Hello, co-founder here: as a backend developer I've had to develop web APIs for various projects over the years. Before I could spend any time on designing and testing my business logic, I had to invest hours into making sure my boilerplate code was valid and provisioning infrastructure, not to mention setting up my cloud environment. We built Amplication so that developers like us could focus on coding the parts tha…

Minor comment. On the homepage the titles of small paragraphs (like What we do, Why we do it), I can't help but notice that I'm ignoring the part that's in the pill, and reading the text only, getting confused, reading again, and spotting the pill, then realizing it's part of the full sentence. Could be only me, but if not, maybe change that?

noted! thanks

Re: Show HN: Amplication – Instantly Generate Node.js Apps with GraphQL and REST API

#106

Post by latchkey » Fri, Jan 15, 2021, 4:28 AM UTC

nikolasburk wrote: post #68

latchkey wrote: post #58

Earlier quoted context omitted.

Please give MikroORM a shot, vastly better than the mentioned. https://github.com/mikro-orm/mikro-orm

What are the points that make you pick MikroORM over Prisma? (I work at Prisma and am always eager to learn about individual preferences of folks when it comes to choosing an ORM.)

Unit of Work.

Re: Show HN: Amplication – Instantly Generate Node.js Apps with GraphQL and REST API

#107

Post by cratermoon » Sat, Jan 16, 2021, 7:09 PM UTC

RedShift1 wrote: post #61

cratermoon wrote: post #46

Autogenerated direct data coupling.

What are you implying?

I appreciate your question and thought it deserved some thought time, in contrast to my initial off-the-cuff comment. I had difficulty putting it into words, but today I was reading another article posted here on HN and it cut to the heart of the problem:

https://macwright.com/2021/01/15/rust.html

"GraphQL basically lets your frontend application define queries, instead of the backend. You give it a range of things it could query, and the application - React or something else - sends arbitrary queries to the backend.

This makes things hard for the backend. Any sort of SQL-level optimization is impossible - your server is writing dynamic SQL, so you rely on the intelligence of your GraphQL server, which is not always high. Juniper, for example: n+1 queries by default. The workaround - a dataloader - is rough and independently maintained. So at the end of the day, you’re going to have a blisteringly-fast application layer that’s spending all of its time inefficiently querying your database."

This is the data coupling problem, allowing the front end to see and arbitrarily query the data model. Yes, you can put a great deal of effort into optimizing the GraphQL server, but then you've just introduced middleware again, and at that point it's hard to see what the GraphQL protocol has over REST.

Re: Show HN: Amplication – Instantly Generate Node.js Apps with GraphQL and REST API

#108

Post by Glyptodon » Sun, Jan 24, 2021, 2:44 AM UTC

qudat wrote: post #90

Glyptodon wrote: post #86

Earlier quoted context omitted.

I'm curious what you don't like about Prisma? I like Active Record + Arel (from Rails) a lot, and have found Knex relatively unpleasant in comparison, offhand Prisma has looked more pleasant/usable to me...

This is where our preferences probably differ. I’m not a fan of ActiveRecord or ORMs in general. I’d much rather write raw sql queries with a little help to improve reusability. I found Prisma to be super basic. Anything complex like joins or a composition of where’s and ors and it didn’t work. It also nests related objects where for my purposes I wanted everything to be flat. So if a list has a user associated with…

Sounds sort of like Active Record without Arel. The things that you're mentioning do sound irritating, not being able to do joins easily, etc., seems lousy. (I think Arel is a bit overlooked, but it's actually very pleasant to build complex/composable queries with it IMO.)

Regarding types, the more I've used JS the more I've come to hate JS's native types for numbers and dates/times, so not terribly shocked by that, kind of think its native types being really obnoxious is part of why typescript is relatively popular.

I am a bit curious - the piece of ORM-style solutions that I like is that they create a clear pattern for organizing certain kinds of application logic - for example, if there's a rule that value X meets certain conditions, usually there are tools or conventions with ORMs to make it not easy to write something that skips the rule without doing so intentionally. Whereas in codebases that don't use some sort of frameworky-ORM-y solution I often find myself thinking there aren't clear patterns of responsibility for such things, leading to bugs or poor DRY practices.