-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(rest): Created rest package #200
base: master
Are you sure you want to change the base?
Conversation
☁️ Nx Cloud ReportCI is running/has finished running commands for commit 49cd3a4. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution ✅ Successfully ran 5 targetsSent with 💌 from NxCloud. |
packages/query-rest/src/decorators/filterable-field.decorator.ts
Outdated
Show resolved
Hide resolved
# Conflicts: # examples/project.json # package.json # yarn.lock
☁️ Nx Cloud ReportCI is running/has finished running commands for commit e2353ec. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution
✅ Successfully ran 2 targetsSent with 💌 from NxCloud. |
# Conflicts: # package.json # yarn.lock
…er in `@Field` decorator
# Conflicts: # yarn.lock
…to use it - Added `FindOneArgsType` for standardizing ID parameter handling. - Updated delete, update, and read resolvers to use `FindOneArgsType`. - Introduced new `id-field.decorator` for marking ID fields. - Removed redundant `BadRequestException` in read resolver.
…clude "Args" suffix
# Conflicts: # yarn.lock
…piSchema decorator
- Correct `FindOneArgsType` parameter in `read.resolver.ts` - Enhance `field.decorator.ts` to properly retrieve metadata - Add `IsNumber` and `IsString` validators for specific types - Improve handling of array options and validation
@TriPSs What's going on in this PR? Kinda curious as to on what you're working in this branch. The name kinda does not ring a bell. I mean what do you mean by "rest"? |
The current packages are focused on building a GraphQL API, this will add a package to create/support REST (Get, Post, Put, Delete) API (More traditional), I'm currently still building this out in inside a other project who will almost go live, so once that is done i'm back porting it here and will implement some tests so it can be released. |
OK, so basically it will be a new package next to the others we have already. But I am worried if this will introduce extra functionality which just might complicate the source code unnecessarily. Will skim through in the next week. |
Well it's something I wanted/needed so i'm still going to add it, it's open for others to then also use if they don't want GraphQL. Also since it's completely islolated in it's own package (just like GraphQL is) and uses the other services (just like the GraphQL one does) I do not see how this complicates the code base, as people only tend to look at the things they need/use (if they look at all). |
Well the idea is to be exactly like the GraphQL one (but with minor differences as not everything in GraphQL is available in REST), with full swagger/open api support so frontend types/libs can still be automatically generated :) Once the internal version is live I will update this PR with the latest version, improve some naming, cleanup, add tests and merge it in for others to use. |
TODO
@FilterableField
None
paging typeMaybe create separate package with the shared code between
rest
andgraphql
packages (Like the interceptors)?