Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Amplication – Instantly Generate Node.js Apps with GraphQL and REST API (github.com/amplication)
270 points by yuvalhazaz 4 days ago | hide | past | favorite | 101 comments





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 that really matter, rather than get distracted by undifferentiated heavy lifting. Amplication is an open-source tool that lets you design your data schema and in return it generates for you a human-readable and editable TypeScript Node.js codebase. This server codebase includes a GraphQL API, REST API, authorization, authentication, admin UI, users management, logging utility, error handler, and much more right out of the box.

we generate your server code dynamically based on changes in your schema. You can download the generated code or continuously push it to a GitHub repository to continue off and edit it further on your own.

For your convenience, we use a web UI to manage this whole operation and it is available for the community as a managed service on https://app.amplication.com, or you can run your own Amplication server. I’ll be more than happy to answer any questions you may have and get your feedback.


This looks good - seems to be hammered currently?

https://app.amplication.com/ckjuaxw2518112510s6qfb0xi8q shows {"statusCode":500,"message":"Internal server error"} for code download, and has been waiting for a sandbox environment for a while.

But I'll be back to try it again in a few days :)


I really love this, years ago I made a similar tool that generated a CRUD app from a DB schema with an admin UI, auth, etc.

How do you solve merging the modified codebase with a freshly generated ones? Let's say I need to add a new field. Do you rely on GIT for this?

Also, the readme could use a link to a sample hello world repo that this Amplication generates.


Love your feedback! Thanks. We plan to have a set of policies to allow the developer to freely work within those policies so we can merge the code back to Amplication and even deploy the app with the custom code. There is a still way to go to get there...

Meanwhile, we let the developer manage the merges in GitHub

When you sign in to app.amplication.com you get a simple sample app with your account


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

I literally started asking around on the web for exactly this today.

Seriously taking a look, this looks promising. We built an app on AppSync and Cognito and I want to get off AWS so I'm looking for alternatives, and this... fits the bill.


Glad to hear that! If You need support of any kind, join our discord channel and we will love to help

https://discord.gg/b8MrjU6


@yuval : Congrats on launch. Happy to come across it. We need more people tackling this problem. UI looks cool :)

At XgeneCloud[1], we are after the same problem.

XgeneCloud provides a desktop app that can connect to any new/existing databases to instantly generate REST & GraphQL APIs.

(Supports MySQL, Postgres, SQL server & SQLite)

Happy to share notes on discord.

[1] : https://github.com/xgenecloud/xgenecloud


I'm curious - is there a tool handles solely the "frontend codebase generation" part of this? This looks great, but we already have a well-defined backend and REST API built using Python+FastAPI, with SQLAlchemy as an ORM and Postgres backing it. I am not a good UI/UX designer, but I understand and have built React applications, so really find myself looking for something that can take an OpenAPI.json spec and produce a hackable frontend codebase that follows best practices.

React-admin[0]? Doesn't read openapi from what I could gather but solves similar problems in a best-practicey kind of way.

[0] https://marmelab.com/react-admin/Readme.html


I had seen this a while ago but should take a fresh look at it - it seems like there should be a community tool that generates data providers from an openapi spec. Thanks!

Are you using SQLAlchemy in a blocking way w/ FastAPI?

I believe so - basically following the vanilla SQLAlchemy integration guide they have [0], and not trying to await query results as they do in the the async guide [1]

[0] https://fastapi.tiangolo.com/tutorial/sql-databases/ [1] https://fastapi.tiangolo.com/advanced/async-sql-databases/


Built on top of immature overhyped tech (nestjs, prisma, etc...) with lots of issues. Something very common in the JS/NPM that always gives you headaches down the road. There's an arms race to sell hosting through immature buggy magical frameworks in the JS world, so this is to be expected.

I'll take the one/two days to set up node, express, postgres with libs for now. What takes up the majority of the time is domain modeling anyway.


I've been developing web apps in Node for a couple years and I'm done with it - I'm all in on Django + DRF now.

I only made the switch a couple months ago and it's amazing how cozy I am with it: everything feels mature, stable and reliable. I reach out for 3rd party packages as needed but it doesn't feel like I'm gluing a Frankenstein together, or that I'm rolling out a bunch of code I don't want to own, or that I'm overthinking for the umpteenth time how I should structure my app. I think after a couple months with Django I'm nearly as productive as I ever was Node.js. Granted that many web dev concepts just carry over, but the feeling is uncanny regardless.

Also, the "language context switch penalty" is a complete myth. I picked up Django by reading two books in 2-3 days, and didn't need to even bother front-loading Python - I just picked it up as I went. I now switch between Python and JS/React seamlessly; I enjoy writing both and I really like the variety (though as dynamic, duck-typed languages maybe they're not that dissimilar). Every thousand characters I type in Python I'll make a silly mistake where I write some JS syntax and that's it - hardly what I'd a call a cognitive penalty.

As it stands, I'd only develop something in Node.js if I really needed its performance characteristics (and then, I may be able to get close to them with Python's asyncio - though I haven't researched this avenue yet so there may be pitfalls I'm not aware of).

All in all, I find it baffling that in over a decade of existence Node.js hasn't produced a web framework that even comes close to Django or Rails.

I do wish OP, Nest, Prisma and all the devs in the Node ecosystem the best of luck nevertheless. I love JavaScript and if someone produces a web framework that really emphasizes developer productivity and happiness I would consider coming back in the future.


NestJS is pretty close to the best web framework I’ve found for node.

Now if only it came with all batteries included, and the DI wouldn’t be so funky, it would be even better, but it’s still lightyears ahead of express for building a comolicated application.


I've never been unhappy in any web framework in any language except for Plone. The NodeJS ecosystem is not without its problems, but you can absolutely write great software in it.

Comparing Django to NodeJS itself is a bit of an apples to oranges comparison though. Even something like Express or Koa will come without an ORM. Django will certainly hold your hand a lot more through the process.

It seems like the biggest issue with the NodeJS ecosystem is that everyone wants to roll their own thing, rather than using the renowned incumbent which works perfectly well. In some ways, this is actually an indication of how deceptively easy it is to work with NodeJS — people really believe they can replace something that has hundreds of years of man hours behind it in a month.


I must second this. I've always viewed frameworks as a joy to my work, as long as there is no magic involved. I develop quite a few mini apps and I find less opinionated frameworks like Express for Node or Flask for Python an absolute dream. The packages on Node can get unwieldy but nothing bad enough to warrant a long term negative outlook.

> you can absolutely write great software in it

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.


> 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's not that such a thing hasn't been developed, but that by the time such a thing gets developed (for example: [0]), NodeJS devs have already decided they don't like gulp (even though just last week gulp was the new thing vs. grunt), they like webpack; they don't like AngularJS, they like React (or VueJS now); etc.

Almost feels like the JS ecosystem is plagued by people who want to rise to dev stardom by making the next big framework, and they spend a LOT of time trying to convince people their thing is the next best thing since sliced bread. I've seen grown up devs abandon stacks that were perfectly fine to spend years migrating to the new thing — granted this happens more at larger companies where resume building sometimes overtakes business needs.

[0]: https://github.com/angular-fullstack/generator-angular-fulls...


Five years ago I might have agreed with you. I think it's pretty telling though that the techs you just listed have now been around for longer than Angular or Gulp were ever popular (at least according to my recollection). Seems to me that the churn has slowed significantly; people are generally happier with React and Webpack than their predecessors.

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.

I'm inclined to agree. This is nothing against the OP but I never reach for boilerplate generators, even ones like `create-react-app`.

Here's a great example of why: I do a bunch of research before I started my project (https://listifi.app - for anyone curious) and decided to go with prisma.js. It looked like it was exactly what I wanted for a REST API built with koa.

I've dumped probably a month fulltime on the project and now that I have enough experience using prisma, I realized it really doesn't do what I want it to do and is actually making my life more difficult as a result.

So now I'm in the process of switching from prisma to knex. Having the glue hidden from me would really affect my willingness to switch technologies and increase my frustrations with any platform.

For any reasonably complex application, you will eventually need to eject.

I want to see how everything is pieced together. Even these js builders like parcel that "do everything for you" eventually don't work.

I'll take a couple of days to set things up the way I want them to over something that tries to do it all for me while only accommodating the happy path.

Again I want to say that this is my personal preference when building any project. I pick a few barebones libraries to help me build what I want and get out of my way.

That should be obvious when you look at my tech stack: https://listifi.app/u/erock/listifi-tech-stack


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 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.


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?


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 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.


I appreciate your reply!

Every time I look at one of these I get anxieties...

At first because they look so easy, clean and productive (just 5min!), but then because I try to get specific answers, like: what drives the schema? Can I use websockets with this? What problems does it solve that others don't? Why does a simple CRUD application need GraphQL integration? Why are there emojis everywhere? Why does it feel like their intentions are unclear?

Then I close the tab and leave with an empty feeling.


dgb23, I will do my best to answer all your questions... I hope the experience this time will be better than the previous ones:

what drives the schema? We provide you with an intuitive UI to create the schema. Later down the road, we plan to add a CLI for easier integration with scripts and other tools.

Can I use websockets with this? Since we provide you with a generated Node.js source code you can build on top of it with whatever you want and expand your application with any missing capabilities. Websocket is also on our list, but to be honest the list is long. We are looking forward to getting more contributors to be able to expedite the releases.

What problems does it solve that others don't? We are focusing on saving time for Node.js developers and provide them with a set of tools for all the repetitive tasks they usually face.

Why does a simple CRUD application need GraphQL integration? We initially generate the app with CRUD operations (both with REST and GraphQL). The idea is that developers will keep adding on top of that all the more complex APIs and operations relevant to their business domain - Currently with code, and soon with more tools to expedite some of the boilerplate.

Why are there emojis everywhere? We love emojis, more precisely we love beautiful UI. Once the CLI is out you will be able to avoid the emojis :-)

Why does it feel like their intentions are unclear? I would love to provide details on every question you may have about our intentions. Generally speaking, we hope in the future to create a sustainable business around the open-source project, while keeping the service free for 99% of the users. The project is open-source so anyone can host a server locally and get all the benefits of Amplication with no string attached.


Looking forward we have a strong belief in both NestJS and Prisma. They are great technologies on there way up (and in many ways, they are already there)

This does nothing to address the OPs concerns. You might as well have just said "Don't worry about it!"

For anyone who's interested, Iddan from the founding team recently gave a demo of Amplication on our "What's new in Prisma" livestream. You can watch it here: https://youtu.be/wQo_Ii_IjXA?t=4279

Really love the work they're doing, definitely check them out!


How does this compare to https://redwoodjs.com/ ?

redwoodjs aims to provide a framework for a serverless architecture with jamstack - It looks amazing. Amplication aims to provide an easier and continuous development experience with Node.js, to allow node.JS developers to focus on their business domain instead of design and boilerplate. Amplication generates a human-readable source code to allow the developers the freedom to choose how to use their apps and how to deploy it - Whether because of business policies and architecture, privacy and security concerns, or just personal preferences.

I had began creating my own sort of thing on top of Hasura which I prefer but this is pretty cool. I'm not at all too big on TS (which is sacrelige apparently) but I'll check this out.

We already got some feedback from developers who used the generated code to learn Node.js :-) maybe it is your chance to jump into TS

> I'm not at all too big on TS (which is sacrelige apparently)

All of JS with an :any appended to it ;)


Interesting idea but I looked at the sample app and the amount of code it generates looks excessive for the features it provides. Thinking about the effort to maintain and extend this code I am not sure if it would be a good starting point for MVP projects.

That's what I thought when I tried JHipster, setting up a Spring Backend with a Generic CRUD Controller and Generic Services, takes 1-2 hours and is much cleaner.

The demo video is really great - I would make it more prominent: https://www.youtube.com/watch?v=tKGeLXoPr94&feature=youtu.be

Really comprehensive product!


thanks!

I was just searching for a tool exactly like this a few days ago. Looks really great!

Great! Please share your feedback once you've tried it!

This really closely mirrors my preferred stack, so I'll definitely be taking a close look at this for my next project.

One pipedream I've had with TS backed APIs is sharing the types between the backend and the frontend to prevent duplication. I didn't see anything in the API consumption docs, but is there anything here that tries to accomplish that deduplication?


We are using this exact technique on the Amplication server where we automatically generate the models for the clients from the graphQL schema on the server. When you build your app with Amplicaiton you anyway get a generated code including the models both for the client and the server so you get exactly this OOB.

This looks very neat.

Why do you require a GitHub account to test it?

---

Edit: and after I logged in with my GitHub credetials, I was directed to https://app.amplication.com/github/callback?code=968[...] which just showed me a 500 error. Hug of Death?


I'm not the OP. FWIW, I have checked their video https://www.youtube.com/watch?v=tKGeLXoPr94

Sorry to hear that. We will make sure to check the logs. As for the login, we ask for a GitHub sign since we thought it would be most convenient and cost affective at this stage since all users are developers. Also, we use it to send the generated code to your GitHub repo.

Can you just make some page that doesn't save anything so we can see what you mean by "visual"? Or embed a youtube preview?


Wanted to test too...

I'm getting " Error: Error in connector: Error querying the database: db error: FATAL: remaining connection slots are reserved for non-replication superuser connections " when deploying.


SamBam if you need any support please jump to our discord channel and we will do out best to help

https://discord.gg/b8MrjU6

Thanks


same 500 error for me

Very excited to see this project hitting the top page. Had the time of my life contributing to it


This looks like it creates very tight coupling between the API and the implementation. This is probably great for prototyping, but probably not a good path for building robust long lived services.

Big fan of frameworks like this. AdonisJS is similar in this space: https://preview.adonisjs.com/

Looks interesting. I've used similar setup but with Hasura. My current project needs to interface with a 3rd party REST API on top of Postgres. I was able to replaced many of the CRUD REST API with Postgraphile. To bring it all under one GraphQL endpoint I used Apollo Federation. When I have time I'll have to see how Amplication federate the various data sources.

Playing around in app.amplication.com I'm seeing a lot of similarities to supabase. Happy to see more competition in this space.

My initial impression is I'm a bit confused as to whether the goal is a hosted service similar to supabase, firebase, etc, or an offline tool that generates the app then it's up to you to go host it somewhere.


We want to give the developers to choose whether to use the hosted solution or take the app and the source code and host anywhere else. We understand developers need the freedom to choose

“Nodey On Rails”?

Really cool... But I would really like to see more data type support and also if it isn't too much support for other frontend frameworks (Specifically Vue.js/Angular). Nest.js and Prisma is something I wanted to try for a long a time. All the best.

Thanks! We are focusing on the backend but try to provide the minimal staring point for front end clients. We will consider adding more clients later down the road.

I'm using the same ecosystem with React and Nest.js. Very awesome to see an app built with best practices for JavaScript in 2021. You might have saved me hundreds of hours of work. Why Prisma and not TypeORM?

TypeORM is no longer maintained in a frequency that gave us enough confidence about the future.

See this discussion https://www.reddit.com/r/graphql/comments/duecak/comment/f77...


Why not use typeORM as the ORM for Amplication ? It is already feature complete

Very cool, looks like it only works with Node.js and possibly React. I've a huge fan of Hasura which just sits in front of Postgres and presents GraphQL queries (and is easily deployable as a container).


What other projects are competitors in this space?

Not sure "competitor" is the right word, but I started to work on my own boilerplate/project-starter some time ago[0]. I choose to use NestJS, knex and NextJS. My objective is to achieve the best tradeoffs between autogenerated-boring-stuff and easily-customize-everything (yes, including complex DB queries, especially those actually).

Also, there's BlitzJS which seems to have similar objectives.

There's definitely no incumbent in the Js/ts/nodejs world similar to the django/laravel/rails/mojolicious frameworks in the other, more mature, dynamic languages.

https://github.com/tudorconstantin/knests


Really cool, super intuitive UI. I won't really be able to use it though until it supports more data types, hopefully with specific DB's in mind.

Thanks. Can you please share what data types you have in mind?

Well with the quick spin I did I wanted to create a few integer based data types, which is pretty standard for a DB/API. Your numerical type only allows for 7 numbers which seems very odd. Postgres for example has 10 different default integer data types. Putting in 11111111 throws an error. There's more than enough reasons why you need larger ranges and more control over the types.

How does this compare to https://wasp-lang.dev/ ?

Great stuff, from wonderful contributors :)

Thanks

I'm having a miserable time with Sequelize, and I see this uses Prisma. What contributed to that decision?

Prisma is awesome. We initially tried TypeOrm and Sequilize and quickly move to Prisma for various reasons. I may post a blog post about this journey soon

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.

Is this a bit like Jhipster but then for JS/Node instead of Java/Spring Boot?

Wondering how many GQL programmers are aware of GQL injections.

Seems like a great tool I’ll make sure to give it a try

Thanks! if you need any support or have feedback please find us on our discord channel. We are always there for a chat

https://discord.gg/b8MrjU6


Why do I have to run Docker to run the server locally? This always raises a red "over-engineered" flag for me. Docker is for deployment, not development.

Our giants came before us, swallowed the enormous complexity and presented us with simpler abstraction to build on.

When you move your work across environmental abstraction, these beneficial abstracts tend to show their cracks.

By keeping the production and the development environments similar, my team avoids deployment surprises and disasters. More importantly, we avoid the escalation calls that take you away from the family dinner table.

If you are gonna delpoy in a docker container, maybe develop in the docker container.


Nice!! How does it compare with Postgraphile?

Postgraphile is a great tool. The main difference is that we generate code that you can use any way you like and deploy anywhere you want. If you are a Node.js developer you get a boost that helps you focus on your business logic without giving up on the flexibility of code. Also, on our roadmap, we want to provide developers with a full set of features to make development easier, e.g. integration, connecting to different DBs, and much more.

Very cool. What DB is the tool currently using?

PostgreSQL

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.


StrongLoop?



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: