[HN Gopher] Show HN: Remult - a CRUD framework for full-stack Ty...
___________________________________________________________________
Show HN: Remult - a CRUD framework for full-stack TypeScript
Author : yonirapoport
Score : 92 points
Date : 2022-05-22 15:52 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| tomcam wrote:
| Very well thought out. Demo at
|
| https://remult-crm-demo.herokuapp.com/
|
| Username: Velva
|
| Password: password
|
| Front end of the demo is functional but a little rough on my
| iPhone with Safari.
| d4a wrote:
| It seems to already be filled with racial slurs unfortunately.
|
| Also, pressing enter to log in doesn't work.
| latchkey wrote:
| I'd prefer if they wrapped https://mikro-orm.io/ instead of
| inventing their own.
| MuffinFlavored wrote:
| Bundle some Dockerfile/docker-compose.yml/k8s yaml/k8s Helm
| charts/Terraform examples maybe?
|
| https://docs.digitalocean.com/products/app-platform/how-to/a...
|
| https://devcenter.heroku.com/articles/heroku-button
| yonirapoport wrote:
| Good idea. Thanks!
| moltar wrote:
| Decorators are tiring.
| dfee wrote:
| I'm distrustful of them. I'm not sure what version will be
| approved and what version has been ruled out, invalidating some
| swath of libraries.
|
| Can anyone provide a succinct summary?
| johnhenry wrote:
| There is an implementation proposal [0] is at stage 3[1],
| which means it's likely to land. Unfortunately, there is no
| set timeline.
|
| - [0] https://github.com/tc39/proposal-decorators - [1]
| https://tc39.es/process-document/
| moltar wrote:
| Another alternative is tRPC.
| jadbox wrote:
| Similar, one of my fav TypeScript CRUD tools is TSOA. It
| generates OpenAPI specs from regular type information on
| functions. https://tsoa-
| community.github.io/docs/introduction.html
| smt88 wrote:
| Unfortunately like almost all Node libraries, it isn't very
| mature or well-maintained. I stopped using it because it was
| too rigid and missing vital features.
| imachine1980_ wrote:
| what is the advantage over next.js-typescript?
| yonirapoport wrote:
| It should be an addition to next.js not a replacement. It adds
| the CRUD capabilities, strong typing, entity code sharing...
| etnichols wrote:
| How does this differ from Prisma? https://www.prisma.io/.
|
| I do like the quick bootstrapping Remult offers via "JSON db" if
| one hasn't set up a DB yet. And entity classes defined as a .ts
| file is nice, as opposed to Prisma's DSL (e.g. schema.prisma
| file).
| redox99 wrote:
| Seems pretty different. Prisma is an ORM basically, while this
| generates HTTP REST endpoints for you.
| yonirapoport wrote:
| Prisma focuses on backend<->db while Remult also handles
| frontend<->backend
| robocat wrote:
| Hmmm, exceptions in validation! Debugger hell.
| export class Product { @Fields.string<Product>({
| validate: product => { if
| (product.name.trim().length == 0) throw
| 'required'; } }) name = '';
| gabereiser wrote:
| I see this a lot with Java style validations. Everything is an
| exception or can be one. Try catch hell everywhere and there
| are two schools of thought. Let the exceptions bubble up. Or
| catch the exceptions you expect at the abstraction, letting the
| rest bubble up.
| matthewfcarlson wrote:
| I love the idea of this. I've written something in the same vein
| but it's a websocket transport and it has a shared vuex store. So
| basically mutations are sent across the wire and it has logic for
| dealing with conflicts.
| darepublic wrote:
| I may try this out since I am handrolling something similar for a
| project but I am strapped for time. Only thing is I am generating
| types from an openapi spec and sharing the types with ui as a
| dependency. I somewhat prefer that approach as I end up with an
| openapi spec and I don't need any framework whatsoever beyond
| perhaps a dev dependency on type generation from openapi doc
| nawgz wrote:
| I like to use Hasura to give me full GraphQL access to a
| PostgreSQL/MSSQL database and then I can use graphql-codegen to
| get real, schema-based frontend types with no need for more
| tools than Hasura and graphql-codegen. Not sure that'll help
| you here but it's a thought.
|
| I will note the MSSQL version of Hasura seems to be slightly
| behind in documentation, not sure about features though
| darepublic wrote:
| unfortunately I am in the anti-graphql camp
| goodoldneon wrote:
| What are you using to codegen the types?
| darepublic wrote:
| I haven't done it yet. I've just set up a monorepo and
| prototyped sharing of types from backend to frontend.
| Googling it seemed like there were some decent options for
| type generation from swagger, i.e.
| https://github.com/drwpow/openapi-typescript
| metadat wrote:
| This looks really nice. Are there any other competing frameworks
| in the TS space? Would be curious to hear about folks'
| experiences.
| xcambar wrote:
| I use Nest as my TS backend framework of choice.
|
| It just works great, covers just every use case I throw at it
| (business apps or side projects), has the right balance of
| versatility and openness, and doesn't try to do more than
| backend.
|
| I really love it.
| js4ever wrote:
| I hated Nest, you have to learn their "magic", it was
| continuously in my way instead of helping me
| kolanos wrote:
| This is totally off topic, but I am glad to see this here.
| Nest.js seems really powerful on the surface, when you
| start reading their docs [0] everything makes sense at
| first. But the deeper you go, the more it sets in that the
| complexity introduced by its "magic" results in very little
| being easily reasoned about. Just look at the process for
| building a GraphQL API [1], for example, it starts out
| simply enough then goes off the deep end. Decorators,
| dependency injection and providers within providers all the
| way down.
|
| [0]: https://docs.nestjs.com [1]:
| https://docs.nestjs.com/graphql/quick-start
| sirius87 wrote:
| I went down that rabbithole when I had to set up Graphql
| with federation. The reason it seems complicated is
| because they're attempting to fit bootstrap processes of
| different libraries into their own IoC style by writing
| tiny wrappers.
|
| You end up with large blocks of config in ugly decorators
| but what they're doing is trying to supply that config to
| the underlying libs.
|
| I consider Nestjs docs to be among the best written docs
| in the node community. Virtually everything you need is
| in there.
| eropple wrote:
| So I spent a lot of time in the Nest ecosystem, and I wrote
| some nontrivial libraries with a little (not a lot) of
| uptake (and neither are actively maintained at this point,
| so these are here mostly for completeness):
|
| https://github.com/eropple/nestjs-auth
|
| https://github.com/eropple/nestjs-openapi3
|
| I was pretty excited by NestJS when I ran into it because,
| well--I don't mind magic, when it's done right. I quite
| like Spring Boot, for example. But NestJS's magic
| is...incorrect, in a lot of ways. The DI container is a
| little bit scary, with oddly hardcoded ways to register
| interceptors into request scope (itself necessary because
| NestJS's logging facilities aren't--or weren't at the time
| --decorating requests with X-Request-Id or similar, so you
| had to register your own) and no way to then define
| interceptor order.
|
| It also has a lot of really overlapping _nouns_ ; guards
| are interceptors but less capable (and @eropple/nestjs-auth
| didn't use them at all) and the "pipe" concept for
| validation was itself inscrutable. To make it usable, I
| ended up just doing everything with decorators and
| interceptors, all living in request scope. And once I'd
| gotten it going, it was pretty nice. But it also meant
| broad incompatibilities with much of the NestJS ecosystem.
| It was mostly just my magic, instead.
|
| These days I use Fastify, and, well--some things never
| change:
|
| https://github.com/eropple/fastify-openapi3
| dimgl wrote:
| Interviewed recently with a startup that said they're
| moving from Hapi over to Nest. Lol... maybe it's for the
| best things didn't work out.
| fswd wrote:
| agree. "inversion of control" doesn't work well for the
| backend. Had an issue with the frontend due to what I
| thought was CORS. Putting a simple 'console.log' in nestjs
| doesn't work... had to write an 'inversion of control'
| custom logger to find out it wasn't a CORS error but double
| slashes '//auth/me' vs /auth/me because of environmental
| variable. A simple console.log could have fixed this but
| instead it took several hours of research. Really? Why?
| makess me think nestjs is built for billable hours and
| frustration... Asking for help you get treated like a jr
| developer.
| Eric_WVGG wrote:
| You're not kidding at all. I discovered a problem with
| their implementation of Bull queues, and the attitude of
| that crowd was something else.
|
| Despite that, I quite like NestJS, but I am a bit
| concerned about their -- and Remult's -- reliance on
| decorators, a standard that appears to be in flux.
| douglasisshiny wrote:
| I thought nest was somewhat straight forward, minus the use
| of the angular module system, but I spent years using
| Java/Spring. That said, nest didn't have a component scan
| so you have to manually specify services per module.
|
| Having spent more time using typescript and picked up
| functional programming similar to Haskell (via fp-ts), I
| wouldn't touch nest despite its popularity.
|
| MarbleJS looks interesting. But I'd also be inclined to use
| express with supporting libraries.
| iampims wrote:
| ChiselStrike
___________________________________________________________________
(page generated 2022-05-22 23:00 UTC)