[HN Gopher] Show HN: Amplication - Instantly Generate Node.js Ap...
___________________________________________________________________
Show HN: Amplication - Instantly Generate Node.js Apps with GraphQL
and REST API
Author : yuvalhazaz
Score : 186 points
Date : 2021-01-12 16:49 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| grok22 wrote:
| Same conceptually as https://github.com/xgenecloud/xgenecloud?
| johnghanks wrote:
| So... you copied AWS' Amplify?
| yuvalhazaz wrote:
| 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.
| tiborsaas wrote:
| 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.
| yuvalhazaz wrote:
| 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
| insomniacity wrote:
| 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 :)
| wyck wrote:
| 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.
| yuvalhazaz wrote:
| Thanks. Can you please share what data types you have in mind?
| wyck wrote:
| 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.
| TameAntelope wrote:
| I'm having a miserable time with Sequelize, and I see this uses
| Prisma. What contributed to that decision?
| yuvalhazaz wrote:
| 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
| latchkey wrote:
| Please give MikroORM a shot, vastly better than the
| mentioned.
|
| https://github.com/mikro-orm/mikro-orm
| nikolasburk wrote:
| 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.)
| nikolasburk wrote:
| 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!
| brainbag wrote:
| I was just searching for a tool exactly like this a few days ago.
| Looks really great!
| yuvalhazaz wrote:
| Great! Please share your feedback once you've tried it!
| yutuibe wrote:
| Wondering how many GQL programmers are aware of GQL injections.
| lrmunoz wrote:
| How does this compare to https://redwoodjs.com/ ?
| yuvalhazaz wrote:
| 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.
| cratermoon wrote:
| Autogenerated direct data coupling.
| RedShift1 wrote:
| What are you implying?
| kgiddens1 wrote:
| Great stuff, from wonderful contributors :)
| yuvalhazaz wrote:
| Thanks
| ithrow wrote:
| 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.
| dgb23 wrote:
| 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.
| yuvalhazaz wrote:
| 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.
| qudat wrote:
| 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
| arcturus17 wrote:
| 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.
| sombremesa wrote:
| 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.
| vagrantJin wrote:
| 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.
| arcturus17 wrote:
| > 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.
| sombremesa wrote:
| > 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...
| yuvalhazaz wrote:
| 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)
| slingnow wrote:
| This does nothing to address the OPs concerns. You might as
| well have just said "Don't worry about it!"
| Dnguyen wrote:
| 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.
| ethan_smith wrote:
| Nice!! How does it compare with Postgraphile?
| yuvalhazaz wrote:
| 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.
| jsnk wrote:
| Very cool. What DB is the tool currently using?
| yuvalhazaz wrote:
| PostgreSQL
| hilalh wrote:
| Seems like a great tool I'll make sure to give it a try
| yuvalhazaz wrote:
| 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
| emilsoman wrote:
| How does this compare to https://wasp-lang.dev/ ?
| Ataraxy wrote:
| 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.
| jamil7 wrote:
| > I'm not at all too big on TS (which is sacrelige apparently)
|
| All of JS with an :any appended to it ;)
| yuvalhazaz wrote:
| 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
| liorshani wrote:
| This is EPIC
| [deleted]
| whalesalad wrote:
| 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!
| yuvalhazaz wrote:
| thanks!
| andrewprock wrote:
| 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.
| city41 wrote:
| 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.
| yuvalhazaz wrote:
| 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
| pamicel wrote:
| Why not use typeORM as the ORM for Amplication ? It is already
| feature complete
| gfrangakis wrote:
| 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.
| iaml wrote:
| 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
| muttantt wrote:
| Are you using SQLAlchemy in a blocking way w/ FastAPI?
| gfrangakis wrote:
| 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/
| itisit wrote:
| StrongLoop?
| mettamage wrote:
| Is this a bit like Jhipster but then for JS/Node instead of
| Java/Spring Boot?
| timbram wrote:
| test
| iddan wrote:
| Very excited to see this project hitting the top page. Had the
| time of my life contributing to it
| yuvalhazaz wrote:
| geektips wrote:
| 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.
| yuvalhazaz wrote:
| 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.
| dave_sid wrote:
| "Nodey On Rails"?
| Zaheer wrote:
| Big fan of frameworks like this. AdonisJS is similar in this
| space: https://preview.adonisjs.com/
| SamBam wrote:
| 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?
| johnx123-up wrote:
| I'm not the OP. FWIW, I have checked their video
| https://www.youtube.com/watch?v=tKGeLXoPr94
| nk1tz wrote:
| same 500 error for me
| yuvalhazaz wrote:
| 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.
| jtth wrote:
| 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?
| yuvalhazaz wrote:
| You can watch this video
| https://www.youtube.com/watch?v=tKGeLXoPr94
| egeozcan wrote:
| 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.
| yuvalhazaz wrote:
| 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
| turtlebits wrote:
| 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).
| wbobeirne wrote:
| 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?
| yuvalhazaz wrote:
| 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.
___________________________________________________________________
(page generated 2021-01-12 23:00 UTC)