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

I wouldn't question this for a second. Nor that some people may be extremely happy with it. But me personally, for my most common use case (end-to-end monolithic web apps, complete with client and back-end) it feels like it places a higher cognitive burden than the alternatives, due to all the things we're mentioning (eg, lack of an established ORM)

> Comparing Django to NodeJS itself is a bit of an apples to oranges comparison

Well, yea, but that's the point of my whole comment - Node could have a Django or Rails equivalent after ten years, don't you think?

> It seems like the biggest issue with the NodeJS ecosystem is that everyone wants to roll their own thing

Completely agree - it's almost an ethos thing. Though I'm not sure if it's a conscious "ethos" or rather having to due with the ecosystem and developer population being disparate and disjointed - anarchical, maybe?

Again, not questioning that there are some really good devs out there that are deliberate and successful in rolling out their own thing. I also think however there's a group of devs who think that they want to roll their own thing, until they have to face the consequences down the road and wish they hadn't.

> how deceptively easy it is to work with NodeJS

Yes, that's a big point in my comment. To add: I have a formal education in software engineering but like many others had to pick up web dev on my own. I bought into the Node.js "one language to rule them all" hype, only to find a much steeper learning curve than I would have had otherwise (mainly due to the async model and the lack of a batteries-included framework), without much of a payoff for it.

I feel no regrets, my path has been what it's been, I've learned a lot and I'm glad to have Node.js as an option in my toolbelt since it's so prevalent and there are good use cases for it. But if I had to recommend a young dev where to start I'd probably point them elsewhere.

As for me going forward I see myself sticking to Django and exploring things like Elixir/Phoenix, Swift, Go or F#, and only coming back to Node if the situation really calls for it or maybe, like I said previously, if there's a batteries-included framework that reaches maturity.

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 also didn’t like how Prisma has a generate cli to integrate end developer models that must be integrated into your build step to deploy if you’re using typescript.

Its schema cli command worked but in weird ways that I didn’t like. Sharing Prisma types with the client was not automatic. For example, Prisma coverts datetime columns into dates, which sounds nice, but when I send that data as an api response it turns into a string. Now I can’t use their interfaces without plucking the date times and converting it to a string. It just wasn’t as useful as I had hoped.

Knex does exactly what I want and nothing more. All of my raw sql queries were easily converted and worked perfectly. I build the interfaces and knex uses them. There’s no special command that converts their schema format into something I can kind of use.

Their typing was nice once I got it working however, and for simple things it worked fine. I just noticed I had to write a lot of raw sql.

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 also didn’t like how Prisma has a generate cli to integrate end developer models that must be integrated into your build step to deploy if you’re using typescript.

Its schema cli command worked but in weird ways that I didn’t like. Sharing Prisma types with the client was not automatic. For example, Prisma coverts datetime columns into dates, which sounds nice, but when I send that data as an api response it turns into a string. Now I can’t use their interfaces without plucking the date times and converting it to a string. It just wasn’t as useful as I had hoped.

Knex does exactly what I want and nothing more. All of my raw sql queries were easily converted and worked perfectly. I build the interfaces and knex uses them. There’s no special command that converts their schema format into something I can kind of use.

Their typing was nice once I got it working however, and for simple things it worked fine. I just noticed I had to write a lot of raw sql.

A lot of people like it so don’t let me critique shy you away from using it. It probably works best if you are using graphql since it automatically nests the models which I would imagine works well with query resolvers.